Kubernetesの「防波堤」を再考する：Admission ControllerによるPodセキュリティ標準（PSS）の強制と、その先の防御戦略
Kubernetesのセキュリティを語る際、多くのエンジニアが「コンテナイメージの脆弱性スキャン」や「ネットワークポリシーの適用」に目を奪われる。だが、実務で数々のインシデントを見てきた私からすれば、それらはあくまで「対症療法」に過ぎない。
真に恐ろしいのは、攻撃者が特権コンテナの隙を突き、ホストOSのカーネル（cgroupやnamespaceの分離境界）を突破しようと試みる瞬間だ。CVE-2024-21626のようなRunCの脆弱性が示す通り、コンテナランタイムの境界は、一度の「設定ミス」で崩壊する。
本稿では、Kubernetesにおける防衛の要、「Pod Security Admission (PSA)」を軸に、我々がどのようにインフラの要塞化を設計すべきかを深掘りする。
—
1. なぜ「Pod Security Standards (PSS)」が絶対的なのか
かつての PodSecurityPolicy (PSP) が非推奨となり、現在のKubernetes（v1.25+）では Pod Security Admission (PSA) が標準だ。これは単なる設定項目ではなく、APIサーバーのガードレイルである。
攻撃者は、CI/CDパイプラインを汚染し、hostPathをマウントしたコンテナを忍ばせようとする。これが通れば、ホストの/etc/shadowや、コンテナランタイムのソケット（/var/run/docker.sock等）が攻撃者の手に渡り、ゲームオーバーだ。PSAは、これらを「実行される前に」拒絶する。
2. PSAの実装：namespace単位の厳格な統制
PSAは、Namespaceに対してラベルを付与することで強制力を発揮する。以下は、プロダクション環境で推奨される「Restricted」プロファイルを適用する例だ。
# 名前空間に対して、セキュリティレベルを強制的に適用する
apiVersion: v1
kind: Namespace
metadata:
name: secured-app-ns
labels:
# Podセキュリティ標準：Restrictedを適用（最も厳格）
pod-security.kubernetes.io/enforce: restricted
# 違反があった場合に監査ログを出力
pod-security.kubernetes.io/audit: restricted
# 違反があった場合に警告を表示（開発者へのフィードバック）
pod-security.kubernetes.io/warn: restrictedこの設定により、allowPrivilegeEscalation: true や runAsNonRoot: false といった設定を持つPodは、APIサーバーによって即座に拒否される。
3. 低レイヤの視点：コンテナ分離の脆弱性とメモリ保護
ここで、なぜ私がここまで「特権コンテナの拒否」に固執するのか、その技術的背景を明かそう。
攻撃者が狙うのは、seccomp（Secure Computing mode）のフィルタリングを回避するシステムコールである。例えば、unshareやcloneを用いて名前空間を操作し、ホスト環境との隔離を無効化する攻撃手法は、今なお脅威だ。
PSAで restricted を強制することは、seccompのデフォルトプロファイルを強制し、不要なシステムコールをブロックすることと同義である。これは、万が一アプリケーションに RCE（リモートコード実行）の脆弱性があったとしても、攻撃者がOSの奥底へアクセスする「道具」を奪うことを意味する。
4. 生成AIとガードレイルの統合：次世代のセキュリティ設計
現在、我々は大規模言語モデル（LLM）をインフラ管理に組み込もうとしている。しかし、プロンプトインジェクションにより、LLMが「セキュリティ設定を無効化するコマンド」を生成してしまうリスクがある。
ここでPSAが重要な「不変の制約」として機能する。たとえLLMが特権コンテナをデプロイするような YAML を生成しようとしても、APIサーバーのPSAがそれを拒絶する。「AIには自由を与えるが、インフラの境界（Policy）はAIの手の届かない場所に固定する」。これが、現代のセキュリティアーキテクトが取るべきスタンスだ。
5. 監査とインシデント対応の泥臭い知見
運用において重要なのは、PSAの audit モードと warn モードを使い分けることだ。突然 enforce を適用すれば、レガシーなアプリケーションはすべてダウンする。
現場では以下のプロセスを推奨する：
1. フェーズ1（モニタリング）: warn モードのみ適用し、どのPodが規約に違反しているかをログ（audit.log）で数週間収集する。
2. フェーズ2（棚卸し）: 違反しているPodのオーナーを特定し、アプリケーションのコード修正を依頼する。
3. フェーズ3（強制）: enforce モードへ切り替える。
特に、audit.log を ELK や Datadog に転送し、pod_security_admission_audit_events_total メトリクスを監視せよ。突如として「特権昇格を試みる異常なAPIリクエスト」が増加した場合、それは内部侵入者か、あるいは攻撃者があなたのクラスタをスキャンしている兆候だ。
結びに：境界線は「動的」ではなく「硬直的」であるべき
技術革新のスピードは速いが、攻撃者が狙う「メモリの脆弱性」や「OSの特権設定」という基本原則は、10年前から変わっていない。クラウドネイティブな世界であっても、信頼の境界線は明確に引く必要がある。
PSAは、単なる設定ファイルではない。それは、あなたのKubernetesという広大な海に浮かぶ、沈まない防波堤である。これを適切に運用し、開発者が「安全なコードを書かざるを得ない環境」を作り上げることこそが、我々エンジニアの責務だ。
セキュアな設計とは、性悪説に基づき、システム自身に「自分自身を裏切らせない」仕組みを埋め込むことに他ならない。さあ、今すぐクラスタのラベルをチェックしてほしい。あなたのインフラは、本当に要塞化されているだろうか。
コメント