はじめに
Kubernetes 1.25以降、PodSecurityPolicy（PSP）は廃止され、代わりにPod Security Admission（PSA）が標準のセキュリティ制御機構として導入されました。
PSAは単なる「ポリシーの集合」ではなく、Kubernetes API Server内部に組み込まれたAdmission Controllerとして動作します。
本記事では、PSAの内部構造・評価フロー・制御アルゴリズムを技術的に解説します。
1. PSAの全体アーキテクチャ
PSAは、Kubernetes API Serverに内蔵されたBuilt-in Admission Controllerです。
kubectl apply -f pod.yaml ↓ Kubernetes API Server ↓ Mutating Admission Controllers ↓ Validating Admission Controllers ↓ Pod Security Admission（PSA） ↓ etcdへ保存 or 拒否 PSAはValidating Admission Phaseで実行されます。つまり、リソースを書き換えるのではなく、「許可／拒否」を判断します。
はじめに
Kubernetes 1.25以降、PodSecurityPolicy（PSP）は廃止され、代わりにPod Security Admission（PSA）が標準のセキュリティ制御機構として導入されました。
PSAは単なる「ポリシーの集合」ではなく、Kubernetes API Server内部に組み込まれたAdmission Controllerとして動作します。
本記事では、PSAの内部構造・評価フロー・制御アルゴリズムを技術的に解説します。
1. PSAの全体アーキテクチャ
PSAは、Kubernetes API Serverに内蔵されたBuilt-in Admission Controllerです。
kubectl apply -f pod.yaml ↓ Kubernetes API Server ↓ Mutating Admission Controllers ↓ Validating Admission Controllers ↓ Pod Security Admission（PSA） ↓ etcdへ保存 or 拒否 PSAはValidating Admission Phaseで実行されます。つまり、リソースを書き換えるのではなく、「許可／拒否」を判断します。
2. Admission Controllerとは？
Kubernetesには2種類のAdmission Controllerがあります：
| 種類 | 役割 |
|---|---|
| Mutating Admission | リソースを書き換える（例：Istioのサイドカー挿入） |
| Validating Admission | リソースを検証し拒否可能 |
PSAはValidating Admission Controllerとして実装されています。
3. PSAの評価対象
PSAが評価する主なリソース：
- Pod
- Deployment
- ReplicaSet
- StatefulSet
- DaemonSet
- Job / CronJob
これらは最終的にPodを生成するため、Podテンプレートを解析します。
4. Namespaceラベルによるポリシー適用メカニズム
PSAはNamespaceに設定されたラベルを参照します。
pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/warn=restricted 内部評価の流れ
- 対象リソースのNamespace取得
- Namespaceラベル取得
- 指定レベル（baseline / restricted）を判定
- Pod specをPSSルールセットに照合
- 違反があればreject / warn / audit
5. PSS評価ロジックの内部構造
PSAは内部的に「Pod Security Standards」の仕様に基づくルールセットを持っています。
評価対象の主なフィールド：
- securityContext
- capabilities
- privileged
- hostNetwork / hostPID / hostIPC
- volumes（hostPathなど）
- runAsUser / runAsNonRoot
- seccompProfile
例：Restrictedレベルでの内部チェック概念
擬似コードイメージ：
if container.securityContext.privileged == true: reject if container.securityContext.runAsNonRoot != true: reject if container.capabilities.add contains "SYS_ADMIN": reject if volume.type == "hostPath": reject 6. enforce / audit / warn の内部動作の違い
| モード | 動作 |
|---|---|
| enforce | 違反時にHTTP 403で拒否 |
| audit | Audit Logに記録 |
| warn | kubectlレスポンスに警告表示 |
内部的な違い
- enforce → admissionエラー返却
- warn → admission許可 + warning header付与
- audit → audit eventへannotation追加
7. PSAとWebhook型Admission（Gatekeeper）との違い
| 項目 | PSA | Gatekeeper |
|---|---|---|
| 実装 | API Server内蔵 | 外部Webhook |
| 拡張性 | 固定（PSSのみ） | Regoで自由に定義 |
| パフォーマンス | 高速（内部実装） | Webhook通信あり |
| 柔軟性 | 低 | 非常に高い |
PSAは高速・標準・シンプル、Gatekeeperは柔軟・高度・組織向けです。
8. パフォーマンス観点
PSAはAPI Server内部で動作するため：
Webhook通信が不要でネットワーク遅延がなく、大規模クラスタでも安定だが、一方で、Webhook型は外部通信が発生します。
9. PSAの制限事項
イメージレジストリ制限、latestタグ禁止、リソース量の最小値チェック、環境別動的制御はPSAではできないため、これらはOPA GatekeeperやKyvernoで補完します。
10. 実務設計モデル
推奨アーキテクチャ：
PSA（Restricted） ← ベースライン + OPA Gatekeeper ← 組織固有ポリシー + CI/CD OPAチェック ← 事前検証 まとめ
- PSAはKubernetes標準のValidating Admission Controller
- Namespaceラベルでポリシーレベル制御
- Restrictedは本番環境推奨
- PSAは高速・標準だが拡張性は限定的
- 高度な制御はGatekeeperと併用
PSAの内部動作を理解することで、Kubernetesセキュリティ設計の基盤がより明確になります。
