はじめに
Kubernetesのセキュリティ・ガバナンスを理解するには、単にWebhookやPSA（Pod Security Admission）を知るだけでは不十分です。 実際には、Kubernetes API Serverが複数のAdmission Pluginsを組み合わせて動作し、それらの有効化はAPI Serverフラグによって制御されています。
今回の記事では、以下の観点からAPI ServerフラグとAdmission Pluginの設定・内部構造を詳細に解説します。
- API ServerのAdmission Plugin有効化フラグ
- Admission chain（順序）の内部動作
- PodSecurity（PSA）の有効化方法
- WebhookのEnablementとConfigurationフロー
- プラグイン間の依存関係と注意点
1. Admission Pluginsとは？
Admission Pluginsは、Kubernetes API Serverがリクエストを処理する際に実行するミドルウェア的な検証ステップです。
プラグインの種類
- Validating Plugins（拒否可能）
- Mutating Plugins（オブジェクト書き換え）
例：代表的なAdmission Plugins
- PodSecurity（PSA）
- MutatingAdmissionWebhook
- ValidatingAdmissionWebhook
- NamespaceLifecycle
- LimitRanger
- ResourceQuota
これらは API Server 起動時のフラグで有効化されます。
2. API Serverフラグ：Admission関連の基本設定
API Serverの主要なAdmission制御フラグは以下です：
--enable-admission-plugins --disable-admission-plugins --admission-control-config-file 例：Kubeadm環境での起動設定
通常、以下のファイルに設定します：
/etc/kubernetes/manifests/kube-apiserver.yaml 抜粋：
... spec: containers: - command: - kube-apiserver - --enable-admission-plugins=PodSecurity,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,LimitRanger,ResourceQuota - --admission-control-config-file=/etc/kubernetes/admission/config.yaml ... 3. Pod Security Admission（PSA）の内部Enablement
PSAは Kubernetes v1.23+ で追加された Built-in Admission Plugin です。
有効化フラグ：
--enable-admission-plugins=PodSecurity PSAが有効になったAPI Serverは NamespaceのPSSラベルを参照し、PodのSpecをチェックします。
PSAは以下の順序で必ず実行される
Mutating Webhooks → PodSecurity → Validating Webhooks この順序は固定で、ユーザーが変更することはできません。
4. Admission chain の内部順序
Kubernetesでは Admission Plugins が以下の順序で実行されます：
Mutatingフェーズ
1. NamespaceLifecycle 2. MutatingAdmissionWebhook 3. （他のMutating Plugins） Validatingフェーズ
1. PodSecurity 2. ValidatingAdmissionWebhook 3. ResourceQuota 4. （他のValidating Plugins） この順序はクラスタのセキュリティ挙動に大きく影響します。
5. Webhookの有効化に必要なフラグ
Webhookを有効化するには、以下のAdmission Pluginsが必要です：
--enable-admission-plugins=MutatingAdmissionWebhook,ValidatingAdmissionWebhook 同時に、API Serverは TLS を要求するため、証明書も必要です。
実際の設定例：
--admission-control-config-file=/etc/kubernetes/admission/webhook-config.yaml --client-ca-file=/etc/kubernetes/pki/ca.crt Webhookを使用しないと Gatekeeper・Kyverno は動作しません。
6. admission-control-config-file の詳細
Webhookの失敗時挙動などは設定ファイルで定義します。
apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: - name: ValidatingAdmissionWebhook configuration: apiVersion: apiserver.config.k8s.io/v1 kind: WebhookAdmission timeoutSeconds: 5 failurePolicy: Fail 設定可能項目：
- timeoutSeconds
- failurePolicy
- matchPolicy
- namespaceSelector
7. disable-admission-plugins の注意点
以下のプラグインは絶対に無効化してはいけません：
- NamespaceLifecycle
- ServiceAccount
- NodeRestriction
- LimitRanger
- ResourceQuota
これらを disable するとクラスタが壊れます。
例（悪い例）：
--disable-admission-plugins=NamespaceLifecycle # 絶対ダメ！ 8. API Serverフラグとコンポーネントの依存関係
Admission Plugins は API Server に完全依存します。Controller Manager や Scheduler では設定しません。
依存関係まとめ：
| 機能 | 依存コンポーネント |
|---|---|
| PSA | API Server |
| Webhook | API Server（TLS必須） |
| ResourceQuota | API Server + Controller Manager |
| Defaulting（mutate） | API Server |
9. 実務での推奨設定まとめ
本番クラスタでは以下が必須です：
--enable-admission-plugins=PodSecurity,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,LimitRanger,ResourceQuota,ServiceAccount,NodeRestriction --admission-control-config-file=/etc/kubernetes/admission/config.yaml --client-ca-file=/etc/kubernetes/pki/ca.crt さらに：
- PSA → ベースラインセキュリティ
- Webhook（Gatekeeper/Kyverno） → 拡張ルール
- ResourceQuota → 資源制限
- LimitRanger → defaultリソース制限
つまり、API Serverフラグはクラスタガバナンスの根幹です。
まとめ
- Admission PluginsはAPI Serverのミドル層として動作
- フラグでEnable/Disable可能（依存関係に要注意）
- PSS / PSAはBuilt-in Pluginとして固定順序で実行
- WebhookはMutating→PSA→Validatingの順序で評価
- 設定ファイルでtimeout・failurePolicyを制御可能
API Serverフラグを理解することで、Kubernetesセキュリティの全体像が一段深く見えるようになります。
