【Kubernetes】PodのPod Security Admissionってなんだ？【PSA】

COLUMN コラム

2025年09月29日
【Kubernetes】PodのPod Security Admissionってなんだ？【PSA】

こんにちは、個人で頑張ってるクラウドエンジニアです。

暑さ寒さも彼岸まで、との言葉通り、外の空気も大分ひんやりとしてきました。

今日は、KubernetsでAPI Serverに対するAPI通信を制御したい！みたいなニーズが現場に有り、軽くPod Security Admission（PSA）について調べてみました。

メモレベルで恐縮ですが、以下の当方理解をさらけ出します…

Pod Security Admission (PSA) 概要
参考: https://kubernetes.io/docs/concepts/security/pod-security-admission/

Kubernetes v1.25 以降で標準有効になった機能
- 現環境のclusterについても標準有効で、ただポリシー制限が無い状態
以前のPSP(PodSecurityPolicy)が非推奨 → 削除されたため、その代替
namespace単位でpodのセキュリティレベルを制御する仕組み
- PSPのように専用リソース(PodSecurityPolicy)は作成せず、namespaceにラベルを付与して制御

Pod Security Admission (PSA) 利用方法
参考: https://kubernetes.io/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-…

以下のようにnamespaceリソースに対して、
それぞれのmode毎にlevel設定が可能であり、pod-security.kubernetes.io/{enforce,audit,warn}のようなラベルに対して、値としてrestricted,baseline,privilegedを指定
“`
metadata:
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/warn: baseline
pod-security.kubernetes.io/audit: baseline
“`

設定が無い場合は、ポリシー制限が無いものとして扱われる(以下のprivilegedlevelと同様)

PSA制御のmodeは３つ。policyに違反した場合、

enforce -> pod作成がrejectされる
warn -> 警告メッセージは出力されるが、pod作成はallowed
audit -> audit logにイベントが記録され、pod作成はallowed

PSA制御のlevelは３つ。

privileged
- 制限なし。何でもできる（クラスタ管理用など）
baseline
- 既知のエスケープや危険な設定を禁止
- 一般アプリ用。制限は最小限にされたポリシーだが、既知の特権昇格を防止
  - 例: privileged コンテナ禁止、hostNetwork/hostPID の禁止など
restricted
- baselineの制限項目 + より厳しい制限。強固なセキュリティが必要なワークロード向け
  - 例: root ユーザ禁止、readOnlyRootFilesystem 必須など