🛡️ Kubernetes PSAセキュリティレベル、一体何をブロックしているのか？（詳細分析）

7月 19, 2026

—

こんにちは！前回の投稿では、Pod Security Admission (PSA)の概念と適用方法について学びました。本日はその続編として、PSAの核となる3つのセキュリティ標準（Pod Security Standards）が具体的に「どのような設定」をブロックし、許可するのかを徹底的に掘り下げていきます。

PSAを適用したのにPodが頻繁にError状態になってしまいますか？あるいはRestrictedレベルを適用したいけれど、何を修正すれば良いか途方に暮れていますか？この記事一つで完璧に整理できます。🚀

1. レベル 0: Privileged (特権) 🔓

「すべてが許可された無法地帯」

このポリシーは意図的に完全に開放されています。

制限事項: なし
許可: ホストカーネルへのアクセス、ルート権限、ホストネットワークの使用など、すべてが可能です。
使用対象: CNIプラグイン、ストレージドライバー、ノード管理エージェントなど、システムレベルのPod。

⚠️ 注意

一般的なWebアプリケーションやマイクロサービスには、絶対にこのレベルを適用してはいけません。ハッキングされると、ノード全体が危険にさらされます！

2. レベル 1: Baseline (基準) 🚧

「最低限の安全装置、一般的なアプリのための標準」

基本的なセキュリティポリシーです。権限昇格(Privilege Escalation)を通じてホストノードに損害を与える可能性のある行為を阻止します。ほとんどの一般的なコンテナイメージは、修正なしでこのレベルで正常に動作します。

🚫 主な制限事項 (ブロックされるもの)

特権コンテナの禁止 (privileged: true)

コンテナがホストのデバイスに直接アクセスするのを防ぎます。

ホストネームスペース共有の禁止

hostNetwork: true: ホストのネットワークを共有できません。
hostPID: true: ホストのプロセスIDを参照できません。
hostIPC: true: ホストのプロセス間通信にアクセスできません。

ホストポートの制限

ホストの特定のポート(0-65535)を占有することを制限します。

特定のLinux機能(Capabilities)追加の制限

システムに致命的な機能(例: CAP_SYS_ADMIN, CAP_MKNODなど)を追加(add)するのを防ぎます。

危険なSysctlsの禁止

カーネルパラメータを変更するsysctls設定のうち、安全でないものは使用できません。

ホストパス(HostPath)ボリューム

注記: BaselineはHostPath自体を完全に禁止するわけではありませんが、厳しく制限することが推奨されます（実質的なブロックはRestrictedで実行されます）。

3. レベル 2: Restricted (制限) 🏰

「最高レベルのセキュリティ、ベストプラクティス」

Baselineのすべての制限事項を含み、Podをさらに隔離し、攻撃対象領域を最小化するための強力なルールが追加されます。このレベルを通過するには、Podスペック(YAML)を修正する必要がある場合があります。

🚫 追加制限事項 (Baseline + α)

このレベルは、以下の条件を必ず明示的に設定する必要があります。

1. ルート(Root)実行の禁止 👮

コンテナは必ずRoot(UID 0)ではないユーザーとして実行される必要があります。
YAML必須設定:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000 # 0以外の数字

2. 権限昇格の禁止 (Privilege Escalation) 📉

プロセスが親プロセスよりも高い権限を獲得するのを防ぎます。setuidバイナリの実行などがブロックされます。
YAML必須設定:

containers:
  securityContext:
    allowPrivilegeEscalation: false

3. Linux機能(Capabilities)の初期化 🗑️

コンテナランタイムがデフォルトで提供する機能でさえも、すべて破棄(DROP)する必要があります。必要な場合は、NET_BIND_SERVICE程度のみ明示的に許可されます。
YAML必須設定:

containers:
  securityContext:
    capabilities:
      drop: ["ALL"]

4. ボリュームタイプの制限 💾

ホストのファイルシステムにアクセスできるHostPathボリュームは絶対に使用できません。
許可されるボリューム: ConfigMap, Secret, EmptyDir, PersistentVolumeClaim, DownwardAPI, Projectedなど、Kubernetes抽象化ボリュームのみが可能です。

5. Seccompプロファイルの適用 🛡️

システムコール(System Call)フィルタリング機能であるSeccompが設定されている必要があります。
YAML必須設定:

securityContext:
  seccompProfile:
    type: RuntimeDefault # またはLocalhost

🧐 一目で比較する要約表

制限項目	Privileged (特権)	Baseline (基準)	Restricted (制限)
Privilegedコンテナ	許可 ✅	ブロック 🚫	ブロック 🚫
Host Network/PID/IPC	許可 ✅	ブロック 🚫	ブロック 🚫
Linux Capabilities	制限なし	危険な機能の追加禁止	すべて破棄(DROP ALL) 必須
Rootユーザー実行	許可 ✅	許可 ✅	禁止 (Non-Root必須)
権限昇格 (Escalation)	許可 ✅	許可 ✅	禁止 (False必須)
ボリュームタイプ	すべて許可 (HostPath含む)	すべて許可	コアボリュームのみ許可 (HostPath禁止)

—

💡 Restrictedレベル通過のための模範解答YAML

Restrictedネームスペースにデプロイするには、以下のテンプレートを参考にしてください。これがまさにセキュリティのベストプラクティスです。

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  # [必須] Podレベルのセキュリティコンテキスト
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: my-app:1.0
    # [必須] コンテナレベルのセキュリティコンテキスト
    securityContext:
      allowPrivilegeEscalation: false
      runAsUser: 1001  # Root(0) 禁止
      capabilities:
        drop:
          - ALL # すべての権限を削除

終わりに 📝

最初はBaselineから始めて運用感覚を掴み、徐々にRestrictedへと強化していくのが良いでしょう。特にインターネットに直接公開されるWebアプリケーションであれば、Restrictedの適用を強く推奨します。

セキュリティは不便なものではなく、私たちのサービスをより強固にするプロセスです！次回の投稿では、PSAのトラブルシューティング事例をお届けします。👋