mhKubernetesでは、多くのアプリケーションがコンテナとして実行されます。便利な一方で、セキュリティ対策が不十分なままだと、内部からの攻撃や誤操作によってクラスター全体が危険にさらされる可能性があります。
そのため、「コンテナに何を許可するか、何を禁止するか」を制御する手段が必要です。そこで登場するのが Kubernetes の PodSecurity（ポッドセキュリティ） 機能です。
🔐 なぜコンテナのセキュリティ対策が必要か？
例を挙げてみます。
- あるPodが「rootユーザーで動作」している
- ホストの
/etcディレクトリをhostPathマウントで読み書きできる - コンテナから他のPodのメタデータを抜き取る
こうした設定は、悪意のあるユーザーにとって「クラスター乗っ取りの入口」となり得ます。
これを防ぐためには、明示的な制限を定める必要があります。
✅ PodSecurityとは？
Kubernetes 1.25 以降、PodSecurityPolicy（PSP）は廃止され、代わりにPod Security Admission（PSA） という機能が正式に導入されました。
PSA は、Podの仕様（YAML）をチェックして、セキュリティ基準に沿わないPodを拒否・警告する仕組みです。
🚦 PodSecurity のモード（3段階）
| レベル | 説明 | 例 |
|---|---|---|
| privileged | 制限なし（最も緩い） | rootでの実行、特権コンテナなどOK |
| baseline | 一般的な用途に適した最低限の制限 | hostPath使用NG、特権モードNG |
| restricted | 本番向けの強い制限 | rootユーザーNG、CAPの追加NG など |
これらのレベルはNamespace単位で適用できます。
🧩 Namespace への適用例
Namespaceに対して restricted レベルを適用する例です：
kubectl label namespace dev \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/enforce-version=latestこれにより、dev 名前空間に restricted レベルのポリシーが強制され、ルールに違反するPodは作成できなくなります。
🧪 モードの種類
PodSecurityには3つの「動作モード」があります：
| モード | 説明 |
|---|---|
enforce | 違反があれば Pod 作成を拒否 |
audit | 拒否はしないがログに記録する |
warn | ユーザーに警告を出すが拒否はしない |
例えば以下のように、警告と監査だけを設定することもできます：
kubectl label namespace test \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted🛠 運用のポイント
- 開発用Namespaceではbaseline、商用環境ではrestrictedを使うのが基本
kubectl explain pod.specで許容される仕様を確認するとよいkube-apiserverのログやkubectl createの出力を見てルール違反を把握できる
⚙️ 他のセキュリティ対策（補足）
PodSecurityだけでなく、以下のような対策も有効です：
- readOnlyRootFilesystem を有効にする
- SecurityContext で
runAsNonRoot,allowPrivilegeEscalationを制限 - NetworkPolicy で通信制限
- RBAC で操作権限を制限
🔚 まとめ
Kubernetesは強力な仕組みを提供してくれますが、何も制限しない状態は非常に危険です。
その第一歩として「Podに許可すること／禁止すること」をNamespace単位でコントロールするPodSecurityの設定は重要です。
