Policy Controller から移行する

Autopilot Standard

このドキュメントでは、Policy Controller からアドミッション ポリシーを移行して、ポリシーの適用にギャップが生じるリスクを軽減する方法について説明します。Policy Controller は 2026 年 11 月 12 日に非推奨となり、2027 年 12 月 31 日にサポートが終了します。バージョン 1.39 以降では、Google Kubernetes Engine（GKE）クラスタは Policy Controller をサポートしていません。

Policy Controller を使用して適用するアドミッション ポリシーを、Kubernetes ValidatingAdmissionPolicies またはセルフマネージド Open Policy Agent（OPA）Gatekeeper に移行できます。移行しても、すでに実行されているワークロードには影響しません。Policy Controller は、リソースの作成または更新のリクエストを評価するため、削除しても実行中のワークロードが再起動または変更されることはありません。

このドキュメントは、フリート全体で Policy Controller を管理するオペレーターとセキュリティ スペシャリストを対象としています。Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

GKE バージョン 1.39 へのアップグレードがブロックされる

GKE は、Policy Controller がインストールされているクラスタのバージョン 1.39 以降へのアップグレードをブロックします。クラスタをバージョン 1.39 にアップグレードする前に、ポリシーを移行し、そのクラスタから Policy Controller を削除します。ポリシーを移行する前にアップグレードのブロックを解除するためだけに Policy Controller を削除しないでください。削除すると、クラスタにポリシーが適用されなくなります。

交換品を選択する

Policy Controller の各アドミッション ポリシーを評価し、次の表からそのポリシーの置換オプションを選択します。クラスタ全体で 1 つの置換を選択する必要はありません。各ポリシーの要件に基づいて、同じクラスタでオプションを組み合わせることができます。

Policy Controller の代替オプションの比較

オプション	使用する状況	運用とサポート
ValidatingAdmissionPolicy（推奨）	作成または更新時に単一のリソースをチェックするポリシー。Policy Controller テンプレート ライブラリのほとんどのテンプレートは、この方法で動作します。	ValidatingAdmissionPolicy は Kubernetes に組み込まれており、GKE バージョン 1.30 以降で追加料金なしで使用できます。Cloud カスタマーケアは、GKE の一部として ValidatingAdmissionPolicies をサポートしています。
Pod セキュリティ アドミッション（Pod セキュリティ バンドルに推奨）	pss-baseline-v2022、pss-restricted-v2022、psp-v2022 バンドルの事前定義された Pod セキュリティ管理。詳細については、Pod セキュリティ バンドルに Pod Security Admission を使用するをご覧ください。	Pod Security Admission は Kubernetes に組み込まれており、GKE では追加料金なしでデフォルトで有効になっています。カスタマーケアは、GKE の一部として Pod Security Admission をサポートしています。
セルフマネージド OPA Gatekeeper	ValidatingAdmissionPolicies で表現できないポリシー（クラスタ内の他のリソースを読み取る参照ポリシー、Rego に保持するポリシー、既存のリソースの監査など）。Gatekeeper ConstraintTemplates に Common Expression Language（CEL）ルールを追加して、Gatekeeper が API サーバーの適用に ValidatingAdmissionPolicies を生成し、監査コントローラが既存のリソースをチェックするようにすることもできます。	Gatekeeper のインストール、アップグレード、運用はユーザーが行います。カスタマーケアは、オープンソースの Gatekeeper をサポートしていません。Gatekeeper コミュニティは、GitHub を通じてサポートを提供しています。

ポリシーのインベントリを作成して分類する

デフォルトでは、Policy Controller テンプレート ライブラリはすべてのテンプレートをインストールし、ポリシー バンドルは dryrun 違反措置を使用して制約をインストールします。そのため、クラスタのテンプレートと制約が、適用するポリシーと一致するとは限りません。適用する内容を確認する手順は次のとおりです。

1. Policy Controller を実行するフリート内のクラスタを特定します。

   gcloud container fleet policycontroller describe \
       --project=PROJECT_ID
   

   PROJECT_ID は、フリートホスト プロジェクトの ID に置き換えます。

   注: Policy Controller を実行しているフリート外のクラスタが存在する場合があります。たとえば、ConfigManagement Operator を使用して Policy Controller をインストールしたクラスタや、Policy Controller をアンインストールせずにフリートから登録を解除したクラスタなどです。これらのクラスタは、上記のコマンドの出力には表示されません。クラスタで Policy Controller が実行されているかどうかを確認するには、Policy Controller のバージョンを表示するをご覧ください。これらのクラスタから Policy Controller を削除するには、フリート外のクラスタから Policy Controller を削除するをご覧ください。

2. 特定した各クラスタで、制約を一覧表示します。

   kubectl get constraints \
       -o custom-columns='KIND:.kind,NAME:.metadata.name,'\
   'ACTION:.spec.enforcementAction,VIOLATIONS:.status.totalViolations,'\
   'BUNDLE:.metadata.labels.policycontroller\.gke\.io/bundleName'
   

   出力には、各制約の違反に対する措置、最新の監査での違反数、制約をインストールしたバンドルが表示されます。ACTION 列に値がない制約では、デフォルトの deny 適用アクションが使用されます。

3. ConstraintTemplate と制約を別々のファイルにバックアップします。

   kubectl get constrainttemplates -o yaml \
       > policy-controller-templates-backup.yaml
   kubectl get constraints -o yaml \
       > policy-controller-constraints-backup.yaml
   

4. 省略可: 次の追加のバックアップ オペレーションを実行します。

   • Policy Controller で参照ルールを有効にした場合は、同期構成をバックアップします。

     kubectl get config.config.gatekeeper.sh -n gatekeeper-system -o yaml \
         > policy-controller-config-backup.yaml
     

   • Policy Controller でミューテーションを有効にした場合は、ミューテーターをバックアップします。

     kubectl get assign,assignmetadata,assignimage,modifyset -o yaml \
         > policy-controller-mutators-backup.yaml
     

これらのバックアップ ファイルは安全な場所に保管してください。Policy Controller を削除すると、作成した ConstraintTemplate、制約、同期構成、ミューテーターなど、クラスタ上のすべての ConstraintTemplate、制約、同期構成、ミューテーターが削除されます。ポリシーを変換または再作成するには、バックアップが必要です。

ポリシーをバックアップしたら、次の表で制約タイプを確認して、各制約の移行パスを決定します。

制約タイプ別の移行パス

制約タイプ	移行パス
単一リソースの制約	制約が data.inventory を読み取らず、Pod セキュリティ バンドルに属さずに、受信リソースのフィールドのみを評価する場合は、ValidatingAdmissionPolicy を使用します。
適用されていない dryrun 制約	制約で dryrun 違反措置が使用されていて、適用する予定がない場合は、制約を削除します。
Pod セキュリティ バンドルの制約	制約が pss-baseline-v2022、pss-restricted-v2022、psp-v2022 バンドルから取得されている場合は、Pod Security Admission を使用します。Pod Security Admission でカバーされていないコントロールには、ValidatingAdmissionPolicies を使用します。
参照制約	制約が、クラスタ内の他のリソースを読み取る参照テンプレートを使用する場合は、セルフマネージド Gatekeeper を使用します。参照テンプレートを見つけるには、バックアップ ファイルで data.inventory 参照を検索します。
Cloud Service Mesh、Istio、または Google Cloudの制約	制約を個別に確認して、組み込みの GKE 機能がポリシーを置き換えるかどうか、またはバックアップ ファイルの ConstraintTemplate が data.inventory を読み取るかどうかを確認します。これらのテンプレートのほとんどは、受信リソースのみをチェックし、ValidatingAdmissionPolicies で動作します。ただし、参照用の AsmAuthzPolicyDefaultDeny テンプレートと AsmPeerAuthnMeshStrictMtls テンプレートは、セルフマネージド Gatekeeper が必要です。組み込みの置換の場合は、K8sRequireBinAuthZ ConstraintTemplate を使用する代わりに Binary Authorization を有効にし、K8sRequireCosNodeImage ConstraintTemplate を使用する代わりにノードプールのノードイメージを構成します。

ValidatingAdmissionPolicy に移行する

ValidatingAdmissionPolicy には、ConstraintTemplate などのポリシー ロジックが含まれています。ValidatingAdmissionPolicyBinding は、制約のようにポリシーを適用します。ValidatingAdmissionPolicy は Rego ではなく CEL 式を使用し、API サーバーは Webhook を使用せずに式を直接評価します。

例: 許可されたイメージ リポジトリ

次の Policy Controller の制約では、Pod が 1 つの Artifact Registry リポジトリのイメージを使用する必要があります。kube-system 名前空間を除外します。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]
  parameters:
    repos:
    - "us-docker.pkg.dev/example-project/example-repo/"

次の ValidatingAdmissionPolicy と ValidatingAdmissionPolicyBinding は、同じルールを適用します。ValidatingAdmissionPolicyBinding は Warn アクションと Audit アクションを使用するため、ValidatingAdmissionPolicy を適用する前に結果を比較できます。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: allowed-repos
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods", "pods/ephemeralcontainers"]
  variables:
  - name: repos
    expression: "['us-docker.pkg.dev/example-project/example-repo/']"
  - name: images
    expression: >-
      object.spec.containers.map(c, c.image) +
      (has(object.spec.initContainers) ?
        object.spec.initContainers.map(c, c.image) : []) +
      (has(object.spec.ephemeralContainers) ?
        object.spec.ephemeralContainers.map(c, c.image) : [])
  validations:
  - expression: >-
      variables.images.all(image,
        variables.repos.exists(repo, image.startsWith(repo)))
    messageExpression: >-
      'container images must come from one of these repositories: ' +
      variables.repos.join(', ')
    reason: Forbidden
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: allowed-repos
spec:
  policyName: allowed-repos
  validationActions: ["Warn", "Audit"]
  matchResources:
    namespaceSelector:
      matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: NotIn
        values: ["kube-system", "gatekeeper-system"]

この例では、repos 変数に制約の parameters フィールドの値が格納されます。検証式は、ValidatingAdmissionPolicy に準拠する Pod に対して true 値を返します。これは、Rego 違反ルールとは逆です。異なる値を指定する複数の ValidatingAdmissionPolicyBinding で 1 つの ValidatingAdmissionPolicy を再利用するには、変数の代わりにパラメータ リソースを使用します。パラメータ リソースの詳細については、Kubernetes ドキュメントのパラメータ リソースをご覧ください。

次の表に、制約フィールドが ValidatingAdmissionPolicy フィールドと ValidatingAdmissionPolicyBinding フィールドにどのようにマッピングされるかを示します。

Policy Controller の制約フィールドと ValidatingAdmissionPolicy フィールドおよび ValidatingAdmissionPolicyBinding フィールドのマッピング

制約フィールド	ValidatingAdmissionPolicy フィールドまたは ValidatingAdmissionPolicyBinding フィールド
spec.enforcementAction	ValidatingAdmissionPolicyBinding の validationActions フィールド。deny、warn、dryrun アクションを ["Deny"]、["Warn"]、["Audit"] 値にマッピングします。
spec.parameters	ValidatingAdmissionPolicy の variables フィールド、または ValidatingAdmissionPolicyBinding が paramRef フィールドで参照するパラメータ リソース
spec.match.kinds	ValidatingAdmissionPolicy の matchConstraints.resourceRules フィールド。これは、種類の代わりに API グループとリソース名（pods リソースなど）を使用します。
spec.match.namespaces と spec.match.excludedNamespaces	ValidatingAdmissionPolicyBinding の matchResources.namespaceSelector フィールド。kubernetes.io/metadata.name ラベルで In 演算子または NotIn 演算子を使用します。
spec.match.labelSelector	ValidatingAdmissionPolicyBinding の matchResources.objectSelector フィールド
spec.match.namespaceSelector	ValidatingAdmissionPolicyBinding の matchResources.namespaceSelector フィールド
spec.match.scope	各リソースルールの scope フィールド

式の記述方法の詳細については、Kubernetes ドキュメントの Kubernetes の CEL をご覧ください。

Policy Controller とともにポリシーをテストする

適用を中断することなく制約を置き換えるには、ValidatingAdmissionPolicy を適用する前に、制約の横で ValidatingAdmissionPolicy を実行します。

1. ValidatingAdmissionPolicy と、validationActions: ["Warn", "Audit"] 設定を含む ValidatingAdmissionPolicyBinding を適用します。Policy Controller の制約はそのままにします。
2. 違反レポートを置き換えるの監査ログクエリを使用して、結果を比較します。ValidatingAdmissionPolicy が Policy Controller で許可されているリクエストにフラグを付ける場合、またはその逆の場合は、ValidatingAdmissionPolicy を修正します。Pod と一致する ValidatingAdmissionPolicy の場合は、警告に依存しないでください。コントローラは Deployment などのワークロードの Pod を作成するため、コントローラは警告を受け取ります。
3. 結果が一致したら、validationActions: ["Deny"] 設定を使用するように ValidatingAdmissionPolicyBinding を変更します。
4. Policy Controller の制約を削除します。

動作の違いを考慮した計画

ValidatingAdmissionPolicy の動作は、次の点で Policy Controller と異なります。これにより、リクエストがブロックされたり、適用にギャップが生じたりする可能性があります。

• 障害ポリシー: Policy Controller Webhook がフェイル オープンします。つまり、Policy Controller が応答しない場合、API サーバーはリクエストを承認します。failurePolicy: Fail 設定を持つ ValidatingAdmissionPolicy は、式がエラーを返すか、CEL コストの上限を超えると、リクエストを拒否します。ValidatingAdmissionPolicy は、参照されたパラメータ リソースが存在せず、ValidatingAdmissionPolicyBinding の paramRef.parameterNotFoundAction フィールドの値が Deny の場合も、リクエストを拒否します。値が Allow の場合、API サーバーは failurePolicy の設定に関係なく、欠落しているパラメータ リソースをスキップします。各 ValidatingAdmissionPolicy をテストし、両方のフィールドの値を選択します。
• 欠落しているフィールド: Rego は欠落しているフィールドを違反なしとして扱いますが、CEL はエラーを返します。オプション フィールドを読み取る前に、has() マクロを使用してフィールドが存在するかどうかを確認します。
• 除外: ValidatingAdmissionPolicy は、デフォルトで Namespace を除外したり、admission.gatekeeper.sh/ignore ラベルを使用したりしません。GKE Standard クラスタでは、ValidatingAdmissionPolicyBinding の matchResources.namespaceSelector フィールド、または ValidatingAdmissionPolicy の matchConstraints.namespaceSelector フィールドまたは matchConditions フィールドで除外しない限り、ValidatingAdmissionPolicyBinding は kube-system Namespace などのシステム Namespace を含むクラスタ内のすべての Namespace に適用されます。Autopilot クラスタでは、GKE はマネージド Namespace を自動的に除外し、nodes、persistentVolumes、certificatesigningrequests、tokenreviews リソースに一致する ValidatingAdmissionPolicy を拒否します。詳細については、GKE Autopilot のセキュリティ対策をご覧ください。
• サブリソース: Policy Controller は、エフェメラル コンテナを追加する Pod の更新を確認します。このカバレッジを維持するには、この例のように、リソースルールに pods/ephemeralcontainers サブリソースを含めます。
• 既存のリソースの監査なし: ValidatingAdmissionPolicy は、受信 API サーバー リクエストのみを評価します。ValidatingAdmissionPolicy に違反する既存のリソースは報告されません。
• リクエストごとに 1 つのメッセージ: ValidatingAdmissionPolicy は、すべての違反ではなく、最初に失敗した検証を報告します。

Pod セキュリティ バンドルに Pod セキュリティ アドミッションを使用する

pss-baseline-v2022 バンドルまたは pss-restricted-v2022 バンドルを使用する場合は、各制約を変換するのではなく、バンドルを Pod Security Admission に置き換えます。Pod Security Admission は、組み込みの Kubernetes PodSecurity アドミッション コントローラを使用して、Namespace ラベルに基づいて Kubernetes Pod セキュリティ標準から事前定義されたルールを適用します。pss-baseline-v2022 バンドルは baseline レベルに対応し、pss-restricted-v2022 バンドルは restricted レベルに対応します。

Pod Security Admission は、ホストパス、ユーザー、機能、sysctl の許可リストなど、psp-v2022 バンドルのすべての制御をカバーしているわけではありません。これらの制御には ValidatingAdmissionPolicies を使用します。Pod Security Admission では、exemptImages パラメータを使用する Policy Controller の制約など、特定のイメージを除外することもできません。GKE は、Pod セキュリティ アドミッションの除外の構成をサポートしていません。例外が必要な場合は、影響を受けるポリシーに ValidatingAdmissionPolicies を使用します。

Pod Security Admission の構成方法については、PodSecurity を使用して事前定義された Pod レベルのセキュリティ ポリシーを適用するをご覧ください。

セルフマネージド OPA Gatekeeper に移行する

ValidatingAdmissionPolicies で表現できないポリシーには Gatekeeper を選択します。Policy Controller は Gatekeeper をベースとしているため、ConstraintTemplates と制約は Gatekeeper で同じ API を使用します。Policy Controller テンプレート ライブラリのすべてのテンプレートは、ロジックを変更せずに Gatekeeper で動作します。ただし、Gatekeeper は新しい Rego エンジンとより厳格な検証を使用するため、カスタム ConstraintTemplate が拒否される可能性があります。

セルフマネージド Gatekeeper を使用する場合は、Google Cloud が Policy Controller で実行するタスク（各クラスタでの Gatekeeper のインストール、アップグレード、スケーリング、モニタリングなど）をユーザーが実行する必要があります。カスタマーケアは、オープンソースの Gatekeeper をサポートしていません。サポートが必要な場合は、Gatekeeper GitHub Issue Tracker を使用してください。

Gatekeeper には、Policy Controller テンプレート ライブラリやポリシー バンドルは含まれていません。バックアップ ファイルには、クラスタの ConstraintTemplate と制約が含まれています。オープンソースの Gatekeeper ライブラリから取得したテンプレートの場合は、Gatekeeper ポリシー ライブラリのテンプレートを使用できます。テンプレート名は同じですが、パラメータとメッセージはバージョンによって異なる場合があります。

ポリシーを Gatekeeper に移行する手順は次のとおりです。

1. 省略可: Policy Controller の交換中に違反措置のギャップを許容できない場合は、まず最も重要なポリシーを ValidatingAdmissionPolicies に移行します。これらの ValidatingAdmissionPolicyBinding で gatekeeper-system Namespace が除外され、Gatekeeper のインストール ジョブがブロックされないようにします。Policy Controller を削除すると、対応する Gatekeeper 制約を適用するまで、クラスタは Gatekeeper ポリシーの適用を停止します。ValidatingAdmissionPolicies は Policy Controller や Gatekeeper に依存しないため、引き続き適用されます。

2. カスタム ConstraintTemplate を使用する場合は、インストールする Gatekeeper バージョンの gator コマンドライン ツールを使用して、各カスタム テンプレート マニフェストをテストします。

   gator test --filename=TEMPLATE_FILE
   

   TEMPLATE_FILE は、ConstraintTemplate マニフェスト ファイルのパスに置き換えます。Policy Controller を削除する前に、Gatekeeper が拒否するカスタム ConstraintTemplate を修正します。

3. GitOps ツールを使用して Git リポジトリから制約をデプロイする場合は、制約で使用する ConstraintTemplate を準備し、Gatekeeper のインストール時にリポジトリに追加します。そうしないと、ConstraintTemplates が存在しなくなるため、Policy Controller を削除した後に制約を適用できなくなります。

4. Policy Controller を削除するの手順に沿って Policy Controller を削除します。Policy Controller がまだ実行されているクラスタに Gatekeeper をインストールしないでください。どちらも gatekeeper-system Namespace、同じ CustomResourceDefinition、同じ Webhook 名を使用します。

5. Helm を使用して Gatekeeper をインストールします。次のセクションの Policy Controller と異なる Gatekeeper の設定の表から選択した設定を使用します。Gatekeeper のインストール方法の詳細については、Gatekeeper のドキュメントのインストールをご覧ください。

   Autopilot クラスタでは、GKE が mutating Webhook のワイルドカード ルールを拒否するため、デフォルトの Helm チャートのインストールが失敗します。disableMutation: true Helm 値を設定するか、mutatingWebhookCustomRules Helm 値を設定して、ミューテーターがターゲットとする特定のリソースのみを一覧表示します。nodes、persistentvolumes、certificatesigningrequests、tokenreviews リソースは含めないでください。

6. バックアップ ファイルで、再適用する各リソースから次のフィールド、ラベル、アノテーションを削除します。

   • status フィールド。
   • metadata セクションの resourceVersion、uid、creationTimestamp、generation、managedFields、ownerReferences フィールド。
   • kubectl.kubernetes.io/last-applied-configuration アノテーション。
   • app.kubernetes.io/managed-by: anthospolicycontroller.googleapis.com ラベル。フリートレベルのデフォルト構成などによって、クラスタで Policy Controller が再度有効になると、このラベルを持つリソースが管理され、変更または削除できるようになります。
   • キーに policycontroller. 接頭辞が付いているラベルとアノテーション。

7. 制約で使用する ConstraintTemplate を適用し、Gatekeeper が各テンプレートの CustomResourceDefinition を作成したことを確認します。

   kubectl get constrainttemplates \
       -o custom-columns='NAME:.metadata.name,CREATED:.status.created'
   

   すべてのテンプレートの CREATED 列に true 値が表示されたら、制約を適用します。

Policy Controller と異なる Gatekeeper の設定

Gatekeeper をインストールする前に、次の表で Gatekeeper Helm チャートのデフォルトが Policy Controller と異なる設定を確認してください。

Policy Controller のデフォルトと Gatekeeper Helm チャートのデフォルトの比較

設定	Policy Controller のデフォルト	Gatekeeper Helm チャートのデフォルト	推奨事項
ミューテーション（変化）	有効にしない限りオフ	オン	ミューテーションを使用しない場合は、disableMutation: true Helm 値を設定します。Autopilot クラスタでは、disableMutation: true Helm 値を設定するか、ワイルドカードや制限付きリソースを使用せずに mutatingWebhookCustomRules Helm 値を構成する必要があります。これらの値のいずれかを指定しない場合、GKE はインストールを拒否します。
Namespace を除外する	gatekeeper-system Namespace と exemptableNamespaces リスト内の Namespace	Gatekeeper がインストールされている Namespace	除外する Namespace を controllerManager.exemptNamespaces Helm 値に追加します。Gatekeeper は、admission.gatekeeper.sh/ignore ラベルを持つ Namespace への変更を拒否します。ただし、それらの Namespace が除外されている場合は除きます。
参照データ	参照バンドル用に自動的に同期	未同期	参照テンプレートが読み取る種類を一覧表示する Gatekeeper Config または SyncSet を作成します。これらの種類が data.inventory オブジェクトに同期されるまで、競合チェックでは違反リクエストが許可され、K8sRequireNamespaceNetworkPolicies ConstraintTemplate などの存在チェックでは、必要なリソースが存在する場合でも、一致したリクエストがすべて拒否されます。
ValidatingAdmissionPolicy の生成	利用不可	CEL コードを含むテンプレートの場合はオン	Policy Controller テンプレートには Rego のみが含まれているため、Gatekeeper は、CEL を ConstraintTemplates に追加した場合にのみ ValidatingAdmissionPolicies を生成します。Webhook で適用を維持するには、defaultCreateVAPForTemplates: false と defaultCreateVAPBindingForConstraints: false の Helm 値を設定します。詳細については、Gatekeeper のドキュメントの Kubernetes Validating Admission Policy との統合をご覧ください。
レプリカとリソース	各コンポーネントに 1 つのレプリカ、メモリ上限は 1,024 MiB	リソース上限が異なる 3 つの Webhook レプリカ	現在の使用量に基づいて、レプリカ数とリソース上限を構成します。
画像	Google マネージド レジストリから pull された	Docker Hub から pull されたイメージ（openpolicyagent/gatekeeper、openpolicyagent/gatekeeper-crds、curlimages/curl イメージ）	プライベート クラスタまたは Binary Authorization を適用するクラスタの場合は、3 つのイメージすべてを Artifact Registry にミラーリングし、チャート内のイメージ値をオーバーライドします。curlimages/curl イメージをミラーリングしない場合は、Webhook プローブジョブを無効にします。

デフォルトでは、Gatekeeper は Prometheus 指標のみを公開します。その指標名は、Policy Controller が Cloud Monitoring に送信する名前とは異なります。Policy Controller の指標を使用するダッシュボードとアラートを更新します。

ミューテーション ポリシーを移行する

Policy Controller でミューテーションを有効にした場合は、ミューテーターを一覧表示します。

kubectl get assign,assignmetadata,assignimage,modifyset

各ミューテーターについて、次のいずれかのオプションを選択します。

• MutatingAdmissionPolicy: GKE バージョン 1.36 以降で MutatingAdmissionPolicy を使用できます。ValidatingAdmissionPolicy と同様に、MutatingAdmissionPolicy は CEL 式を使用し、Webhook なしで API サーバーで実行されます。Kubernetes は、ValidatingAdmissionPolicies の前にすべての MutatingAdmissionPolicies を実行します。そのため、これらを一緒にテストして、ミューテーションによって ValidatingAdmissionPolicy が有効なマニフェストを拒否しないことを確認してください。Autopilot クラスタでは、GKE は MutatingAdmissionPolicy からマネージド Namespace を除外します。ミューテーション ポリシーの詳細については、Kubernetes ドキュメントのミューテーション アドミッション ポリシーをご覧ください。
• セルフマネージド Gatekeeper: Standard クラスタでは、Gatekeeper がデフォルトでミューテーションを有効にするため、ミューテーターは変更なしで動作します。Autopilot クラスタでは、Gatekeeper チャートで mutatingWebhookCustomRules Helm 値を設定して、ワイルドカード ルールの代わりに、ミューテーターがターゲットとする特定のリソースを一覧表示する必要があります。詳細については、GKE Autopilot のセキュリティ対策をご覧ください。Gatekeeper をインストールしたら、制約の場合と同様に、ミューテーターのバックアップ ファイルから Policy Controller のメタデータを削除し、ミューテーターを再適用します。

ビルド パイプラインでポリシー チェックを更新する

ビルド パイプラインは、デプロイ前にマニフェストを Policy Controller の制約に照らしてチェックすることがあります。たとえば、パイプラインで kpt の gatekeeper 関数または gator コマンドライン ツールを使用している場合があります。詳細については、CI パイプラインで会社のポリシーに照らしてアプリの状態を検証するをご覧ください。

パイプラインでマニフェストがチェックされる場合は、置換用に更新します。

• Gatekeeper を使用している場合は、パイプラインを保持できます。gator コマンドまたは kpt コマンドのファイルパスまたはディレクトリ パスを更新して、クリーンアップされた Gatekeeper ConstraintTemplate と制約マニフェストを含むリポジトリまたはディレクトリを参照します。

• ValidatingAdmissionPolicies を使用している場合、これらのツールはポリシーを評価しません。代わりに、Deny アクションを使用する ValidatingAdmissionPolicies と ValidatingAdmissionPolicyBindings を含むテストクラスタに対して、サーバーサイドのドライランを実行します。

  kubectl apply --dry-run=server -f MANIFEST_DIRECTORY
  

  MANIFEST_DIRECTORY は、マニフェストを含むディレクトリに置き換えます。ValidatingAdmissionPolicy がマニフェストを拒否すると、コマンドは失敗します。

違反報告を置き換える

ValidatingAdmissionPolicy にはダッシュボードは含まれておらず、クラスタにすでに存在するリソースは監査されません。代わりに次のメソッドを使用します。

• 警告: ValidatingAdmissionPolicyBinding が Warn アクションを使用している場合、API サーバーはリクエストを送信したクライアント（kubectl コマンドライン ツールなど）に警告を返します。Deployment 内の Pod など、コントローラが作成する Pod の場合、コントローラは警告を受け取ります。

• 監査ログ: ValidatingAdmissionPolicyBinding が Audit アクションを使用する場合、API サーバーは失敗した検証ごとに監査ログエントリにアノテーションを付けます。GKE は、作成、更新、削除のリクエストを Cloud Logging の管理アクティビティ監査ログに書き込みます。失敗した検証を見つけるには、ログ エクスプローラで次のクエリを実行します。

  resource.type="k8s_cluster"
  logName:"cloudaudit.googleapis.com%2Factivity"
  labels."validation.policy.admission.k8s.io/validation_failure":*
  

既存のリソースのコンプライアンス レポートとして dryrun 違反措置を含む制約を使用している場合、ValidatingAdmissionPolicies はそのレポートを置き換えることができません。これらのポリシーは、セルフマネージド Gatekeeper に保持します。監査コントローラは、スケジュールに従って既存のリソースをチェックします。

Policy Controller を削除する

クラスタから Policy Controller を削除する前に、次の操作を行います。

• ValidatingAdmissionPolicies または Pod Security Admission に移行したポリシーが適用されていること、ConstraintTemplates、制約、ミューテーターのバックアップがあることを確認します。Policy Controller を削除すると、その CustomResourceDefinition が削除されます。これにより、作成した ConstraintTemplate、制約、ミューテーターなど、クラスタ上のすべての ConstraintTemplate、制約、ミューテーターが削除されます。
• Config Sync や Argo CD などの GitOps ツールを使用して Git リポジトリから制約をデプロイする場合は、置き換えられた制約をリポジトリから削除します。クラスタから制約が削除されていることを確認します。
• 省略可: Policy Controller Webhook に依存するものがないことを確認するには、まず Policy Controller を一時停止します。一時停止すると、Webhook 構成のみが削除されます。これは復元できます。

Policy Controller を削除する手順は次のとおりです。

1. クラスタから Policy Controller をアンインストールします。

   gcloud container fleet policycontroller disable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   次のように置き換えます。

   • MEMBERSHIP_NAME: Policy Controller をアンインストールする登録済みクラスタのメンバーシップ名。複数のクラスタから Policy Controller をアンインストールするには、メンバーシップ名のカンマ区切りのリストを指定するか、--memberships=MEMBERSHIP_NAME フラグを --all-memberships フラグに置き換えます。
   • PROJECT_ID: フリートホスト プロジェクトの ID。

2. Policy Controller がクラスタからアンインストールされたことを確認します。

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

   各メンバーシップの最上位の policycontroller.state フィールドの値が DECOMMISSIONING ではなく NOT_INSTALLED になるまで待ちます。CustomResourceDefinition のクリーンアップが完了する前に、個々の componentStates エントリが NOT_INSTALLED 状態になります。

   セルフマネージド Gatekeeper をインストールする場合は、gatekeeper-system Namespace が存在しないことを確認します。

   kubectl get namespace gatekeeper-system
   

   gatekeeper-system Namespace が見つからないことが出力に表示されるまで待ちます。

3. 省略可: 後で登録するクラスタが Policy Controller を取得しないようにするには、フリートレベルのデフォルト構成を削除します。

   gcloud container fleet policycontroller enable \
       --no-fleet-default-member-config \
       --project=PROJECT_ID
   

   このコマンドは、デフォルトの構成のみを削除します。クラスタに Policy Controller はインストールされません。

注意: Policy Controller のアンインストールが完了するまで、Policy Controller フリート機能を削除したり、クラスタの登録を解除したりしないでください。それ以外の場合、Policy Controller は管理なしでクラスタ上で実行され続けます。Policy Controller を削除するために gcloud container fleet policycontroller detach コマンドを使用しないでください。このコマンドは管理を停止し、Policy Controller を実行したままにします。

フリート外のクラスタから Policy Controller を削除する

gcloud container fleet policycontroller disable コマンドは、フリートが管理するクラスタからのみ Policy Controller を削除します。クラスタは、次のケースでフリート管理なしで Policy Controller を実行できます。

• ConfigManagement Operator を使用して Policy Controller をインストールした。
• Policy Controller のアンインストールが完了する前に、フリートからクラスタの登録を解除したか、gcloud container fleet policycontroller detach コマンドを実行した。

これらのクラスタから Policy Controller を削除するには、クラスタをフリート管理下に置き、Policy Controller をアンインストールします。

1. ポリシーのインベントリと分類の説明に従って、ConstraintTemplate、制約、同期構成、ミューテーターをバックアップします。ConfigManagement Operator のインストールから取得したバックアップからメタデータをクリーンアップする場合は、ownerReferences フィールドと policycontroller.* メタデータに加えて、configmanagement.gke.io/* ラベルと k8s-app: kubernetes-config-management ラベルも削除します。

2. ConfigManagement Operator を使用して Policy Controller をインストールした場合は、クラスタの ConfigManagement カスタム リソースから policyController フィールドを削除します。調整が完了するまで待ちます。調整には約 2 分かかります。次に、gatekeeper-system Namespace がまだ存在するかどうかを確認します。

   kubectl get namespace gatekeeper-system
   

   ConfigManagement Operator バージョン 1.17 以前では、policyController フィールドを削除すると、Policy Controller が自動的にアンインストールされます。gatekeeper-system Namespace が見つからない場合は、このセクションの残りの手順をスキップします。ConfigManagement Operator バージョン 1.18 以降では、gatekeeper-system Namespace がクラスタに残るため、次の手順に進みます。

3. クラスタがフリートに登録されていない場合は、登録します。詳細については、 Google Cloud のクラスタをフリートに登録するをご覧ください。

4. クラスタでミューテーションが有効になっているかどうかを確認します。

   kubectl get mutatingwebhookconfiguration \
       gatekeeper-mutating-webhook-configuration
   

5. クラスタのメンバーシップで Policy Controller を有効にして、フリートが既存のインストールの管理を引き継ぐようにします。上記のコマンドで gatekeeper-mutating-webhook-configuration リソースが返された場合は、--mutation フラグを追加して、フリートがクラスタ スコープのミューテーション リソースを採用し、後で削除するようにします。

   gcloud container fleet policycontroller enable \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID
   

   次のように置き換えます。

   • MEMBERSHIP_NAME: 登録済みクラスタのメンバーシップ名。
   • PROJECT_ID: フリートホスト プロジェクトの ID。

6. メンバーシップの policycontroller.state フィールドの値が ACTIVE になるまで待ちます。

   gcloud container fleet policycontroller describe \
       --memberships=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       --format="yaml(membershipStates)"
   

7. Policy Controller を削除するの手順に沿って、Policy Controller をアンインストールします。セルフマネージド Gatekeeper をインストールしない場合は、gatekeeper-system Namespace が削除された後に、残りの制約 CustomResourceDefinition を削除します。

   kubectl get crd -o name \
       | grep '\.constraints\.gatekeeper\.sh$' \
       | xargs -r kubectl delete
   

8. 省略可: この手順を完了するためだけにクラスタを登録した場合は、describe コマンドでメンバーシップの NOT_INSTALLED 状態が表示された後に登録を解除します。--enable-fleet フラグを使用して登録したクラスタの場合は、gcloud container fleet memberships unregister コマンドではなく、--clear-fleet-project フラグを指定して gcloud container clusters update コマンドを実行します。詳細については、クラスタの登録解除をご覧ください。

次のステップ

• Validating Admission Policy（Kubernetes ドキュメント）を読む。
• PodSecurity を使用して事前定義された Pod レベルのセキュリティ ポリシーを適用する方法を確認する。
• Gatekeeper のドキュメントを読む。