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

Kubernetes のアドミッションは、API server のリクエストパイプラインにおいて認証と認可の後、かつオブジェクトが etcd に書き込まれる前に位置します。順序付けられた二段階で動作し、mutating コントローラはオブジェクトを書き換え(既定値の付与、Istio/Envoy サイドカーの注入)、続いて validating コントローラが受理または拒否します。組み込みコントローラには NamespaceLifecycle、ResourceQuota、ServiceAccount、PodSecurity、ImagePolicyWebhook があります。外部ポリシエンジンは MutatingWebhookConfiguration/ValidatingWebhookConfiguration として登録し、AdmissionReview の JSON ペイロードを受け取って許可/拒否の判定を返します。ここが OPA Gatekeeper や Kyverno の接続点です。1.30(GA)以降、ValidatingAdmissionPolicy は CEL 式を API server に直接埋め込み、webhook へのネットワークホップを排除します。

アドミッションは、サプライチェーンおよびワークロードのポリシを強制する中心点です。イメージ署名の検証(Sigstore/cosign)、Pod Security Standards、ラベル統制などです。そのため webhook 自体が攻撃対象になります。2025 年 3 月の IngressNightmare(CVE-2025-1974、CVSS 9.8、および CVE-2025-1097/1098/24514)では、認証されていない攻撃者が ingress-nginx の admission エンドポイントに到達して NGINX ディレクティブを注入し、コントローラ Pod での RCE とクラスタ全体のシークレット窃取の可能性を招きました。アドミッションエンドポイントを決してネットワークに公開してはならないという痛烈な教訓です。

運用面では、到達不能な webhook に対する failurePolicy: Fail はクラスタを機能不全に陥らせる可能性があるため、namespaceSelector で webhook の適用範囲を絞り、timeoutSeconds を短く設定し、kube-system を除外します。

flowchart LR
  U[kubectl / クライアント] --> API[API server]
  API --> AUTHN[認証]
  AUTHN --> AUTHZ[認可 RBAC]
  AUTHZ --> MUT[Mutating アドミッション -> 注入 / 既定値]
  MUT --> SCH[スキーマとオブジェクトの検証]
  SCH --> VAL[Validating アドミッション + VAP CEL]
  VAL --> D{許可?}
  D -->|拒否| ERR[クライアントへ要求を拒否]
  D -->|許可| ETCD[(Persist to etcd)]
  VAL -.policy.-> ENG[OPA Gatekeeper / Kyverno]