Kubernetes 用の Azure Policy を使用して AKS リソースのクォータ ポリシーを構成する

  • 10 分

Azure Policy は、クラウド環境に対する標準の適用とコンプライアンスの評価を大規模に行うために役立ちます。 会社は、従業員が会社のソフトウェア、ハードウェア、組織内のその他のリソースを使用できる方法を定義するビジネス ルールを実装することをお勧めします。 そのため、企業はポリシーを使ってアクセスを適用、確認、定義します。 ポリシーは、組織がガバナンスおよび法的要件を満たし、ベスト プラクティスを実施し、組織の規約を確立するのに役立ちます。

Azure Kubernetes Service (AKS) では、ポリシーを使ってクラウド ネイティブ アプリケーションを効率的に調整できます。 チームによる AKS の使用方法を管理して、コスト効率の高いアプローチを確保するビジネス ルールの適用が必要であることを認識しています。 Azure Policy を使って、このアイデアを Azure ベースのクラウド リソースに適用することにします。

Kubernetes 用の Azure Policy の使用方法について説明する前に、Kubernetes 内からこの機能を有効にするための概念をさらに理解しておく必要があります。

Kubernetes アドミッション コントローラーとは

"アドミッション" コントローラーは、要求された Kubernetes オブジェクトの永続化の前に、Kubernetes API に対して認証および承認された要求をインターセプトする Kubernetes プラグインです。 たとえば、新しいワークロードをデプロイし、そのデプロイに特定のメモリ要件を持つポッド要求が含まれているとします。 アドミッション コントローラーでデプロイ要求をインターセプトし、クラスターに永続化する前にデプロイを承認する必要があります。

アドミッション コントローラーは、クラスターの使用方法と設計を制御および強制するソフトウェアと考えることができます。 それによって Kubernetes オブジェクトの作成、削除、変更の要求が制限されます。

アドミッション コントローラー Webhook とは

"アドミッション コントローラー Webhook" は、アドミッション要求を受信し、これらの要求に従って動作する HTTP コールバック機能です。 アドミッション コントローラーは実行時に構成する必要があります。 これらのコントローラーは、コンパイルされたアドミッション プラグインか、Webhook として実行されるデプロイされた拡張機能のどちらかに存在します。

"検証 Webhook" または "変更 Webhook" という 2 種類の Admission Webhook を使用できます。 変更 Webhook は、最初に呼び出され、API サーバーに送信されるオブジェクトの既定値を変更して適用することができます。 検証 Webhook は、オブジェクトの値を検証し、要求を拒否することができます。

Open Policy Agent (OPA) とは

"Open Policy Agent (OPA)" は、オープンソースの汎用ポリシー エンジンです。ポリシーを作成するための宣言型の高級言語が提供されています。 これらのポリシーを使用して、システムの動作を監視する規則を定義できます。

OPA Gatekeeper とは

OPA Gatekeeper は、OPA 構文に従うカスタム リソース定義 (CRD) ベースのポリシーを適用する、オープンソースの検証 Kubernetes アドミッション コントローラー Webhook です。

OPA Gatekeeper の目的は、サービスのポリシー ルールをハードコーディングする代わりに、構成を使用してアドミッション ポリシーをカスタマイズできるようにすることです。 また、ポリシーに違反しているリソースを特定するためのクラスターの完全なビューも提供されます。

OPA Gatekeeper を使用して、組織全体のポリシーをルールで定義します。

  • 構成されているすべてのポッドに、CPU 制限やメモリ制限などの最大リソース制限を適用する。

  • イメージのデプロイは、承認されたリポジトリからのみ許可する。

  • クラスター内のすべての名前空間のラベルの名前付け規則では、各名前空間の接続ポイントを指定する必要があります。

  • クラスター サービスにグローバルに一意のセレクターがあることを義務付けます。

AKS の Azure Policy

Azure Policy は、OPA Gatekeeper バージョン 3 を拡張し、組み込みのポリシーを介して AKS と統合されます。 これらのポリシーにより、一貫した一元的な方法で、大規模な実施と保護をクラスターに適用します。

会社の開発チームは、開発を最適化し、Kubernetes 開発ワークフローを簡略化するために、DevSpaces などの開発ツールを導入することを望んでいます。 あなたは、チーム メンバーにプロジェクト固有のリソース制限に従わせる必要があります。 開発名前空間で許可されるコンピューティング リソース、ストレージ リソース、およびオブジェクト数を定義するポリシーを設定することにします。

リソース制限を設定するには、名前空間レベルでリソース クォータを適用し、リソースの使用状況を監視してポリシーのクォータを調整します。 この方法を使用して、開発チーム全体でのリソースの予約と制限を行います。

AKS 用の Azure Policy アドオンを有効にする方法

AKS 用の Azure Policy アドオンを登録するには、いくつかの手順があります。 ここでは例を示しますが、実際にこの手順を実行するのは次のユニットです。

  1. az provider register コマンドを使用して、2 つのリソース プロバイダーを登録します。

    • Microsoft.ContainerService および Microsoft.PolicyInsights:これらのリソース プロバイダーは、ポリシー イベントに関する情報のクエリ実行やコンテナー管理などのアクションをサポートします。 これらは、ポリシーの修復のクエリ、作成、更新、または削除を行うためのアクションです。

    2 つの登録コマンドの例を次に示します。

    az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.PolicyInsights

  2. AKS-AzurePolicyAutoApprove 機能を Microsoft. ContainerService リソース プロバイダーに登録します。 このコマンドの例を次に示します。

    az feature register --namespace Microsoft.ContainerService --name AKS-AzurePolicyAutoApprove

  3. 機能が正常に登録されたことを確認後、--namespace パラメーターを指定して az provider register コマンドを実行し、新しい機能の登録を反映します。 このコマンドの例を次に示します。

    az provider register -n Microsoft.ContainerService

  4. azure-policy アドオンを有効にします。

    az aks enable-addons \
    --addons azure-policy \
    --name myAKSCluster \
    --resource-group myResourceGroup

    アドオンをアクティブ化すると、クラスター上の 2 つの名前空間にあるワークロードがスケジュールされます。 最初の名前空間は kube-system で、これには azure-policy と azure-policy-webhook が含まれます。 2 番目の名前空間は gatekeeper-system で、これには gatekeeper-controller-manager が含まれています。 これらのワークロードは、AKS コントロール プレーンに送信された要求を評価する役割を担います。 構成されたポリシーに基づいて、ポリシー Webhook では要求を許可または拒否できます。

組み込みポリシーの定義を割り当てる

Azure ポリシーのコンプライアンス ダッシュボードを使用して、Azure 環境のポリシーを管理します。 ダッシュボードを使用すると、リソースごと、ポリシーごとの詳細レベルにドリルダウンできます。 既存のリソースの一括修復と新しいリソースの自動修復を使用して、リソースを準拠させるのに役立ちます。

各ポリシーについて、次の概要情報が一覧表示されます。

項目 説明 例
名前 ポリシーの名前。 [プレビュー]:[Kubernetes クラスター内でコンテナーの CPU およびメモリのリソース制限が指定された制限を確実に超えないようにする] という名前のポリシーを構成する準備ができました。
スコープ このポリシーが適用されるサブスクリプション リソース グループ。 mySubscription/rg-akscostsaving。
コンプライアンスの状態 割り当てられたポリシーの状態。 準拠、競合、未開始、または未登録。
リソースのコンプライアンス ポリシーに準拠しているリソースの割合。 この計算では、準拠、非準拠、競合の各リソースが考慮されます。 100
準拠していないリソース 1 つまたは複数のポリシー ルールに違反している一意のリソースの数。 3
準拠していないポリシー 準拠していないポリシーの数。 5

ここから、トリガーされたイベントのリソースごと、ポリシーごとの詳細にドリルダウンできます。 たとえば、拒否されたワークロードのデプロイの詳細を確認できます。

ポリシーの割り当て

ポリシーを割り当てるには、Azure Policy のナビゲーション パネルの [作成] セクションで [割り当て] オプションを選びます。

Azure ポリシーを 2 つの方法のいずれかで ("イニシアチブ" と呼ばれるポリシーのグループとして、または 1 つのポリシーとして) 割り当てます。

イニシアチブ割り当て

イニシアチブ割り当ての場合、特定の目標や目的を満たすためにグループ化された Azure ポリシー定義のコレクションが割り当てられます。 たとえば、お客様のリソース全体でペイメント カード業界データ セキュリティ基準を適用することが目標である場合があります。

ポリシー割り当て

ポリシー割り当ての場合、[Kubernetes クラスターで特権コンテナーを許可しない] など、1 つのポリシーが割り当てられます。

ポリシーを割り当てる方法

各ポリシーは、一連の構成手順を使用して定義されます。 キャプチャする情報の量は、選択するポリシーの種類によって異なります。

たとえば、会社のクラウド環境での開発者によるリソースのデプロイを制限するために、Azure Kubernetes Service 用の組み込みの Azure ポリシーの 1 つを割り当てることができます。 ポリシーの名前は、[Kubernetes クラスター内でコンテナーの CPU およびメモリのリソース制限が指定された制限を超えないようにする] です。

このポリシーでは、デプロイ要求によって要求される使用可能なリソースに制限を設定することが必要になります。

ポリシーを割り当てるときに構成可能なオプションを見てみましょう。

ポリシーの基本情報

最初の手順では、新しいポリシーを定義する基本情報を選択して入力する必要があります。 たとえば、この情報はポリシーやリソース スコープなどです。 この表には、構成できる各項目が示されています。

Item 説明
スコープ スコープによって、ポリシー割り当てが適用されるリソース、またはリソースのグループが決まります。 この値は、サブスクリプションまたは管理グループに基づいています。 スコープのレベルよりも 1 つ下のレベルで、リソースを選択から除外することができます。
ポリシー定義 適用するポリシー。 いくつかの組み込みのポリシー オプションから選択できます。
割り当て名 割り当てられたポリシーを識別するための名前。
説明 ポリシーについて説明する自由テキストの説明。
ポリシーの適用 [有効] と [無効] を選択できます。 オプションが無効になっている場合、ポリシーは適用されず、要求が非準拠で拒否されることはありません。
割り当て担当者 既定値が登録済みユーザーの自由テキスト値。 この値は変更できます。

ポリシー パラメーター

ポリシーでは、各ポリシーに適用されるビジネス ルールを構成する必要があります。 すべてのポリシーに同じビジネス ルールが設定されるわけではありません。そのため、各ポリシーには異なるパラメーターがあります。

たとえば、[Kubernetes クラスター内でコンテナーの CPU およびメモリのリソース制限が指定された制限を確実に超えないようにする] ポリシーでは、次の 3 つのパラメーターを設定する必要があります。

  • コンテナーで使用できる最大 CPU ユニット数
  • コンテナーで使用できるメモリの最大バイト数
  • ポリシーから除外する Kubernetes 名前空間のリスト

そのポリシーを、構成するカスタム パラメーターがない [Web アプリケーションには HTTPS を介してのみアクセスできるようにする] ポリシーと比較してください。

すべてのポリシーに [効果] 設定があります。 この設定は、ポリシーの実行を有効または無効にします。 パラメーターと同様に、ポリシーにも異なる [効果] オプションがある場合があります。

たとえば、リソース管理ポリシーの場合は、[結果] 値として audit、deny、または disable を選択できます。 Web アプリケーション ポリシーの場合は、audit または disable のみを選択できます。

この表には、ポリシー定義で現在サポートされているすべての効果が一覧表示されています。

効果 説明
追加 要求されたリソースにフィールドを追加する
監査 アクティビティ ログに警告イベントを作成する
AuditIfNotExists 条件に一致するリソースに関連するリソースの監査を有効にする
Deny ポリシー定義によって定義された標準に一致しないリソース要求を防ぎ、要求を失敗させる
DeployIfNotExists 条件が満たされたときにテンプレートのデプロイを実行する
Disabled テストの状況で、またはポリシー定義で効果がパラメーター化されている場合に、単一の割り当てを無効にするのに役立つ
Modify 作成時または更新時にリソースのタグを追加、更新、または削除する

ポリシーの修復

最後の手順では、ポリシーの修復について検討します。 ポリシーを割り当てる場合、リソースが既に存在しており、新しいポリシーに違反している可能性があります。 既定では、新しく作成したリソースのみが新しいポリシーに適用されます。 新しいポリシーを割り当てた後、修復を使って既存のリソースを確認します。 修復タスクは、適用されるポリシーの種類によって異なる場合があります。

次の演習では、[Kubernetes クラスター内でコンテナーの CPU およびメモリのリソース制限が指定された制限を確実に超えないようにする] ポリシーを使って、さらにコストを削減します。