Policy Controller

解決する課題

Kubernetes は柔軟ゆえに、特権コンテナ・ルート実行・許可外レジストリのイメージ・ラベル欠落といった「望ましくない構成」も簡単にデプロイできてしまいます。Policy Controller は、こうした構成をデプロイの入口で機械的に検査し、組織のセキュリティ・運用基準に反するものを弾くガードレールを、クラスタを横断して提供します。

• レビューや口頭ルールに頼らず、禁止構成のデプロイを技術的に止めたい（特権昇格、hostPath マウントなど）
• 複数クラスタ・複数チームに、同じセキュリティ基準を一貫して効かせたい
• PSP（PodSecurityPolicy）廃止後の代替として、より柔軟なポリシーエンジンが欲しい
• CIS Benchmark や社内標準への準拠状況を、継続的に可視化・監査したい

主要概念と用語

• OPA Gatekeeper: Policy Controller の基盤となる OSS。Open Policy Agent（OPA）を Kubernetes のアドミッション Webhook として組み込んだもの
• 制約テンプレート（ConstraintTemplate）: ポリシーのロジックを記述した雛形。判定ルールは Rego（OPA のポリシー言語）で書かれ、パラメータを受け取れる
• 制約（Constraint）: テンプレートを具体化したインスタンス。どのリソース種別に・どのパラメータで・どの適用モードで効かせるかを指定する
• 適用モード（enforcementAction）: 違反時の挙動。ブロックする deny、監査ログのみの dryrun、警告を返す warn がある
• 制約テンプレートライブラリ: Google が提供する既製テンプレート群。特権コンテナ禁止や許可レジストリ制限など、よく使うルールがすぐ使える
• ポリシーバンドル（Policy Bundle）: CIS Benchmark や PSS（Pod Security Standards）など、目的別にまとめられた制約のセット
• 監査（Audit）: 既にクラスタ内にある（デプロイ済みの）リソースを定期的に再評価し、ポリシー違反を一覧化する機能
• Config Sync との連携: ポリシー定義を Git で管理し、複数クラスタへ宣言的に配布する（GitOps）構成が一般的

仕様・制限・クォータ

• GKE Enterprise（旧 Anthos）の機能として提供される。GKE のほか、接続済みの他環境クラスタにも展開できる
• アドミッション制御（Webhook）として動作: リソースの作成・更新時に API サーバーから呼ばれ、ポリシー判定を行う。判定対象は Pod に限らず任意の Kubernetes リソース
• デプロイ時の強制と、デプロイ済みリソースの監査の二系統を持つ。前者は新規・更新を入口で弾き、後者は既存の違反を洗い出す
• Rego による表現力: PSP よりも柔軟な条件を記述でき、パラメータ化したテンプレートを再利用できる
• Webhook の可用性に注意: アドミッション Webhook が応答できないと API リクエストに影響しうるため、failurePolicy の設計と Policy Controller 自身の健全性監視が重要
• クォータ・上限: 制約数や評価対象は環境規模に依存する。具体的な上限値は変動しうるため、最新値は公式ドキュメントで確認する

内部の仕組み

Policy Controller は、Kubernetes API サーバーのバリデーティング・アドミッション Webhookとして割り込み、リソースが etcd に永続化される前にポリシー判定を行います。

• リソースの作成・更新要求が API サーバーに届くと、API サーバーは登録済みの Webhook として Gatekeeper を呼び出す
• Gatekeeper は、対象リソースに該当する制約を集め、各制約が参照する制約テンプレートの Rego ロジックで違反の有無を評価する
• 違反があれば、制約の適用モードに従って、要求を拒否（deny）、警告のみ（warn）、または通過させてログ記録（dryrun）する
• 別系統の監査コントローラが、デプロイ済みリソースを定期的に同じ制約で再評価し、違反を制約オブジェクトの status に書き出す

ポリシー定義（テンプレート・制約）は Kubernetes のカスタムリソースなので、Config Sync で Git から各クラスタへ配布すれば、全クラスタに同一ルールを宣言的に効かせられます。

設計パターン / ベストプラクティス

• まず dryrun（監査のみ）で開始し、既存・新規がどれだけ違反するかを可視化してから deny に切り替える
• 既製の制約テンプレートライブラリとポリシーバンドルを活用し、CIS や PSS 準拠を自前 Rego を書かずに始める
• ポリシー定義は **Config Sync で Git 管理（GitOps）**し、レビューと履歴を残しつつ複数クラスタへ一括配布する
• 段階適用: 重大度の高いルール（特権コンテナ・ホスト名前空間など）から deny にし、軽微なもの（ラベル必須など）は warn/dryrun で運用する
• 例外は制約の対象範囲（namespace 除外など）で明示し、抜け穴を最小化・可視化する
• Webhook の failurePolicy を、セキュリティ要件と可用性のバランスで選ぶ（fail-closed は安全だが Webhook 障害時にデプロイが止まる）

運用・監視

• 監査結果を定期的に確認し、デプロイ済みリソースのポリシー違反（特に強制前の母数）を把握する
• 制約オブジェクトの status で各制約の違反件数を追い、強制への移行可否を判断する
• Policy Controller / Gatekeeper の Pod の健全性とメトリクスを監視する。Webhook がダウンするとアドミッションに影響しうるため、可用性を確保する
• デプロイがブロックされたら、どの制約のどのパラメータに違反したかを拒否メッセージで特定し、マニフェスト側を修正する
• ポリシー変更は GitOps の PR レビューを通し、いきなり全クラスタに強制ルールを撒かない運用にする

コスト

Policy Controller は GKE Enterprise（Anthos）の機能として提供されるため、コストは基本的に GKE Enterprise のサブスクリプション／管理対象クラスタ（vCPU）課金に含まれます。Policy Controller 単体での従量課金というより、Enterprise 機能をまとめて利用する前提です。

セキュリティ

• 入口での強制により、特権コンテナ・ルート実行・許可外イメージなどの危険な構成を本番に入れさせない
• PSP の後継として、Pod Security Standards 相当の制約を柔軟に表現・適用できる
• ポリシーの変更権限を限定し、ガードレールそのものを無効化・緩和されないよう IAM／RBAC で統制する
• 例外（namespace 除外・特定 SA の許可など）は最小化して可視化し、抜け穴を恒常化させない
• Config Sync の GitOps と組み合わせ、ポリシーのドリフトを検出・是正して一貫性を保つ

関連サービス・比較

Policy Controller はしばしば Binary Authorization と対比されます。Binary Authorization が「信頼できるイメージか（署名検証）」に特化するのに対し、Policy Controller は「Kubernetes リソース構成が組織基準に沿うか」という広い構成ガバナンスを担い、両者は補完関係にあります。

ハンズオン / CLI例

# GKE Enterprise の Fleet 機能として Policy Controller を有効化する
gcloud container fleet policycontroller enable \
  --memberships=CLUSTER_NAME

# 監査からブロックへ：適用モードを dryrun で確認後に deny へ切り替える想定の制約例
# （以下は kubectl で適用する制約マニフェストのイメージ）
cat <<'EOF' | kubectl apply -f -
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: deny-privileged-containers
spec:
  enforcementAction: dryrun   # まずは監査のみ。問題なければ deny へ
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
EOF

# 監査結果（違反件数）を確認する
kubectl get k8spspprivilegedcontainer deny-privileged-containers \
  -o jsonpath='{.status.totalViolations}'

# 設定状態を確認する
gcloud container fleet policycontroller describe \
  --memberships=CLUSTER_NAME