Admission Controlとポリシー実行（Webhook/CEL）

admission control とは何か

Kubernetes の API サーバーは、クライアントから来たリクエスト（Pod を作る、Deployment を更新する等）を、そのまま etcd に書き込むわけではありません。書き込みの 直前 に、リクエストを横取りして検査・改変する関門があります。これが admission control（受け入れ制御） です。

ここで重要なのは「いつ」走るかです。API サーバーの処理は固定された順序を持ちます。

1. 認証（Authentication）：誰からのリクエストか確認する。
2. 認可（Authorization）：その人にこの操作の権限があるか判定する（RBAC など）。
3. mutating admission：リクエストの 内容 を改変する（後述）。
4. スキーマ検証：改変後のオブジェクトが OpenAPI スキーマに沿うか検証する。
5. validating admission：内容を検査して可否を返す（後述）。これを通れば etcd に保存される。

認可は「操作してよいか（誰が何をできるか）」を見るのに対し、admission は「その内容が妥当か（この Pod は特権コンテナを使っていないか、ラベルが付いているか）」を見ます。RBAC では表現できない、オブジェクトの中身に踏み込んだルール強制がここで可能になります。

mutating と validating：2段構えとその順序

admission には2種類のフェーズがあり、順序が決まっている ことが設計の根幹です。

• mutating（変更）admission：先に走る。リクエスト中のオブジェクトを 書き換えられる（デフォルト値の注入、サイドカーの追加、ラベルの付与など）。
• validating（検証）admission：後に走る。オブジェクトを 見て可否だけを返す。受理（allow）か拒否（deny）かで、内容は変えない。

なぜ mutating が先なのか。validating は「最終的に保存される姿」を検査する必要があるからです。もし validating の後に mutating が改変したら、検証を通り抜けたオブジェクトが検証後に書き換わり、検証が無意味になります。だから順序は 必ず mutating → validating で固定され、validating フェーズを通過したオブジェクトはもう改変されません。

API サーバー内部では、この2フェーズの間に 再エンコード／再検証 が挟まります。全 mutating プラグインが適用された結果のオブジェクトが、validating に渡される確定形になります。

webhook の仕組み：API サーバーが外部を呼ぶ

組み込みの admission プラグイン（NamespaceLifecycle など）はコンパイル済みでカーネルに固定ですが、ユーザーが独自ルールを足す主流の手段が admission webhook です。ValidatingWebhookConfiguration / MutatingWebhookConfiguration というリソースで登録します。

動作はシンプルで、しかし危険です。マッチするリクエストが来ると、API サーバーが webhook サーバーに対して同期的に HTTPS POST を送ります。ボディは AdmissionReview オブジェクト（対象リソース・操作種別・ユーザー情報を含む）。webhook は許可／拒否（mutating なら JSON Patch 付き）を AdmissionReview で返します。

この「API サーバーが外部 HTTP を待つ」という構造が、設計上の最大の注意点を生みます。

CEL：webhook なしでポリシーを書く

webhook は柔軟ですが、外部サーバーの運用・証明書・可用性という重荷を伴います。これを避けるために、API サーバーに CEL（Common Expression Language） が組み込まれました。ValidatingAdmissionPolicy（および mutating 版）として、外部プロセスなしに API サーバー内でポリシーを評価します。

CEL は安全な式言語で、ループや任意 I/O を持たず、評価コストに上限がある（チューリング完全ではない）よう設計されています。これにより API サーバー内で安全に同期評価でき、webhook のような外部呼び出し・ネットワーク往復・障害点がありません。

# webhook 不要。API サーバー内で CEL を評価
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: replica-limit
spec:
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 5"   # replicas が 5 以下のみ許可
      message: "replicas は 5 以下にしてください"

CEL は軽量で障害点が増えない一方、表現力に限界があります。外部データ参照（「この Image は脆弱性スキャンを通ったか」を別 DB に問い合わせる等）や複雑なロジックは苦手で、そこは依然 webhook ＋外部エンジンの出番です。判断軸は「API サーバー内で完結する単純な不変条件は CEL、外部知識や複雑な合成判断は webhook」です。

OPA/Gatekeeper・Kyverno：ポリシーエンジンの3系統

実務では、生の webhook を自作するより ポリシーエンジン を webhook の背後に置くのが一般的です。代表が OPA/Gatekeeper と Kyverno で、CEL を加えた3系統を比べると性格がはっきりします。

• OPA/Gatekeeper：汎用ポリシーエンジン OPA を Kubernetes 用に包んだもの。ルールは Rego で書き、ConstraintTemplate（ルールの型）と Constraint（適用パラメータ）に分離する設計です。Kubernetes 以外でも使える汎用性が強みですが、Rego の学習コストが高めです。
• Kyverno：Kubernetes 専用に作られ、ポリシーを YAML（CRD） で書きます。新言語を学ばずに済み、検証（validate）だけでなく 改変（mutate） や 生成（generate：namespace 作成時に既定の NetworkPolicy を自動生成等） も同じ枠組みで書けるのが特徴です。

3つとも本質は同じ「admission のタイミングでオブジェクトを検査・改変する」仕組みで、違いは どこで評価するか（内蔵か外部か）と 何で書くか（CEL/Rego/YAML）です。

配置上の設計指針

admission を入れる際は、可用性とのトレードオフを常に意識します。

1. まず CEL を検討：API サーバー内で完結する単純なルール（ラベル必須、replicas 上限、特権コンテナ禁止）は CEL で書き、外部依存を増やさない。
2. webhook は対象を絞る：matchConditions（CEL 前段フィルタ）・namespaceSelector・objectSelector で、本当に必要なリクエストだけを捕まえる。捕まえる範囲が広いほど API 全体のレイテンシと障害リスクが増えます。
3. failurePolicy を意図的に選ぶ：セキュリティ強制系（特権 Pod 拒否など）は Fail（webhook が落ちたら拒否＝安全側）、補助的なラベル付与などは Ignore（落ちても素通し）と、ルールの性質で使い分けます。
4. 冪等に作る：mutating は順序保証がなく再呼び出しもあるため、何度適用しても同じ結果になるよう設計します。

admission はサービスメッシュのサイドカー自動注入（/devops/service-mesh/）の正体でもあり、デプロイ戦略（/devops/deployment-strategies/）の安全ガードや、CI/CD（/devops/ci-cd/）でクラスタ手前で弾けない実行時ポリシーの最後の砦としても機能します。「クラスタに入る前」に強制できるからこそ、構成のドリフトを設計段階で封じられるのが admission control の価値です。

まとめ

• admission は 認証・認可の後、etcd 保存の直前 に走り、書き込み系操作の 内容 を検査・改変する関門。
• フェーズは mutating（改変が先）→ validating（検証が後） で固定。validating 通過後はオブジェクトを変えられない。
• webhook は API サーバーが同期 HTTP で外部を呼ぶ ため、failurePolicy・timeout・対象範囲の設計を誤るとクラスタごと詰まる。
• ポリシー実行は CEL（内蔵・軽量）／OPA・Gatekeeper（Rego）／Kyverno（YAML） の3系統。単純な不変条件は CEL、複雑・外部依存の判断は webhook ＋エンジンで使い分ける。