Skip to content
Published on

Pod Security Standards（PSA/PSS）実践ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Authors
  • Name
    Twitter
Pod Security Standards Guide

1. Pod Security Standardsとは？

Kubernetes 1.25からPodSecurityPolicy（PSP）が完全に削除され、**Pod Security Admission（PSA）がデフォルトのセキュリティメカニズムとなりました。PSAはPod Security Standards（PSS）**という3段階のセキュリティプロファイルに基づいて動作します。

PSPからPSAへの移行背景

PSPは複雑なRBAC設定が必要で、デバッグが困難でした。PSAはnamespaceラベルだけで簡単にセキュリティポリシーを適用できるため、運用負荷が大幅に軽減されました。

2. 3つのセキュリティプロファイル

Privileged（特権）

すべてが許可されるプロファイルです。CNIやストレージドライバーなどのシステムレベルのワークロードに使用します。

# kube-system namespaceにPrivilegedを適用
apiVersion: v1
kind: Namespace
metadata:
  name: kube-system
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

Baseline（基本）

既知の権限昇格を防止しつつ、大部分のワークロードが動作できるプロファイルです。

制限項目：

  • hostNetwork、hostPID、hostIPCの使用禁止
  • privilegedコンテナ禁止
  • 危険なcapabilitiesの追加禁止（NET_RAWなど）
  • hostPathボリューム禁止
apiVersion: v1
kind: Namespace
metadata:
  name: app-staging
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.30
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Restricted（制限）

最も厳格なプロファイルで、セキュリティのベストプラクティスを強制します。

追加制限項目：

  • runAsNonRoot必須
  • Seccompプロファイル設定必須
  • すべてのcapabilitiesのdrop必須
  • allowPrivilegeEscalation: false必須
apiVersion: v1
kind: Namespace
metadata:
  name: app-production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.30
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. PSAの動作モード

PSAは3つのモードで動作します：

モード動作用途
enforceポリシー違反Podの作成を拒否実際のポリシー適用
audit監査ログに記録モニタリング
warnユーザーに警告を表示マイグレーション準備
# namespaceにラベルを適用
kubectl label namespace my-app \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

4. Restrictedプロファイル対応のPod作成

Restrictedを満たすPod specの例です：

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: app-production
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: nginx:1.27-alpine
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        runAsNonRoot: true
        runAsUser: 1000
        capabilities:
          drop:
            - ALL
      resources:
        limits:
          memory: '128Mi'
          cpu: '500m'
        requests:
          memory: '64Mi'
          cpu: '250m'
      volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /var/cache/nginx
        - name: run
          mountPath: /var/run
  volumes:
    - name: tmp
      emptyDir: {}
    - name: cache
      emptyDir: {}
    - name: run
      emptyDir: {}

5. マイグレーション戦略

既存クラスターをPSAへ移行するための段階的なアプローチです。

Step 1：現在の状態を監査

# すべてのnamespaceに対してdry-run検査
kubectl label --dry-run=server --overwrite ns --all \
  pod-security.kubernetes.io/enforce=baseline

# 特定namespaceの違反事項を確認
kubectl get pods -n my-app -o json | \
  kubectl apply --dry-run=server -f - 2>&1 | grep -i "warning"

Step 2：warn/auditモードで開始

# まずwarnとauditのみ適用
kubectl label namespace my-app \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline

Step 3：違反ワークロードの修正

# 監査ログで違反事項を確認
kubectl logs -n kube-system -l component=kube-apiserver | \
  grep "pod-security.kubernetes.io"

Step 4：enforceモードの有効化

# 十分なテスト後にenforceを適用
kubectl label namespace my-app \
  pod-security.kubernetes.io/enforce=baseline \
  --overwrite

6. Namespace別の例外処理

特定のワークロードが上位権限を必要とする場合、namespaceを分離することが推奨されます：

# モニタリングエージェント用の別namespace
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring-agents
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: restricted
---
# 一般アプリ用namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production-apps
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

7. AdmissionConfigurationによるクラスターデフォルトの設定

APIサーバー設定でクラスター全体のデフォルトポリシーを指定できます：

# /etc/kubernetes/psa-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: PodSecurity
    configuration:
      apiVersion: pod-security.admission.config.k8s.io/v1
      kind: PodSecurityConfiguration
      defaults:
        enforce: 'baseline'
        enforce-version: 'latest'
        audit: 'restricted'
        audit-version: 'latest'
        warn: 'restricted'
        warn-version: 'latest'
      exemptions:
        usernames: []
        runtimeClasses: []
        namespaces:
          - kube-system
          - kube-public
          - istio-system

8. 実践トラブルシューティング

よくあるエラーと解決法

# エラー: Pod作成が拒否される
# Error: pods "my-pod" is forbidden: violates PodSecurity "restricted:v1.30"

# 1. どのフィールドが違反しているか確認
kubectl describe pod my-pod -n production-apps 2>&1

# 2. 一時的にwarnモードで詳細確認
kubectl label namespace production-apps \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  --overwrite

よく発生する違反チェックリスト

#!/bin/bash
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  echo "=== Namespace: $ns ==="
  kubectl get pods -n "$ns" -o json | \
    jq -r '.items[] | select(
      .spec.containers[].securityContext == null or
      .spec.securityContext == null
    ) | .metadata.name'
done

9. クイズ

Q1：PSAの3つの動作モードとそれぞれの役割は？
  1. enforce：ポリシーに違反するPodの作成を拒否します。
  2. audit：違反事項を監査ログに記録しますが、Podの作成は許可します。
  3. warn：kubectlユーザーに警告メッセージを表示しますが、Podの作成は許可します。

マイグレーション時にはwarn/auditを先に適用し、十分な検証後にenforceを有効化するのが安全です。

Q2：Restrictedプロファイルで必ず設定しなければならないsecurityContextの4項目は？
  1. runAsNonRoot: true — rootユーザーでの実行を禁止
  2. allowPrivilegeEscalation: false — 権限昇格を禁止
  3. capabilities.drop: ["ALL"] — すべてのLinux capabilitiesを削除
  4. seccompProfile.type: RuntimeDefault — Seccompプロファイルを設定

この4つすべてを設定しないと、Restricted namespaceでPodの作成が拒否されます。

Q3：既存クラスターをPSAへ移行する際の推奨手順は？
  1. 現在の状態を監査：dry-runで違反事項を把握
  2. warn/auditの適用：実際のブロックなしでモニタリング
  3. 違反ワークロードの修正：securityContextの追加、権限の最小化
  4. enforceの有効化：十分なテスト後に実際のポリシーを適用
  5. クラスターデフォルトの設定：AdmissionConfigurationで新規namespaceに自動適用

段階的なアプローチが肝心であり、一度にenforceを適用することは絶対に避けてください。

Discuss on Twitter • View on GitHub