次の方法で共有


Kubernetes 用の Azure Policy について理解する

Azure Policy によって Open Policy Agent (OPA) のための "アドミッション コントローラー Webhook" である Gatekeeper v3 が拡張され、一貫した一元的な方法でクラスター コンポーネントに対して大規模な実施と保護が適用されます。 クラスター コンポーネントには、ポッド、コンテナー、名前空間が含まれます。

Azure Policy を使うと、Kubernetes クラスター コンポーネントのコンプライアンス状態を 1 か所から管理し、レポートすることができます。 Azure Policy のアドオンまたは拡張機能を使うことで、 たとえば、ポリシーの安全なロールアウトとロールバックのためにセレクターオーバーライドを使うような Azure Policy の機能によって、クラスター コンポーネントの管理が強化されます。

Kubernetes 用の Azure Policy では、次のクラスター環境がサポートされています。

重要

Azure Policy アドオンの Helm モデルと AKS エンジンのアドオンは "非推奨" になりました。 手順に従ってアドオンを削除します。

概要

Azure Policy のアドオンまたは拡張機能を Kubernetes クラスターにインストールすると、Azure Policy によって次の機能が適用されます。

  • Azure Policy サービスを使用してクラスターへのポリシー割り当てをチェックします。
  • 制約テンプレート制約カスタム リソースとして、またはミューテーション テンプレート リソースとして、ポリシー定義をクラスターにデプロイします (ポリシー定義の内容に応じて)。
  • 監査およびコンプライアンスの詳細を Azure Policy サービスに報告します。

Kubernetes クラスターで Azure Policy を有効にして使用するには、次の操作を実行します。

  1. Kubernetes クラスターを構成し、(クラスターの種類に応じて) Azure Kubernetes Service (AKS) アドオン、または Azure Policy の Arc 対応 Kubernetes クラスター用拡張機能をインストールします。

    Note

    インストールの一般的な問題については、Azure Policy アドオンのトラブルシューティングに関するページを参照してください。

  2. Kubernetes 用の Azure Policy 定義を作成するか、サンプルを使います

  3. 定義を Kubernetes クラスターに割り当てる

  4. 検証を待機する

  5. ログトラブルシューティング

  6. 制限事項FAQ セクションの推奨事項を確認します

AKS 用の Azure Policy アドオンをインストールする

AKS 用 Azure Policy アドオンは、長期サポート (LTS) を備えた Kubernetes バージョン 1.27 の一部です。

前提条件

  1. リソース プロバイダーとプレビュー機能を登録します。

    • Azure portal:

      Microsoft.PolicyInsights リソース プロバイダーを登録します。 手順については、「リソース プロバイダーと種類」を参照してください。

    • Azure CLI:

      # Log in first with az login if you're not using Cloud Shell
      
      # Provider register: Register the Azure Policy provider
      az provider register --namespace Microsoft.PolicyInsights
      
  2. Azure CLI バージョン 2.12.0 以降がインストールされて構成されている必要があります。 バージョンを確認するには、az --version コマンドを実行します。 インストールまたはアップグレードの必要がある場合は、「Azure CLI をインストールする方法」を参照してください。

  3. AKS クラスターは、Azure Kubernetes Service (AKS) でサポートされている Kubernetes バージョンである必要があります。 AKS クラスターのバージョンを検証するには、次のスクリプトを使用します。

    # Log in first with az login if you're not using Cloud Shell
    
    # Look for the value in kubernetesVersion
    az aks list
    
  4. Azure Policy 拡張機能のポートを開きます。 Azure Policy 拡張機能では、これらのドメインとポートを使用して、ポリシー定義と割り当てがフェッチされ、クラスターのコンプライアンスが Azure policy に報告されます。

    Domain Port
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

前提条件が完了したら、管理する AKS クラスターに Azure Policy アドオンをインストールします。

  • Azure Portal

    1. Azure portal で [すべてのサービス] を選択し、 [Kubernetes サービス] を検索して選択することで AKS サービスを起動します。

    2. お使いのいずれかの AKS クラスターを選択します。

    3. [Kubernetes サービス] ページの左側の [ポリシー] を選択します。

    4. メイン ページで、 [アドオンを有効にする] ボタンを選択します。

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell
    
    az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
    

アドオンが正常にインストールされていることと、azure-policy および gatekeeper ポッドが実行されていることを確認するには、次のコマンドを実行します。

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

最後に、<rg> をリソース グループ名に置き換え、<cluster-name> を AKS クラスターの名前に置き換えて Azure CLI コマンド az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name> を実行することにより、最新のアドオンがインストールされていることを確認します。 結果は、サービス プリンシパルを使用するクラスターの次の出力のようになります:

{
  "config": null,
  "enabled": true,
  "identity": null
}

マネージド ID を使用するクラスターの出力は次のとおりです:

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Azure Arc 対応 Kubernetes 用の Azure Policy 拡張機能をインストールする

Kubernetes 用の Azure Policy を使用すると、Kubernetes クラスターのコンプライアンスの状態を 1 か所から管理し、レポートすることができます。 Azure Policy の Arc 対応 Kubernetes クラスター用拡張機能を使うと、ポッドやコンテナーなどの Arc 対応 Kubernetes クラスター コンポーネントを管理できます。

この記事では、Kubernetes 用の Azure Policy 拡張機能を作成し、拡張機能の状態を表示し、拡張機能を削除する方法について説明します。

拡張機能のプラットフォームの概要については、Azure Arc クラスターの拡張機能に関する記事を参照してください。

前提条件

既に Helm を拡張機能なしで直接使用して、Kubernetes 用の Azure Policy を Azure Arc クラスターにデプロイしている場合は、手順に従って Helm チャートを削除します。 削除が完了したら、次に進むことができます。

  1. お使いの Kubernetes クラスターがサポートされているディストリビューションであることを確認します。

    Note

    Arc 拡張機能用の Azure Policy は、次の Kubernetes ディストリビューションでサポートされています。

  2. Azure Arc へのクラスターの接続など、こちらに記載されている Kubernetes 拡張機能の一般的な前提条件を、すべて満たしていることを確認します。

    Note

    Arc 対応 Kubernetes クラスターでは、こちらのリージョンで Azure Policy 拡張機能がサポートされています。

  3. Azure Policy 拡張機能のポートを開きます。 Azure Policy 拡張機能では、これらのドメインとポートを使用して、ポリシー定義と割り当てがフェッチされ、クラスターのコンプライアンスが Azure policy に報告されます。

    Domain Port
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443
  4. Azure Policy 拡張機能をインストールしたり、このサービスの機能のいずれかを有効にしたりする前に、お客様のサブスクリプションで Microsoft.PolicyInsights リソース プロバイダーを有効にする必要があります。

    Note

    リソース プロバイダーを有効にするには、リソース プロバイダーと種類に関する記事の手順を実行するか、Azure CLI または Azure PowerShell コマンドを実行します。

    • Azure CLI

      # Log in first with az login if you're not using Cloud Shell
      # Provider register: Register the Azure Policy provider
      az provider register --namespace 'Microsoft.PolicyInsights'
      
    • Azure PowerShell

      # Log in first with Connect-AzAccount if you're not using Cloud Shell
      
      # Provider register: Register the Azure Policy provider
      Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'
      

Azure Policy 拡張機能を作成する

Note

Azure Policy 拡張機能の作成では、以下に注意してください。

  • 自動アップグレードは既定で有効になっています。これにより、新しい変更がデプロイされると、Azure Policy 拡張機能のマイナー バージョンが更新されます。
  • パラメーターとして connectedk8s に渡されるプロキシ変数は、送信プロキシをサポートするように Azure Policy 拡張機能に反映されます。

拡張機能のインスタンスを作成するには、Arc 対応クラスターで、<> をご自身の値に置き換えて次のコマンドを実行します。

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

例:

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

出力例:

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Azure Policy 拡張機能を表示する

拡張機能インスタンスが正常に作成されたことを確認し、拡張機能のメタデータを検査するには、<> をご自身の値に置き換えて次のコマンドを実行します。

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

例:

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

拡張機能が正常にインストールされていることと、azure-policy ポッドと gatekeeper ポッドが実行されていることを確認するには、次のコマンドを実行します。

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Azure Policy 拡張機能を削除する

拡張機能インスタンスを削除するには、<> をご自身の値に置き換えて次のコマンドを実行します。

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

ポリシー定義を作成する

Kubernetes を管理するための Azure Policy 言語構造は、既存のポリシー定義のものに従います。 Azure Policy の組み込みポリシー ライブラリには割り当てに利用できるサンプル定義ファイルがあり、クラスター コンポーネントの管理に使用できます。

Kubernetes 用の Azure Policy では、Azure Kubernetes Service クラスターと Azure Arc 対応 Kubernetes クラスターの両方で、コンポーネント レベルでのカスタム定義の作成もサポートされています。 制約テンプレートとミューテーション テンプレートのサンプルは、Gatekeeper コミュニティ ライブラリで入手できます。 Azure Policy の Visual Studio Code 拡張機能を使って、既存の制約テンプレートまたはミューテーション テンプレートをカスタム Azure Policy ポリシー定義に変換できます。

Microsoft.Kubernetes.Dataリソース プロバイダー モードでは、Kubernetes クラスターを管理するために、AuditDenyDisabledMutate の各効果が使われます。

"audit" および "deny" によって、OPA Constraint Framework および Gatekeeper v3 の操作に固有の details プロパティが提供される必要があります。

Azure Policy は、ポリシー定義の details.templateInfo または details.constraintInfo プロパティの一部として、これらの CustomResourceDefinitions (CRD) の URI または Base64Encoded 値をアドオンに渡します。 Rego は、Kubernetes クラスターへの要求を検証するために OPA および Gatekeeper がサポートする言語です。 Azure Policy は、Kubernetes 管理のための既存の標準をサポートすることによって、既存の規則を再利用し、これらを Azure Policy とペアにすることで、統合されたクラウド コンプライアンス レポート体験を実現します。 詳しくは、「Rego とは」を参照してください。

ポリシー定義を割り当てる

ポリシー定義を Kubernetes クラスターに割り当てるには、適切な Azure ロールベースのアクセス制御 (Azure RBAC) ポリシー割り当て操作が割り当てられている必要があります。 Azure 組み込みのロール リソース ポリシー共同作成者所有者には、これらの操作があります。 詳細については、「Azure Policy における Azure RBAC アクセス許可」を参照してください。

次の手順に従って、Azure portal を使用してクラスターを管理する組み込みのポリシー定義を確認します。 カスタム ポリシー定義を使用する場合は、それを作成するときに使用した名前またはカテゴリで検索します。

  1. Azure portal で Azure Policy サービスを開始します。 左側のウィンドウで [すべてのサービス] を選択し、 [ポリシー] を検索して選択します。

  2. Azure Policy ページの左側のウィンドウで、 [定義] を選択します。

  3. [カテゴリ] ドロップダウン リスト ボックスから、 [すべて選択] を使用してフィルターをクリアし、 [Kubernetes] を選択します。

  4. ポリシー定義を選択し、 [割り当てる] ボタンを選択します。

  5. [スコープ] を、ポリシーの割り当てを適用する Kubernetes クラスターの管理グループ、サブスクリプション、またはリソース グループに設定します。

    Note

    Kubernetes 用の Azure Policy 定義を割り当てるとき、 [スコープ] にクラスター リソースを含める必要があります。

  6. ポリシーの割り当てに、簡単に識別するために使用できる [名前][説明] を設定します。

  7. [ポリシーの適用] を以下のいずれかの値に設定します。

    • [有効] - クラスターでポリシーを適用します。 違反がある Kubernetes の受付要求は拒否されます。

    • [無効] - クラスターでポリシーを適用しません。 違反がある Kubernetes の受付要求は拒否されません。 コンプライアンス評価の結果は引き続き利用できます。 新しいポリシー定義を実行中のクラスターにロールアウトする場合、[無効] オプションを使用すると、違反のある受付要求が拒否されないため、ポリシー定義のテストに役立ちます。

  8. [次へ] を選択します。

  9. パラメーターの値を設定する

    • ポリシーの評価から Kubernetes 名前空間を除外するには、パラメーター [名前空間の除外] で名前空間の一覧を指定します。 kube-systemgatekeeper-systemazure-arc は除外することが推奨されます。
  10. [Review + create](レビュー + 作成) を選択します。

あるいは、「ポリシーの割り当て - ポータル」クイックスタートを使用して、Kubernetes ポリシーを見つけて割り当てます。 サンプルの audit vms ではなく、Kubernetes ポリシー定義を検索します。

重要

組み込みのポリシー定義は、カテゴリ Kubernetes の Kubernetes クラスターに使用できます。 組み込みポリシー定義の一覧については、Kubernetes のサンプルに関する記事をご覧ください。

ポリシーの評価

アドオンは 15 分おきに、ポリシーの割り当ての変更について Azure Policy サービスでチェックインします。 この更新サイクル中に、アドオンによって変更が確認されます。 これらの変更によって、制約テンプレートと制約の作成、更新、または削除がトリガーされます。

Kubernetes クラスターでは、クラスターに適したラベルが名前空間に含まれている場合、違反のある受付要求は拒否されません。 コンプライアンス評価の結果は引き続き利用できます。

  • Azure Arc 対応 Kubernetes クラスター: admission.policy.azure.com/ignore

Note

Azure Policy アドオンによってインストールされた制約テンプレートと制約リソースを作成および更新するアクセス許可を、クラスター管理者が保持している場合であっても、手動の更新は上書きされるため、こういったシナリオはサポートされていません。 Gatekeeper は、アドオンをインストールして Azure Policy ポリシー定義を割り当てる前に存在していたポリシーの評価を続けます。

アドオンでは、15 分ごとにクラスターのフル スキャンが呼び出されます。 アドオンを使うと、フル スキャンの詳細情報と、クラスターに試行された変更についての Gatekeeper によるすべてのリアルタイム評価が収集された後、すべての Azure Policy 割り当てと同様に、[ポリシー準拠状況の詳細] に含めるために、結果が Azure Policy に報告されます。 アクティブなポリシー割り当ての結果のみが監査サイクル中に返されます。 監査結果は、失敗した制約の状態フィールドに違反と示されることもあります。 "準拠していない" リソースの詳細については、「リソース プロバイダー モードのコンポーネントの詳細」を参照してください。

Note

Kubernetes クラスター用の Azure Policy 内の各コンプライアンス レポートには、過去 45 分間のすべての違反が含まれます。 タイムスタンプは、違反が発生した時刻を示します。

その他の考慮事項:

  • クラスター サブスクリプションが Microsoft Defender for Cloud に登録されている場合、Microsoft Defender for Cloud Kubernetes ポリシーがクラスターに自動的に適用されます。

  • 既存の Kubernetes リソースを持つクラスターに deny ポリシーを適用すると、新しいポリシーに準拠していない既存のリソースが引き続き実行されます。 準拠していないリソースが別のノードで再スケジュールされると、ゲートキーパーによってリソースの作成がブロックされます。

  • リソースを検証する拒否ポリシーがクラスターにある場合、デプロイの作成時にはユーザーに拒否メッセージは表示されません。 たとえば、replicasets とポッドを含む Kubernetes のデプロイについて考えてみましょう。 ユーザーが kubectl describe deployment $MY_DEPLOYMENT を実行したとき、イベントの一部として拒否メッセージは返されません。 ただし、kubectl describe replicasets.apps $MY_DEPLOYMENT によって、拒否に関連付けられたイベントが返されます。

Note

ポリシーの評価に init コンテナーが含まれる場合があります。 init コンテナーが含まれるかどうかを確認するには、次のような宣言がないか CRD を確認してください。

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

制約テンプレートの競合

複数の制約テンプレートのリソース メタデータ名が同じだが、ポリシー定義で参照されているソースが異なる場所にある場合、このポリシー定義は競合していると見なされます。 たとえば、2 つのポリシー定義によって、Azure Policy テンプレート ストア (store.policy.core.windows.net) と GitHub のように、異なるソースの場所に格納されている同じ template.yaml ファイルが参照されている場合があります。

ポリシー定義とその制約テンプレートが割り当てられているが、クラスターにまだインストールされておらず、かつ競合している場合、これらは競合しているものとして報告され、競合が解決されるまでクラスターにインストールされません。 同様に、新しく割り当てられたポリシー定義と競合する、クラスター上に既に存在する既存のポリシー定義とその制約テンプレートは、引き続き正常に機能します。 既存の割り当てが更新され、制約テンプレートの同期に失敗した場合、クラスターも競合としてマークされます。 すべての競合メッセージについては、「AKS リソース プロバイダー モードのコンプライアンス上の理由」を参照してください。

ログ記録

Kubernetes のコントローラーおよびコンテナーとして、azure-policy ポッドと gatekeeper ポッドのどちらを使用しても、Kubernetes クラスター内にログが保持されます。 一般に、クラスターへのポリシー インジェストとコンプライアンス レポートに関する問題のトラブルシューティングを行うには、azure-policy ログを使用します。 ランタイムの拒否のトラブルシューティングを行うには、gatekeeper-controller-manager ポッド ログを使用します。 既存のリソースの監査のトラブルシューティングを行うには、gatekeeper-audit ポッド ログを使用します。 このログは Kubernetes クラスターの [Insights] ページに公開されます。 詳細については、「Azure Monitor for containers を使用して Kubernetes クラスターのパフォーマンスを監視する」を参照してください。

アドオンのログを表示するには、kubectl を使用します。

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

コンプライアンスの結果に表示される特定の ComplianceReasonCode をトラブルシューティングしようとしている場合は、azure-policy ポッドのログでそのコードを検索して、付随するエラー全体を確認できます。

詳細については、Gatekeeper ドキュメントの Gatekeeper のデバッグに関する記事を参照してください。

Gatekeeper のアーティファクトを表示する

アドオンにより、ポリシー割り当てがダウンロードされ、制約テンプレートと制約がクラスターにインストールされた後、ポリシー割り当て ID やポリシー定義 ID などの Azure Policy 情報で両方に注釈が付けられます。 アドオン関連のアーティファクトを表示するようにクライアントを構成するには、次の手順を使用します。

  1. クラスター用に kubeconfig を設定します。

    Azure Kubernetes Service クラスターの場合、次の Azure CLI を使用します。

    # Set context to the subscription
    az account set --subscription <YOUR-SUBSCRIPTION>
    
    # Save credentials for kubeconfig into .kube in your home folder
    az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>
    
  2. クラスターの接続をテストします。

    kubectl cluster-info コマンドを実行します。 正常に実行されると、各サービスは実行されている場所の URL で応答します。

アドオンの制約テンプレートを表示する

アドオンによってダウンロードされた制約テンプレートを表示するには、kubectl get constrainttemplates を実行します。 k8sazure で始まる制約テンプレートが、アドオンによってインストールされたものです。

アドオンのミューテーション テンプレートを表示する

アドオンによってダウンロードされたミューテーション テンプレートを表示するには、kubectl get assignkubectl get assignmetadatakubectl get modifyset を実行します。

Azure Policy のマッピングを取得する

クラスターにダウンロードされた制約テンプレートとポリシー定義間のマッピングを特定するには、kubectl get constrainttemplates <TEMPLATE> -o yaml を使用します。 結果は次の出力のようになります。

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> はサブスクリプション ID、<GUID> はマップされたポリシー定義の ID です。 <URL-OF-YAML> は、クラスターにインストールするためにアドオンによってダウンロードされた制約テンプレートのソースの場所です。

アドオンによってダウンロードされた制約テンプレートの名前を取得したら、その名前を使用して関連する制約を表示できます。 kubectl get <constraintTemplateName> を使用してリストを取得します。 アドオンによってインストールされた制約は、azurepolicy- で始まります。

制約の詳細を表示する

制約には、ポリシー定義の違反とマッピングおよびポリシー割り当てに関する詳細が含まれます。 詳細を表示するには、kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml を使用します。 結果は次の出力のようになります。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

アドオンのトラブルシューティング

Kubernetes のアドオンのトラブルシューティングに関する詳細については、Azure Policy のトラブルシューティングに関する記事の Kubernetes のセクションを参照してください。

Arc 拡張機能用の Azure Policy 拡張機能に関連する問題については、以下に移動してください。

Azure Policy に関連する問題については、以下に移動してください。

AKS 変更ログ用の Azure Policy アドオン

Azure Policy の AKS 用アドオンには、アドオンのイメージ バージョンを示すバージョン番号が含まれます。 アドオンに機能サポートが新しく導入されると、このバージョン番号が増加します。

このセクションは、クラスターにインストールされているアドオンのバージョンを特定し、AKS クラスターごとにインストールされている Azure Policy アドオン バージョンの履歴テーブルを共有するのに役立ちます。

クラスターにインストールされているアドオンのバージョンを特定する

Azure Policy アドオンでは、バージョンごとに標準のセマンティック バージョン管理スキーマが使われます。 使用中の Azure Policy アドオンのバージョンを確認するには、次のコマンドを実行します: kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

次のコマンドを実行すると、Azure Policy アドオンで使われている Gatekeeper のバージョンを確認できます: kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

最後に、自分が使っている AKS クラスターのバージョンを確認するには、リンクされている AKS ガイダンスに従います。

AKS クラスターのバージョンごとに使用可能なアドオンのバージョン

1.9.1

セキュリティの強化。

  • リリース日: 2025 年 1 月
  • Kubernetes 1.27 以降
  • Gatekeeper 3.17.1

1.8.0

たとえば、execを拒否するなど、ポリシーを使用して CONNECT 操作を評価できるようになりました。 非準拠の CONNECT 操作で使用できるブラウンフィールド コンプライアンスは存在しないため、CONNECT を対象とする監査効果を持つポリシーでは、何の操作も行われません。

セキュリティの強化。

  • リリース日: 2024 年 11 月
  • Kubernetes 1.27 以降
  • Gatekeeper 3.17.1

1.7.1

CEL と VAP について説明します。 Common Expression Language (CEL) は、ポリシーの検証規則を宣言するために使用できる Kubernetes ネイティブの式言語です。 Validating Admission Policy (VAP) 機能は、ツリー内のポリシー評価を提供し、受付要求の待機時間を削減し、信頼性と可用性を向上させます。 サポートされている検証アクションには、拒否、警告、監査が含まれます。 CEL/VAP のカスタム ポリシー作成は許可されており、既存のユーザーは Rego を CEL に変換する必要はありません。これらはどちらもサポートされ、ポリシーを適用するために使用されるためです。 CEL と VAP を使用するには、ユーザーは Microsoft.ContainerService 名前空間の機能フラグ AKS-AzurePolicyK8sNativeValidation に登録する必要があります。 この選択肢の詳細については、Gatekeeper のドキュメントを参照してください。

セキュリティの強化。

  • リリース日: 2024 年 9 月
  • Kubernetes 1.27 以降 (VAP 世代は 1.30 以降でのみサポートされます)
  • Gatekeeper 3.17.1

1.7.0

ワークロード リソース (Deployments、ReplicaSets、Jobs など) が許容可能なポッドを生成するかどうかを前もって知ることを可能にするシフト レフト機能である拡張が導入されます。 拡張は、ポリシーの動作を変更するのではなく、ポッドをスコープとするポリシーの Gatekeeper による評価を、ポッド許可時ではなくワークロード許可時に発生するようにシフトさせるだけのものであるべきです。 ただし、この評価を実行するには、ワークロード内で定義されたポッド仕様に基づく What-If ポッドを生成して評価する必要がありますが、メタデータが不完全な場合があります。 たとえば、What-If ポッドには適切な所有者参照が含まれません。 このポリシー動作の変化の小さなリスクのために、Microsoft は拡張を既定では無効として導入しています。 特定のポリシー定義に対して拡張を有効にするには、.policyRule.then.details.sourceAll に設定します。 組み込みポリシーは、このフィールドのパラメーター化を実現するために間もなく更新される予定です。 ポリシー定義をテストし、評価のために生成された What-If ポッドが不完全であることに気付いた場合は、ソース Generated での変異を使用して What-If ポッドを変異させることもできます。 この選択肢の詳細については、「Gatekeeper のドキュメント」を参照してください。

現在、拡張は AKS クラスターでのみ使用でき、Arc クラスターでは使用できません。

セキュリティの強化。

  • リリース日: 2024 年 7 月
  • Kubernetes 1.27 以降
  • Gatekeeper 3.16.3

1.6.1

セキュリティの強化。

  • 2024 年 5 月リリース
  • Gatekeeper 3.14.2

1.5.0

セキュリティの強化。

  • 2024 年 5 月リリース
  • Kubernetes 1.27 以降
  • Gatekeeper 3.16.3

1.4.0

ミューテーションと外部データを既定で有効にします。 Webhook を追加でミューテートし、Webhook 検証のタイムアウト上限を増やすと、最悪の場合、呼び出しの待ち時間が長くなる可能性があります。 また、コンプライアンスの結果でポリシー セット定義のバージョンを表示するためのサポートが導入されます。

  • リリース日: 2024 年 5 月
  • Kubernetes 1.25 以降
  • Gatekeeper 3.14.0

1.3.0

エラー状態にあるポリシーに対してエラー状態を導入し、非準拠状態にあるポリシーと区別できるようにします。 v1 制約テンプレートのサポートと、ミューテーション ポリシーでの excludedNamespaces パラメーターの使用を追加します。 インストール後の制約テンプレートにエラー状態チェックを追加します。

  • リリース: 2024 年 2 月
  • Kubernetes 1.25 以降
  • Gatekeeper 3.14.0

1.2.1

  • リリース日: 2023 年 10 月
  • Kubernetes 1.25 以降
  • Gatekeeper 3.13.3

1.1.0

  • リリース日: 2023 年 7 月
  • Kubernetes 1.27 以降
  • Gatekeeper 3.11.1

1.0.1

  • リリース日: 2023 年 6 月
  • Kubernetes 1.24 以降
  • Gatekeeper 3.11.1

1.0.0

Kubernetes 用 Azure Policy では、大規模な AKS クラスターを修復するためのミューテーションがサポートされるようになりました。

アドオンを削除する

AKS からアドオンを削除する

AKS クラスターから Azure Policy アドオンを削除するには、Azure portal または Azure CLI のいずれかを使用します。

  • Azure portal

    1. Azure portal で [すべてのサービス] を選択し、 [Kubernetes サービス] を検索して選択することで AKS サービスを起動します。

    2. Azure Policy アドオンを無効にする AKS クラスターを選択します。

    3. [Kubernetes サービス] ページの左側の [ポリシー] を選択します。

    4. メイン ページで、 [アドオンを無効にする] ボタンを選択します。

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell
    
    az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup
    

Azure Arc 対応 Kubernetes からアドオンを削除する

Note

Azure Policy アドオン Helm モデルは非推奨になりました。 この代わりに、Azure Arc 対応 Kubernetes 用の Azure Policy 拡張機能を選択してください。

Azure Policy アドオンと Gatekeeper を Azure Arc 対応 Kubernetes クラスターから削除するには、次の Helm コマンドを実行します。

helm uninstall azure-policy-addon

AKS エンジンからアドオンを削除する

注意

Azure パブリック クラウドのお客様に対して、AKS エンジン製品は非推奨となりました。 マネージド Kubernetes には Azure Kubernetes Service (AKS) を、セルフマネージド Kubernetes の場合にはクラスター API プロバイダー Azure を使用することを検討します。 新しい機能は計画されていません。このプロジェクトは CVE および類似のものに対してのみ更新され、Kubernetes 1.24 が更新プログラムを受け取る最終バージョンとなります。

AKS エンジン クラスターから Azure Policy アドオンと Gatekeeper を削除するには、アドオンのインストール方法に合わせたメソッドを使用します。

  • AKS エンジンのクラスター定義で addons プロパティを設定してインストールした場合:

    azure-policyaddons プロパティを false に変更した後で、クラスター定義を AKS エンジンに再デプロイします。

    "addons": [
      {
        "name": "azure-policy",
        "enabled": false
      }
    ]
    

    詳細については、AKS エンジン - Azure Policy アドオンの無効化に関するページを参照してください。

  • Helm Chart を使用してインストールした場合は、次の Helm コマンドを実行します。

    helm uninstall azure-policy-addon
    

制限事項

  • 一般的な Azure Policy の定義と割り当ての制限については、Azure Policy のドキュメントに記載されている制限をレビューしてください
  • Kubernetes の Azure Policy アドオンは、Linux ノード プールにのみデプロイできます。
  • Azure Policy アドオンでサポートされるポッド最大数 (クラスターあたり): 10,000
  • クラスターごとのポリシー単位での非対応レコードの最大数:500
  • サブスクリプションごとの非対応レコードの最大数:100 万
  • Azure Policy アドオン以外の Gatekeeper のインストールは、サポートされていません。 Azure Policy アドオンを有効にする前に、以前の Gatekeeper インストールによってインストールされたすべてのコンポーネントをアンインストールします。
  • コンプライアンス違反の理由は、Microsoft.Kubernetes.Data リソース プロバイダー モードでは使用できません。 コンポーネントの詳細を使用してください。
  • コンポーネント レベルの除外は、リソース プロバイダー モードではサポートされていません。 Azure Policy 定義でパラメーターのサポートを使って、特定の名前空間を除いたり含めたりできます。
  • 制約テンプレートで metadata.gatekeeper.sh/requires-sync-data 注釈を使ってクラスターから OPA キャッシュへのデータのレプリケーションを構成する設定は、現在、組み込みポリシーでのみ許可されています。 その理由は、慎重に使用しないと、Gatekeeper ポッドのリソース使用量が大幅に増加する可能性があるためです。

Gatekeeper 構成の構成

Gatekeeper 構成の変更は、重要なセキュリティ設定が含まれているためサポートされていません。 構成に対する編集が調整されます。

制約テンプレートでの data.inventory の使用

現在、一部の組み込みポリシーはデータ レプリケーションを利用しています。これにより、ユーザーは既存のクラスター上のリソースを OPA キャッシュに同期し、AdmissionReview 要求の評価時にそれらを参照できます。 データ レプリケーション ポリシーは、Rego 内に data.inventory があることや、metadata.gatekeeper.sh/requires-sync-data 注釈 (ポリシー評価が適切に機能するためにどのリソースをキャッシュする必要があるかを Azure Policy アドオンに通知します) があることで区別できます。 このプロセスは、この注釈が規範的ではなく説明的であるスタンドアロンの Gatekeeper とは異なります。

現在、カスタム ポリシー定義でのデータ レプリケーションの使用はブロックされています。これは、インスタンス数が多いリソースをレプリケートすると、注意して使用しないと Gatekeeper ポッドのリソース使用量が大幅に増加する可能性があるためです。 この注釈がある制約テンプレートを含むカスタム ポリシー定義を作成しようとすると、ConstraintTemplateInstallFailed エラーが表示されます。

この注釈を削除すると、表示されるエラーが軽減されるように見えますが、ポリシー アドオンはその制約テンプレートに必要なリソースをキャッシュに同期しません。 そのため、ポリシーは空の data.inventory に対して評価されます (必要なリソースをレプリケートする組み込みが割り当てられていないと想定した場合)。 これにより、誤解を招くコンプライアンス結果が得られます。 前に説明したように、必要なリソースをキャッシュするように構成を手動で編集することはできません。

AKS の Azure Policy アドオンにのみ、次の制限事項が適用されます。

よく寄せられる質問

Azure Policy アドオンや Azure Policy 拡張機能のインストールでは、クラスターに何がデプロイされますか?

Azure Policy アドオンでは、3 つの Gatekeeper コンポーネント (監査ポッドのレプリカが 1 つ、Webhook ポッドのレプリカが 2 つ) を実行する必要があります。 また、1 つの Azure Policy ポッドと 1 つの Azure Policy Webhook ポッドもインストールされます。

各クラスターで Azure Policy のアドオンや拡張機能を使用する際には、どれくらいの量のリソース消費を想定する必要がありますか?

クラスター内での Kubernetes リソースとポリシー割り当ての数が増えるにつれて、監査と適用の操作が必要になり、クラスターで実行される Kubernetes 用 Azure Policy コンポーネントによって、さらに多くのリソースが消費されます。

計画に役立つ見積もりを次に示します。

  • 最大 20 の制約を持つ 1 つのクラスター内のポッド数が 500 を下回る場合: コンポーネントごとに 2 つの vCPU と 350 MB のメモリ。
  • 最大 40 の制約を持つ 1 つのクラスター内のポッド数が 500 を上回る場合: コンポーネントごとに 3 つの vCPU と 600 MB のメモリ。

Kubernetes 用 Azure Policy の定義は Windows ポッドに適用できますか?

Windows ポッド セキュリティ コンテキストをサポートしていません。 そのため、Windows ポッドでは、ルート特権の禁止など、一部の Azure Policy 定義をエスカレートすることができず、Linux ポッドにのみ適用されます。

どのような種類の診断データが Azure Policy アドオンによって収集されますか?

Kubernetes の Azure Policy アドオンを使うと、制限されたクラスター診断データが収集されます。 この診断データは、ソフトウェアとパフォーマンスに関連する重要な技術データです。 データは次の方法で使用されます。

  • Azure Policy アドオンを最新の状態に維持する。
  • Azure Policy アドオンをセキュリティで保護し、信頼性とパフォーマンスを維持する。
  • アドオン使用状態の集計分析を通じて、Azure Policy アドオンの改善を行なう。

アドオンによって収集された情報は、個人データではありません。 現在、次の詳細情報が収集されています。

  • Azure Policy アドオン エージェントのバージョン
  • クラスターの種類
  • クラスターのリージョン
  • クラスターのリソース グループ
  • クラスターのリソース ID
  • クラスターのサブスクリプション ID
  • クラスターの OS (例:Linux)
  • クラスターの市区町村 (例:シアトル)
  • クラスターの州または都道府県 (例:ワシントン)
  • クラスターの国または地域 (例:米国)
  • ポリシー評価でのエージェントのインストール中に Azure Policy アドオンによって発生した例外/エラー
  • Azure Policy アドオンによってインストールされていない Gatekeeper ポリシー定義の数

Azure Policy アドオンをインストールするときに留意すべき一般的なベスト プラクティスは何ですか?

  • CriticalAddonsOnly テイントとシステム ノード プールを使用して、Gatekeeper ポッドをスケジュールします。 詳細については、システム ノード プールの使用に関するページを参照してください。
  • AKS クラスターから送信トラフィックをセキュリティで保護します。 詳細については、クラスター ノードのエグレス トラフィックの制御に関するページを参照してください。
  • クラスターで aad-pod-identity が有効になっている場合、Node Managed Identity (NMI) ポッドによって、Azure Instance Metadata エンドポイントの呼び出しをインターセプトするようにノードの iptables が変更されます。 この構成の場合、Metadata エンドポイントに要求が行われると、ポッドで aad-pod-identity が使用されていない場合でも NMI により要求がインターセプトされます。
  • CRD に定義されているラベルに一致するポッドから Metadata エンドポイントへの要求はすべて、NMI で何も処理することなく、プロキシ処理する必要があることを aad-pod-identity に通知するように、AzurePodIdentityException CRD を構成できます。 kube-system 名前空間の kubernetes.azure.com/managedby: aks ラベルを持つシステム ポッドは、AzurePodIdentityException CRD を構成して、aad-pod-identity で除外する必要があります。 詳細については、「特定のポッドまたはアプリケーションの aad-pod-identity を無効にする」を参照してください。 例外を構成するには、mic-exception YAML をインストールします。

次のステップ