【入門編】 Admission Controllerを用いたPodセキュリティ標準(PSS)の強制 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやクラウドのセキュリティを担当していると、「Kubernetes（K8s）のセキュリティって、なんだか壁が高そう…」と感じてしまうこと、ありませんか？

「コンテナ技術は便利だけど、中のアプリが乗っ取られたらどうなっちゃうの？」
「特権コンテナって言葉は聞くけど、何がそんなに危ないの？」

そんな不安を抱えている新人エンジニアや開発者の方に向けて、今回はKubernetesの標準機能である「Pod Security Admission (PSA)」を使った、クラウド時代の強力な要塞化（ハーデニング）について、身近な例えを交えながら分かりやすく解説していきますね。

一歩ずつ、確実に安全な環境を作れるようになりましょう！

—

1. 家の鍵に例える「特権コンテナ」と「ホストパス」の危険性

まず、これから防ごうとしているセキュリティリスクについて、私たちが普段暮らしている「お家（マンション）」に例えて考えてみましょう。

Kubernetesの世界で動く「Pod（ポッド）」という単位は、いわばマンションの「各お部屋」のようなものです。通常、お部屋の住人（コンテナ）は、自分のお部屋の中だけで暮らしています。たとえそのお部屋の住人が悪意を持っていたとしても、他の部屋に入ったり、マンションの管理室（ホストOS）の金庫を勝手に開けたりすることはできません。これが「安全な状態」ですよね。

しかし、セキュリティの設定を甘くしてしまうと、次のような危険な状態が生まれてしまいます。

特権コンテナ（Privileged Container）の実行
例えるなら、「合鍵どころか、マンション全体のマスターキーを部屋の住人に渡しっぱなしにしている状態」です。これを許してしまうと、コンテナの脱獄（コンテナエスケープ）が起きた際に、その下にあるホストOS（サーバー本体）のすべてが敵の手に渡ってしまいます。
ホストパス（HostPath）のマウント
例えるなら、「自室のクローゼットの壁をぶち抜いて、管理人室の裏通路に直接つながるドアを作っている状態」です。コンテナからホスト側の重要ファイル（/etc/shadow や Dockerのソケットなど）に直接触れられてしまい、システム全体が乗っ取られる原因になります。

「こんな危ない設定、誰もわざわざしないよ！」と思われるかもしれませんが、開発の便利さや古いチュートリアルのコピペから、うっかりこうした危険な設定が本番環境に紛れ込んでしまうことが、現場では本当によくあるんです。

だからこそ、人間の「うっかり」を防ぐために、システム側でガッチリと門番を置く必要があります。それが今回紹介する Pod Security Admission (PSA) です。

—

2. Pod Security Admission (PSA) とは？

Pod Security Admissionは、Kubernetes（バージョン1.25以降で標準）に組み込まれている公式の「門番」機能です。

マンションの入り口に屈強なガードマンを立たせたとイメージしてください。住人が新しい荷物（Pod）を持ち込もうとしたとき、ガードマンがその中身をチェックします。

「おっと、この荷物、鍵の開けっ放し（特権設定）があるからロビーに入れちゃダメだよ！」

このように、危険な設定を持つPodがKubernetesクラスター（マンション内）に入るのを、ポリシーレベルで自動的に拒否（Reject）してくれるのがPSAの素晴らしいところです。

PSAには、あらかじめいくつかのセキュリティレベルが用意されています。

1. Privileged（特権）：制限なし。何でも許可します（開発・検証用など一部のシステム用）。
2. Baseline（ベースライン）：一般的なアプリケーション向けの標準的な制限。既知のエスケープ経路を防ぎます。
3. Restricted（厳格）：最も安全なレベル。セキュリティベストプラクティスを強制し、非ルートユーザーでの実行などを求めます。

今回は、この中の Baseline または Restricted を名前空間（Namespace）に適用し、危険なPodをシャットアウトする方法を見ていきましょう！

—

3. 実践！ネームスペースにセキュリティ基準を適用する

それでは、実際に手を動かしてみましょう。
Kubernetesでは、ネームスペース（Namespace）という単位ごとに、どのセキュリティレベルを適用するかをラベル（Labels）で指定できます。

例えば、production という本番用のネームスペースを作って、そこに「Baseline」レベルの厳しいチェックをかける設定ファイルは以下のようになります。

# production-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Pod Security Admissionのモードを設定します
    # audit: 違反があった場合に監査ログに記録する（今回は警告モード）
    pod-security.kubernetes.io/audit: "baseline"
    # warn: ユーザーの画面（kubectl apply時など）に警告メッセージを表示する
    pod-security.kubernetes.io/warn: "baseline"
    # enforce: 違反するPodの作成を「完全に拒否（ブロック）」する
    pod-security.kubernetes.io/enforce: "baseline"
    
    # さらに厳格にしたい場合は、enforceの値を "restricted" に変更します
    # pod-security.kubernetes.io/enforce: "restricted"

この設定ファイルをクラスターに適用するには、いつも通り kubectl apply を使います。

kubectl apply -f production-namespace.yaml

たったこれだけで、production ネームスペースの門番が有効化されます。非常に簡単ですよね！

—

4. 実際に攻撃的なPodをデプロイして拒否されるか試してみよう

門番がちゃんと働いているか、あえて「危険な設定（特権コンテナ）」を持ったPodをデプロイしてテストしてみましょう。

以下のマニフェストは、securityContext.privileged: true を指定した、いかにも危なっかしいPodの例です。

# bad-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: unsafe-pod
  namespace: production # 先ほどセキュリティを設定したネームスペース
spec:
  containers:
  - name: hacker-wannabe
    image: nginx:latest
    securityContext:
      # ここが危険！ホストを乗っ取れる特権コンテナを指定
      privileged: true

このPodを production ネームスペースにデプロイしてみます。

kubectl apply -f bad-pod.yaml

すると、以下のようなエラーメッセージが返ってきて、Kubernetesがデプロイをピタッと止めてくれるはずです。

Error from server (Forbidden): error when creating "bad-pod.yaml": 
pods "unsafe-pod" is forbidden: violates PodSecurity "baseline:latest": 
privileged (container "hacker-wannabe" must not set securityContext.privileged=true)

「おっ、見事にガードマンが弾いてくれましたね！」

このように、開発者がうっかり privileged: true や危険なホストマウントの設定を含んだコードをデプロイしようとしても、PSAが水際でブロックしてくれるため、インフラの安全性が強力に保たれます。

—

5. 現場のセキュリティ担当者からのアドバイス

実務でこのPSAを導入する際、いくつかの「泥臭いコツ」がありますのでシェアしておきますね。

1. いきなり enforce（強制拒否）から始めない
既存のシステムがある環境でいきなり enforce: "restricted" などを設定すると、動いていたアプリケーションがいきなりデプロイできなくなるトラブル（障害）を引き起こします。まずは audit や warn モードで既存のPodがポリシーに違反していないかログを観測し、安全を確認してから enforce に切り替えるのが鉄則です。
2. 例外が必要な場合はどうするか？
どうしてもシステム上の理由で特権コンテナや特定のホストボリュームが必要なレガシーシステムがある場合は、特定のネームスペースだけ除外するか、あるいは例外的なServiceAccountに対する権限調整を検討します。ただし、原則は「例外を作らないこと」です。

—

まとめ

今回は、Pod Security Admission (PSA) を使って、特権コンテナの実行や危険なマウントをポリシーレベルで拒否する方法を解説しました。

特権コンテナやホストパスは、お家のマスターキーを泥棒に渡すようなもの。
Pod Security Admission (PSA) は、危険な設定を持つPodの侵入を防ぐ強力な門番。
ネームスペースに enforce ラベルを貼るだけで、簡単にセキュリティを強制できる。

セキュリティ対策と聞くと難しく身構えてしまいがちですが、Kubernetesの標準機能であるPSAを正しく使えば、手間をかけずにインフラの堅牢性を大きく高めることができます。

ぜひ、皆さんの開発・検証環境のネームスペースから試してみてくださいね。一歩ずつ、安全で強いシステムを作っていきましょう！