OPA Gatekeeper本番段階導入｜AuditからEnforceモード移行とポリシー違反切り戻し

Audit モードが「仮運用」でしかない理由と移行の全体像

OPA Gatekeeper を Kubernetes クラスタに導入した直後は enforcementAction: audit の状態で運用するのが一般的なプラクティスです。Audit モードではポリシー違反がログに記録されるだけで、リソースの作成・更新はブロックされません。クラスタを壊さずにどのリソースが違反しているかを把握できる反面、セキュリティ要件やコンプライアンス要件を実際には満たせていません。「Gatekeeper を入れた」という状態と「Gatekeeper でポリシーを強制している」という状態は、運用上まったく異なります。

Enforce モードへの移行は段階的に行うのが安全です。Gatekeeper v3.7 以降では audit と deny の中間にあたる warn という enforcementAction が利用できます。warn は API レスポンスに警告メッセージを返しますがリソースはブロックしません。CI/CD パイプラインや運用チームが警告を認識できる体制を整えてから deny へ進む2段階移行が推奨されます。

移行の全体像は次のとおりです。

• ステップ 1：Audit モードで違反件数・対象リソースを棚卸しする
• ステップ 2：enforcementAction: warn に切り替えて CI/CD の挙動を確認する
• ステップ 3：違反リソースを修正または例外（Exclusion）として登録する
• ステップ 4：enforcementAction: deny に切り替える
• ステップ 5：切り替え後の動作を検証し、異常があれば切り戻す

移行前チェック — 既存の違反件数と影響範囲を把握する

Gatekeeper は Constraint リソースの .status.violations フィールドに違反情報を蓄積します。まず現在の違反状況を確認します。

# クラスタ全体の Constraint 一覧と違反件数を確認
kubectl get constraints -A

# 特定の Constraint の違反詳細を確認
kubectl get k8srequiredlabels.constraints.gatekeeper.sh require-namespace-labels \
  -o jsonpath='{.status.violations}' | jq .

違反リソースの出力には kind、name、namespace、message が含まれます。この一覧をもとに対応方針を決めます。主な対応は次の3通りです。

• 修正する：違反しているリソースのマニフェストを修正して再デプロイする
• 例外登録する：Constraint の spec.match.excludedNamespaces や spec.match.namespaces で適用範囲を絞る
• ポリシーを見直す：違反が多すぎる場合は ConstraintTemplate の要件定義が実態と乖離している可能性があるため、ポリシーの前提条件を再確認する

違反件数がゼロに近い状態か、残った違反がすべて意図的な例外として処理済みになってから次のステップへ進みます。Enforce モードに切り替えた後は違反しているリソースの更新もブロックされるため、対処が終わっていないリソースが残ると予期せぬ障害につながります。よくあるつまずきとして、kube-system など管理系 Namespace のリソースが違反しているケースがあります。spec.match.excludedNamespaces で除外しておくか、事前に修正してから進めるのが安全です。

enforcementAction を段階的に切り替える手順

Constraint の spec.enforcementAction フィールドを変更することでモードを切り替えます。ConstraintTemplate 側の変更は不要です。

まず warn へ切り替えます。

kubectl patch k8srequiredlabels.constraints.gatekeeper.sh require-namespace-labels \
  --type='merge' \
  -p '{"spec":{"enforcementAction":"warn"}}'

warn への切り替え後、CI/CD パイプラインで実際にデプロイを試行し、警告メッセージが想定どおりのリソースに対して出ているかを確認します。kubectl apply の出力には Warning: プレフィクスで違反メッセージが表示されます。想定外のリソースへの警告が出ている場合は Constraint の spec.match 条件を調整します。

問題がなければ deny へ切り替えます。

kubectl patch k8srequiredlabels.constraints.gatekeeper.sh require-namespace-labels \
  --type='merge' \
  -p '{"spec":{"enforcementAction":"deny"}}'

複数の Constraint を一括で切り替える場合はスクリプト化してリスト管理すると抜け漏れを防げます。Argo CD や Flux CD を使っている環境では Constraint マニフェストをリポジトリで管理し、ブランチ戦略でロールバック経路を確保しておくと安全です。Constraint ごとに個別に deny へ移行する方が、問題発生時の切り分けが容易です。すべてを一度に切り替えるのは避けることを推奨します。

Enforce 移行後の動作検証とモニタリング

deny への切り替え直後は、Admission Webhook が正常に機能しているかを確認します。

# Gatekeeper の Pod が Running かどうか確認
kubectl get pods -n gatekeeper-system

# ValidatingWebhookConfiguration の状態確認
kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -o yaml

Gatekeeper の ValidatingWebhookConfiguration には failurePolicy の設定があります。デフォルトは Ignore で、Gatekeeper Pod が応答できない場合はポリシーチェックをスキップしてリソース作成を許可します。セキュリティ要件が厳しい環境では Fail に設定することもありますが、Fail の場合は Gatekeeper 自体の可用性がクラスタ全体のリソース操作に影響します。本番環境では failurePolicy の選択を意図的に行い、チームで共有しておくことが重要です。

切り替え後のモニタリングでは次の点を観察します。

• Gatekeeper コントローラの Pod ログに ERROR や Admission Webhook 関連のエラーが出ていないか
• CI/CD パイプラインのデプロイジョブが新たに失敗していないか
• kubectl get constraints -A で .status.violations の件数が急増していないか（Audit は deny モードでも引き続き記録される）
• Prometheus + Gatekeeper Exporter を使っている場合は gatekeeper_violations_total メトリクスの推移を確認する

ポリシー違反による障害発生時の切り戻し手順

Enforce モード移行後に「デプロイが通らない」「既存リソースの更新ができない」などの障害が発生した場合は、原因を特定しながら迅速に切り戻します。

パターン 1：特定の Constraint による誤ブロック

対象の Constraint を audit に戻します。

kubectl patch k8srequiredlabels.constraints.gatekeeper.sh require-namespace-labels \
  --type='merge' \
  -p '{"spec":{"enforcementAction":"audit"}}'

これで当該ポリシーによるブロックは即座に解除されます。GitOps 管理下にある場合はマニフェストも合わせて変更し、コントローラとの差分（ドリフト）が発生しないようにします。

パターン 2：Gatekeeper Pod 自体の障害で全リソース操作がブロックされる

failurePolicy: Fail を設定している場合、Gatekeeper Pod がクラッシュすると新規リソース作成がすべてブロックされます。この場合は ValidatingWebhookConfiguration を一時的に削除します。

# 緊急時のみ — Webhook を一時削除してブロックを解除
kubectl delete validatingwebhookconfiguration gatekeeper-validating-webhook-configuration

Webhook の削除後は Gatekeeper Pod を再起動するか、Helm でアップデートして再インストールします。再起動後に Gatekeeper が自動で Webhook を再登録します。この操作によりクラスタへの全 API アクセスが再び通るようになるため、緊急対応の手順書に明記しておくことを推奨します。また、Webhook 削除から再登録までの間はポリシーが適用されない状態になるため、その時間帯に行われた変更を事後に監査する手順も合わせて準備しておくと安心です。

パターン 3：既存ワークロードが再作成できなくなる

ノードのメンテナンスや Pod の再スケジュールで既存の Pod が再作成される際に Enforce モードのポリシーに引っかかるケースがあります。既存の Pod は Admission Webhook の対象外ですが、Deployment の spec 変更によって Pod テンプレートが再評価されると違反が発生します。一般的には、Enforce 移行前に既存リソースの違反を解消しておくことでこのパターンを防げます。発生してしまった場合は、問題の Constraint を audit に戻してから根本原因を修正します。

2026 年の現行環境差分と今後の選択肢

2026 年時点では Gatekeeper は v3.17 以降が主流となっています。現行環境で注意すべき差分を整理します。

Kubernetes 標準の ValidatingAdmissionPolicy（VAP）との関係

Kubernetes 1.30 で GA となった ValidatingAdmissionPolicy は CEL（Common Expression Language）を使ったアドミッションポリシーを OPA/Rego なしで記述できます。シンプルなポリシーであれば Gatekeeper なしで実現できるため、新規クラスタでは VAP と Gatekeeper の役割分担を設計段階から決めておくと運用コストを抑えられます。ただし、Rego の表現力が必要な複雑なポリシーや既存の Gatekeeper Library を活用したい場合は Gatekeeper が引き続き有効です。

Gatekeeper v3.14 以降の CEL サポート

Gatekeeper v3.14 以降では ConstraintTemplate 内で Rego に加えて CEL を使ったポリシー記述が可能になっています。CEL は Rego より学習コストが低く、VAP との親和性も高いため、今後新規にポリシーを追加する際の選択肢として検討できます。既存の Rego ポリシーを即座に移行する必要はありませんが、チームの習熟度に応じて段階的に取り入れることが可能です。

マネージド Kubernetes での注意点

GKE の Policy Controller、AKS の Azure Policy for Kubernetes はいずれも OPA Gatekeeper をベースにしたマネージドサービスです。これらの環境では ValidatingWebhookConfiguration を直接操作できない場合があるため、緊急時の切り戻し手順がセルフホストの Gatekeeper と異なります。マネージドサービスを利用している場合は、各クラウドプロバイダのドキュメントでサポートされる切り戻し方法を事前に確認してください。

Mutation Webhook の安定化

Gatekeeper の Mutation（変更 Webhook）機能は v3.14 以降で安定版として利用できます。Enforce モードのポリシーと組み合わせると、違反しそうなリソースにデフォルト値を自動注入してブロックを回避できる設計も可能です。ただし、Mutation と Validation を組み合わせると動作が複雑になるため、段階的に導入することを推奨します。

Audit から Enforce への移行は1度で完了させようとせず、Constraint ごとに段階的に進めることが現実的な運用です。違反件数が多いポリシーは warn を挟み、CI/CD への影響を確認してから deny に移行するという流れが、本番環境での安全な導入に直結します。切り戻し手順をあらかじめ整備しておくことで、Enforce モードへの移行に対するチームの心理的ハードルも下がります。