情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#Kubernetes#PodSecurityStandards#PodSecurityAdmission#컨테이너보안#PSA#DevSecOps#제로트러스트
最終更新 · 2026-09-27

Kubernetes Pod Security StandardsとPod Security Admissionに基づくコンテナセキュリティ

1. 概要

定義: Kubernetes Pod Security Standards(PSS)はPodが使用できる権限と分離機能を3段階の累積セキュリティプロファイルで定義し、Pod Security Admission(PSA)はそのプロファイルをNamespace単位でenforce・audit・warnモードにより適用する組込みのAdmission機構である。

コンテナはプロセスとファイルシステムを分離するが、分離設定が弱いとホストのネットワーク・プロセス・IPC Namespaceを共有したり、Linux capabilityを過剰に付与したりできる。privileged: trueのような設定は利便性を高める一方、コンテナ脱出やホスト掌握の攻撃面を大きくする。したがってイメージ脆弱性の検査だけでは不十分であり、デプロイ時に実行権限も一貫して検証しなければならない。

初期のPodSecurityPolicy(PSP)は利用できたが、Kubernetes 1.21で非推奨化の流れに入り、1.25で削除された。PSAは別のWebhookを導入せず、APIサーバーの組込みAdmission ControllerでPSSを適用する。ただしPSAは全てのコンテナセキュリティポリシーを表現する汎用エンジンではないため、NetworkPolicy・イメージ署名・ランタイム検知と階層的に設計する。

PSSはポリシーの内容と適用方法を分離する。ポリシーは「どのPodセキュリティレベルを要求するか」を表し、PSAのモードは違反を拒否・記録・警告するかを決める。この分離により、開発・検証・本番クラスタで同じ基準を再利用しながらenforcementを段階的に強化できる。

Kubernetes公式文書の現行ページは3プロファイル、モード、Namespaceラベル、バージョン固定、免除設定を説明している。文書のバージョンはクラスタのバージョンと異なることがあるため、実運用では実際のControl Planeとkubeletのバージョンに対応するPSS文書を確認する。

1.1 背景と必要性

第一に、コンテナイメージはアプリケーション成果物であり、実行権限の最終決定者ではない。同じイメージでもhostNetwork、hostPID、privileged、allowPrivilegeEscalation、seccomp、capabilityの設定によりリスクが変わる。PSSはこのような実行時属性を標準プロファイルにまとめ、組織の最低基準を作る。

第二に、マルチテナントクラスタではチームのYAMLがプラットフォーム境界を越えないようにする必要がある。Namespaceにプロファイルを付ければ各チームのパイプラインが異なっても同じAdmission基準を通過しなければならず、セキュリティ検査を開発者の記憶だけに依存しなくてよい。

第三に、最初から全てをrestrictedで拒否すると既存ワークロードと運用ツールが一斉に停止する可能性がある。PSAのwarnとauditは、デプロイを許可しながら違反を観測する移行段階である。これを利用して免除を減らし、必要な場合だけ明示的な特権Namespaceを許可する。

2. PSSプロファイルとセキュリティ境界

flowchart LR
    P[Pod manifest] --> PSA[Pod Security Admission]
    PSA --> L{Namespace labels}
    L --> PR[Privileged<br/>unrestricted]
    L --> BA[Baseline<br/>known escalation prevention]
    L --> RE[Restricted<br/>hardening best practices]
    PR --> A[Pod admitted]
    BA --> B[Baseline-compliant Pod]
    RE --> C[Restricted-compliant Pod]
    PSA --> M{Mode}
    M --> E[enforce: reject]
    M --> U[audit: audit annotation]
    M --> W[warn: client warning]

PSSの3レベルは独立したメニューではなく累積する境界である。privilegedは制限なし、baselineは一般的なワークロードとの互換性を重視しながら既知の権限昇格を防ぎ、restrictedはBaselineの制約を含みつつnon-root・seccomp・最小限のcapabilityなど現在のPod hardeningを要求する。

privilegedはノードエージェント、デバイスプラグイン、ホストと直接相互作用するネットワーク・ストレージシステムでは避けられない場合がある。しかし全ての運用ツールをprivilegedで実行するとNamespace分離の意味が失われる。信頼された運用主体と狭いNamespaceに限定し、理由・イメージ・サービスアカウント・ノード範囲を文書化する。

baselineは一般アプリケーションの現実的な出発点である。Host Namespace共有、privilegedコンテナ、危険な追加capability、許可されないhostPath・hostPort・sysctlなどの既知リスクを制限する。1つのコンテナが基準に違反するとPod全体が検証失敗するため、init containerとephemeral containerも検査する。

restrictedは互換性の一部を犠牲にして強いPod hardeningを適用する。Linuxコンテナは権限昇格を許可せず、seccompはRuntimeDefaultまたはLocalhostを指定し、capabilityはALLを削除して本当に必要な場合だけNET_BIND_SERVICEを戻す。コンテナやイメージがnon-rootで動作しなければアプリケーションを修正する。

プロファイル 目的 主な対象 代表的な制御
Privileged 最大の互換性と権限 ノード・インフラワークロード 制限なし、明示的な免除理由が必要
Baseline 既知の権限昇格を遮断 一般アプリケーション Host Namespace・privileged・危険なcapabilityを制限
Restricted 強いPod hardening 重要・低信頼ワークロード non-root・seccomp・capabilityを最小化

Namespaceにプロファイル名を付けるだけでセキュリティが完成するわけではない。例えばBaselineは脆弱なイメージを検査せず、Restrictedもサービスアカウントトークンの目的や東西トラフィックを制御しない。PSSはPodがどの権限で起動できるかを定義する第一防御線と理解する。

3. PSAの動作とラベルモデル

sequenceDiagram
    participant C as Client or Controller
    participant API as kube-apiserver
    participant PSA as Pod Security Admission
    participant NS as Namespace labels
    participant AUD as Audit log
    participant K as Kubelet
    C->>API: Create Deployment or Pod
    API->>PSA: Admission request
    PSA->>NS: Read enforce/audit/warn level and version
    PSA-->>API: Decision and warnings
    PSA->>AUD: Record violation annotation when audit applies
    API-->>C: Reject, warning, or success
    API->>K: Schedule admitted Pod

PSAはNamespaceラベルを読み、モードごとのプロファイルを決める。基本形式はpod-security.kubernetes.io/<MODE>: <LEVEL>であり、MODEはenforce・audit・warn、LEVELはprivileged・baseline・restrictedのいずれかである。例えばpod-security.kubernetes.io/enforce=baselineはBaseline違反Podの作成を拒否する。

enforceは違反をAPIリクエスト失敗として扱う。利用者はForbiddenと違反フィールドを確認してマニフェストを修正する。Deployment作成時はテンプレートが直ちにPodにならなくても検査できるが、enforcementは生成されたPodオブジェクトに適用される点をパイプラインで区別する。

auditはリクエストを許可するが、中央監査ログで集計できるようAudit annotationを残す。どのNamespaceのどの制御に違反が多いかを測る際に有用である。ログ収集が欠けるとauditは黙った許可になるため、APIサーバーの監査ポリシーと保存期間を同時に設計する。

warnはリクエストを許可しつつクライアントへ利用者向け警告を返す。開発者とデプロイパイプラインがすぐ確認できる反面、自動化ツールが警告を捨てる可能性がある。CIでは段階に応じて警告を可視化した作業項目やエラーへ変換する。

3つのモードは異なるレベルを同時に設定できる。enforce=baseline、audit=restricted、warn=restrictedとすればBaselineは強制し、Restrictedへの移行準備を観測できる。本番では可用性を維持しながら強い目標レベルの違反を減らす組合せとなる。

3.1 ポリシーバージョン固定

PSSの基準はKubernetesのマイナーバージョンとともに変わり得る。pod-security.kubernetes.io/<MODE>-versionラベルで特定バージョンに固定でき、latestで現行基準に追随できる。アップグレードで急に強化されることを防ぐため、enforcementは検証済みバージョンに固定し、audit・warnは最新基準で運用する方法を検討する。

バージョン固定は古い基準を永続的に保つ許可ではない。固定版では許されるが最新版で制限されるフィールドをauditとwarnで見える化し、次回アップグレード前の修正計画を作る。混在バージョンクラスタでは古いkubeletがPod OSフィールドを十分に適用できない場合にも注意する。

4. 主な制御項目と適用手順

4.1 ホスト分離と権限昇格

hostNetwork・hostPID・hostIPCを使うとPodはノードのネットワーク・プロセス・IPC領域と結合する。監視やネットワークプラグインのように目的が明確なSystem Pod以外では、これらのフィールドを拒否することが原則である。必要な場合も同じノードに配置されるワークロードと攻撃経路を分析する。

privilegedコンテナは大部分のコンテナ分離機構を回避できる。allowPrivilegeEscalationがtrueならsetuidやfile capabilityで権限を拡大できるため、Restrictedはfalseを要求する。runAsNonRootとrunAsUserをイメージの実ユーザーと一致させないと起動に失敗することがあり、イメージビルド時のユーザー定義が重要になる。

Linux capabilityはroot全体より小さいが、NET_ADMINやSYS_ADMINのような権限はシステムへ影響する。Restrictedでは最初に全capabilityを削除し、必要な場合だけNET_BIND_SERVICEを戻す。高いポートを使うようアプリケーションを変更する方が、capability免除を残すより安全な場合がある。

4.2 seccomp・AppArmor・SELinux

seccompはコンテナプロセスが呼び出せるシステムコールを制限する。RuntimeDefaultはランタイムの既定プロファイルを使用し、特殊なアプリケーションはLocalhostプロファイルを指定できる。privilegedで迂回するとカーネル攻撃面が広がるため、互換性・性能テストで必要なシステムコールを確定する。

AppArmorとSELinuxはイメージとノードOSのポリシーに依存する。PSSがフィールドの形式を検査しても、ノードにプロファイルがロードされ監査イベントが収集されるかは別に検証する。異なるノードOSを混在させると同じPodでもセキュリティプロファイルにより挙動が変わることがある。

4.3 YAML設計とサプライチェーン連携

PSSは最終PodSpecを基準に判断するため、Helmの既定値、Kustomize overlay、Operatorが生成するテンプレートを全て検査する。開発者のDeploymentが安全でも、Operatorがprivileged init containerを追加すれば結果は変わる。レンダリング済みマニフェストにserver dry-runとポリシー検査を行う。

イメージ署名とSBOMはPSSの代替ではない。署名はどのイメージをデプロイしたか、SBOMはどのコンポーネントを含むか、PSSはそのイメージがどの権限で実行されるかを表す。これらを1つのデプロイ承認ポリシーに結合すれば、信頼できない部品と過剰な実行権限を同時に減らせる。

4.4 特権ワークロードの免除

PSAはユーザー名、RuntimeClass、Namespaceを明示的な免除リストに設定できる。免除リクエストはenforce・audit・warnを全てスキップするため、広い免除は実質的なポリシー迂回である。サービスアカウントを免除する場合、そのアカウントでDeploymentを作成できる利用者まで間接的に免除されないか確認する。

免除は「システムだから」ではなく、具体的機能と統制策に基づいて承認する。例えばNetwork Plugin Namespace、Device Plugin RuntimeClass、ノード診断ツールのイメージをdigestと実行ノードに固定し、RBAC・NetworkPolicy・監査ログを追加する。不要になった権限が残らないよう免除リストを定期的に再検査する。

5. 適用・運用手順

第一段階は全Namespaceとワークロードの棚卸しである。System Namespace、ビルド・デプロイツール、アプリケーション、観測・セキュリティエージェントを分け、privileged・hostPath・hostNetwork・capabilityの使用状況を収集する。ラベルのないNamespaceは「安全」ではなく「未評価」と扱う。

第二に目標レベルを決め、warnとauditを先に有効にする。例えば開発NamespaceではBaselineを警告し、重要サービスではRestrictedを警告・監査する。違反フィールド、担当チーム、修正難易度、業務影響を表で管理し、原因と代案は文章によるRunbookに残す。

第三にテスト・ステージングでenforceを適用する。kubectl label --dry-run=serverで既存Podを新基準に当てはめ、Deployment・Job・CronJob・Operatorが作るPodまで検証する。1回のデプロイ成功より、Rolling Update、復旧、debug ephemeral container、ノード交換を含む運用シナリオの合格が重要である。

第四に本番をNamespace単位で段階移行する。一般アプリケーションには先にBaseline enforcementを適用し、修正済みサービスをRestrictedへ昇格する。避けられない特権ワークロードは一般アプリケーションと混在させず、別Namespaceと承認済み免除で隔離する。

第五にアップグレード前後の基準差分を観測する。enforcementを固定していても、audit・warnで最新プロファイルを評価し、その差分をリリース検証項目に入れる。違反数、免除数、デプロイ失敗率、セキュリティ事故の検知時間をダッシュボードと経営指標に結び付ける。

6. 比較分析

6.1 PSSと汎用ポリシーエンジン

PSSはKubernetesに組み込まれ、3プロファイルとNamespaceラベルという単純な運用モデルを提供する。別Webhookを導入・アップグレードする必要が少なく、共通最低線を素早く適用できる。一方、承認済みイメージレジストリ、許可されたhostPath、フィールド間条件のような組織固有の細かな規則は表現しにくい。

OPA GatekeeperやKyvernoのような汎用エンジンは、組織ルールへの拡張、監査、変換、検証を提供できる。その代わりWebhookの可用性、ポリシー順序、性能、失敗時動作、CRDライフサイクルを運用する必要がある。実務ではPSSを共通最低線とし、汎用エンジンで企業固有の追加条件を補う組合せが合理的である。

比較軸 PSS・PSA 汎用ポリシーエンジン
導入 Kubernetesの組込み機能が中心 別Controller・Webhookが必要
表現力 3プロファイルとPodセキュリティフィールド 組織固有の条件・変換・検査
適用範囲 主にPodセキュリティとNamespace イメージ・ラベル・リソース関係など広範囲
長所 単純性・一貫性・低い導入障壁 高い表現力・自動化
注意点 細かな免除と企業規則に限界 Webhook可用性・衝突・運用複雑性

6.2 PSSとランタイムセキュリティ

PSSはPod作成・更新時の予防的制御である。Falcoのようなランタイムツールは実行中のプロセス、ファイルアクセス、ネットワーク動作を観測し、実行開始後の攻撃や異常を検知する。前者は「この設定で起動させない」、後者は「起動後の異常を検知する」ものであり、競合ではなく多層防御である。

例えばRestrictedを通過したイメージでも、アプリケーション脆弱性からシェルを実行すればPSSだけでは検知できない。逆にランタイム検知だけに依存すると実行後の対応になる。Pod作成ポリシー、ネットワーク分離、イメージ信頼、ランタイム検知を連携させる。

7. 適用事例と深化

7.1 金融取引APIクラスタ

金融取引APIはRestrictedを目標にし、enforce=baseline、audit=restricted、warn=restrictedから開始する。開発チームはイメージをnon-rootで実行しread-only root filesystemを支援し、プラットフォームチームは共通Helm Chartにseccomp RuntimeDefaultとcapability dropを追加する。監査ログはサービス別の違反と承認済み免除を追跡する。

ステージングでRestricted enforcementを有効にした後、決済承認・Rolling Deployment・障害復旧を繰り返す。デバッグにephemeral containerが必要なら、一般運用者へ無制限権限を与えず、承認済みDebug RuntimeClassと短期TTLのアクセスアカウントを使う。障害対応の利便性が恒久的な特権経路にならないようにする。

7.2 製造エッジクラスタ

工場エッジではデバイスプラグインとネットワークエージェントがHost Namespaceや特定capabilityを要求する場合がある。これらをアプリケーションNamespaceから分離し、イメージdigest、RuntimeClass、サービスアカウントで免除を絞る。センサー収集サービスはBaselineまたはRestrictedで運用し、現場基盤の特権経路が業務APIへ広がらないようにする。

エッジクラスタは接続が不安定な場合があるため、クラスタプロビジョニング段階でラベルとPSA設定を宣言し、ローカル監査ログを保存する。中央へ復帰したら免除リストと違反イベントを同期し、現場ごとの例外が蓄積しないようにする。

7.3 試験・関連テーマの答案戦略

試験答案ではPSSを定義するだけでなく、「危険なPodSpec → PSAモード判定 → API応答または監査 → kubelet実行 → ランタイム観測」の因果フローを図示するとよい。その後3プロファイルを表で要約し、各プロファイルが必要な組織的理由を文章で説明する。

コンテナセキュリティ、DevSecOps、ゼロトラスト、サプライチェーンセキュリティと関連付けるときは制御時点を分ける。PSSはワークロード権限、イメージ署名は出所、SBOMは構成透明性、NetworkPolicyは通信範囲、ランタイムセキュリティは挙動を扱う。この区別により「セキュリティツールを増やす」という列挙型答案を避けられる。

8. 考慮事項と示唆

  1. 可用性と最小権限の均衡を設計する。 直ちにRestrictedを強制すると運用・デプロイツールが停止するため、warn・auditで違反を集め、サービスごとの修正順を定める。一方privilegedを既定値にせず、例外は別Namespace・RBAC・監査・期限で制御する。

  2. ポリシーバージョンとクラスタバージョンを一緒に管理する。 KubernetesアップグレードでPSS基準が変化し、混在kubeletではOS別フィールドの適用も異なり得る。enforcement版を事前検証し、audit・warnは最新基準で運用してアップグレードリスクを早期に見つける。

  3. 免除をセキュリティ資産として管理する。 ユーザー・RuntimeClass・Namespace免除は3モードを全てスキップするため、理由・所有者・イメージ・許可ノード・期限を記録する。サービスアカウントが作成できるリソースまで検討し、定期的なアクセス再認証を行う。

  4. PSS外の制御を明確に接続する。 PSSを通過しても脆弱なイメージ、過剰なネットワーク範囲、盗難されたサービスアカウント、異常なランタイム動作は残り得る。イメージ検査・署名、SBOM・VEX、NetworkPolicy、Secret管理、ランタイム検知を1つのポリシー流れに接続し、担当者を明確にする。

  5. 運用指標でポリシー効果を検証する。 目的は違反数の削減だけではなく、privileged比率、免除比率、デプロイ失敗率、例外の平均存続期間、事故検知時間も追跡する。これらの指標により、セキュリティ強化が生産性と可用性へ与えた影響を技術士の観点から説明できる。

参考資料

一言まとめ: PSSはPod権限の最低セキュリティ境界を定義し、PSAはNamespace単位のwarn・audit・enforceで段階適用するため、実効性あるコンテナセキュリティにはバージョン・免除・サプライチェーン・ランタイム制御も必要である。