🛡️ Kubernetesセキュリティの新しい標準: Pod Security Admission (PSA) 完全ガイド

7月 20, 2026

—

皆さん、こんにちは！今日は、Kubernetesセキュリティ設定の核となるPod Security Admission (PSA)について深く掘り下げていきたいと思います。

v1.25から、従来のPod Security Policy (PSP)が完全に削除され、PSAがその役割を担うことになりました。「セキュリティ設定は難しい」という偏見を打ち破り、Kubernetesネイティブな方法（Built-in）で非常にシンプルに適用できるPSAのすべてを詳細にまとめました。🚀

1. PSAとは何ですか？ 🤔

Pod Security Admission (PSA)は、Podが作成される際に、そのPodが事前に定義されたセキュリティ標準（Pod Security Standards）に準拠しているかを検査するアドミッションコントローラー（Admission Controller）です。

以前のPSPは設定が複雑で権限管理が難しかったですが、PSAは別途CRD（Custom Resource Definition）をインストールすることなく、ネームスペースにラベルを付けるだけで即座に動作します。

2. 主要概念1: セキュリティレベル (Levels) 📊

PSAは、Pod Security Standards (PSS)と呼ばれる3つのセキュリティレベルを基準にPodを検査します。状況に合わせて適切なレベルを選択する必要があります。

レベル (Level)	説明	推奨対象
Privileged	一切の制約がありません。ホストのカーネル機能にアクセス可能です。	システム管理用エージェント (CNI、ストレージドライバーなど)
Baseline	権限昇格(Privilege Escalation)を防止する最小限の制約です。	一般的なマイクロサービス、ウェブアプリケーション
Restricted	最も強力なセキュリティレベルです。Root実行禁止、ボリュームタイプ制限などを含みます。	セキュリティが非常に重要な金融/個人情報処理アプリ

3. 主要概念2: 制御モード (Modes) 🎛️

ポリシーに違反した場合の処理方法を3つのモードで決定できます。1つのネームスペースに複数のモードを同時に適用することも可能です！

Enforce (強制): ポリシー違反時にPodの作成を拒否（Reject）します。
Audit (監査): Podの作成は許可しますが、違反事実を監査ログ（Audit Log）に残します。
Warn (警告): Podの作成は許可しますが、ユーザーに警告メッセージを表示します。

4. 実践！PSA適用ガイド 🛠️

それでは、実際にネームスペースにポリシーを適用してみましょう。最も推奨される方法は、「警告（Warn）モードでまず確認し、強制（Enforce）モードに切り替える」ことです。

Step 1. テスト用ネームスペースの作成

kubectl create ns psa-test

Step 2. ポリシーの適用（ラベリング）

psa-testネームスペースに最も強力なセキュリティであるrestrictedレベルを適用してみます。最初はブロックされないようにwarnモードのみを有効にしてみましょう。

# 構文: pod-security.kubernetes.io/<MODE>=<LEVEL>

# 1. 警告モード設定 (Restricted違反時に警告)
kubectl label ns psa-test pod-security.kubernetes.io/warn=restricted

# 2. 強制モード設定 (Baseline違反時にブロック) -> 二重適用可能
kubectl label ns psa-test pod-security.kubernetes.io/enforce=baseline

Step 3. ポリシー違反Podの作成テスト

セキュリティ設定が全くないNginx Podを作成しようとするとどうなるでしょうか？

Bash

kubectl run nginx --image=nginx -n psa-test

出力結果 (Warnモード動作):

Warning: would violate PodSecurity “restricted:latest”: allowPrivilegeEscalation != false (container “nginx” must set securityContext.allowPrivilegeEscalation=false), runAsNonRoot != true (pod or container “nginx” must set securityContext.runAsNonRoot=true), …

pod/nginx created

enforce=baselineは通過したためPodは作成されましたが、warn=restrictedによって多数の警告メッセージが表示されたことがわかります。

Step 4. ‘Restricted’に準拠するようにPodを修正

Restrictedレベルを通過するには、securityContextを注意深く設定する必要があります。

YAML

apiVersion: v1
kind: Pod
metadata:
  name: secure-nginx
  namespace: psa-test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      runAsUser: 1001 # Root(0)以外のユーザーを指定

5. 高度な設定: 例外処理 (Exemptions) 🔓

特定のネームスペースではほとんどのPodをブロックする必要がありますが、特定の管理者やコントローラーは許可する必要がある場合があります。これはネームスペースラベルではなく、クラスターレベルの設定ファイル（AdmissionConfiguration）を通じて制御します。

注意: この設定はAPIサーバーの設定ファイルを変更する必要があるため、マネージドKubernetes（EKS、GKE、AKS）では直接設定が制限される場合があります。

YAML

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "baseline"
      enforce-version: "latest"
    exemptions:
      # 特定のユーザー名を例外処理
      usernames: ["admin", "system:serviceaccount:kube-system:replicaset-controller"]
      # 特定のランタイムクラスを例外処理
      runtimeClasses: ["kata-containers"]
      # 特定のネームスペースを例外処理
      namespaces: ["kube-system"]

6. まとめ: 安全な導入のためのロードマップ 🗺️

PSAを運用環境に導入する際は、サービスの中断を防ぐために以下の順序に従うことをお勧めします。

現状把握: 現在のクラスターバージョンを確認し（v1.23以上推奨）、ネームスペースごとの用途を分類します。
Audit/Warnモードの適用: enforceなしでwarn=baselineまたはwarn=restrictedをまず適用し、ログを収集します。
アプリケーションの修正: 警告が発生するPodのsecurityContextを修正します。
Enforceへの切り替え: 警告がなくなったらenforceモードに切り替えてセキュリティを強制します。

PSAはもはや選択肢ではなく、必須です。複雑なサードパーティツールなしでも強力なセキュリティガバナンスを構築できるPSAを、今すぐ始めてみましょう！💪