Pod Security（ポッドセキュリティ）

2025年11月6日

Pod Security（ポッドセキュリティ）

英語表記: Pod Security

概要

ポッドセキュリティ（Pod Security）とは、コンテナオーケストレーションシステム、特にKubernetesやOpenShiftといったオーケストレーション環境において、最小のワークロード単位である「Pod」のセキュリティを確保するためのメカニズムです。これは、Podの定義（マニフェスト）がセキュリティ上の危険な設定を含んでいないかをチェックし、実行を許可するかどうかを制御するクラスタセキュリティの重要な機能です。具体的には、Pod Security Standards (PSS) という標準化されたセキュリティプロファイルを適用し、悪意のある設定や脆弱な設定を持つPodがクラスタ内で動作することを未然に防ぎます。

詳細解説

ポッドセキュリティは、タクソノミでいう「セキュリティとガバナンス」の範疇において、クラスタの健全性を保つための基盤となります。Podはアプリケーションの実体であるため、Podの設定ミスや意図的な悪用は、クラスタ全体のリソースへの不正アクセスや権限昇格といった深刻な脅威に直結するからです。

目的と背景：なぜPod Securityが必要なのか

Kubernetesクラスタは、複数のテナントや多様なワークロードが混在することが一般的です。あるPodがホストのルート権限を取得したり、機密性の高いファイルシステムにアクセスできる状態にあると、そのPodを乗っ取られた場合にクラスタ全体が侵害されるリスクがあります。Pod Securityの目的は、このような過剰な権限を持つPodの実行を防止し、セキュリティのベストプラクティスを強制することにあります。

これは、以前使用されていた「Pod Security Policy (PSP)」の後継機能として導入されました。PSPは非常に柔軟でしたが、設定が複雑で、管理が難しいという課題がありました。そこで、Kubernetesコミュニティは、よりシンプルで標準化されたセキュリティポリシーのセットとして、Pod Security Standards (PSS) を定義し、それを適用する仕組みとしてPod Security Admission (PSA) を導入しました。この移行は、クラスタセキュリティの運用ガバナンスを大幅に改善したと言えます。

主要コンポーネント：PSSとPSA

ポッドセキュリティを構成する主要な要素は、以下の二つです。

Pod Security Standards (PSS)：
これは、Podが満たすべきセキュリティ要件を定義した標準セットです。PSSには、セキュリティレベルに応じて主に以下の3つのプロファイルが用意されています。
- Privileged（特権）: 最も制限が緩いプロファイルで、既定のセキュリティ設定を無視し、ホストリソースへの広範なアクセスを許可します。これは、クラスタシステムコンポーネントやネットワークプラグインなど、非常に特殊な用途にのみ使用されるべきです。
- Baseline（ベースライン）: 一般的なアプリケーションのワークロードに対して推奨される、最低限のセキュリティ対策を適用します。既知の権限昇格のリスクを防ぎつつ、多くのアプリケーションが問題なく動作できる程度の自由度を保ちます。
- Restricted（制限付き）: 最も制限が厳しいプロファイルです。セキュリティのベストプラクティスを厳格に適用し、ホストへのアクセスをほぼ完全に遮断します。機密性の高い環境や、信頼できないユーザーからのPod実行を防ぐ場合に最適です。
Pod Security Admission (PSA)：
これは、KubernetesのAPIサーバーに組み込まれたAdmission Controller（受付制御機構）の一種です。ユーザーがPodを作成または更新しようとした際、PSAはPSSで定義されたルールに基づき、Podのマニフェストを評価します。

仕組み：セキュリティの強制と監査

PSAは、ネームスペース（名前空間）単位でPSSのプロファイルを適用します。ネームスペースに設定されたポリシーに基づき、Podの要求を以下の3つのモードで処理します。

Enforce（強制）: ポリシーに違反するPodの作成や更新を完全に拒否します。これにより、セキュリティリスクのあるPodがクラスタにデプロイされるのを防ぎます。これがクラスタセキュリティの「盾」の役割を果たします。
Audit（監査）: ポリシー違反があってもPodの実行は許可しますが、その違反内容を監査ログに記録します。将来的な強制適用に備え、どのPodが違反しているかを把握するために使用されます。
Warn（警告）: ポリシー違反があっても実行は許可しますが、ユーザーに対して警告メッセージを返します。開発環境や移行期間中に、影響を把握するために役立ちます。

このように、ポッドセキュリティは、オーケストレーション環境の「セキュリティとガバナンス」を維持するために、Podのライフサイクルの非常に早い段階で介入し、クラスタ全体の安全を担保しているのです。

具体例・活用シーン

1. 開発環境と本番環境の区別

多くの企業では、開発環境（Dev）と本番環境（Prod）でPod Securityの適用レベルを変えています。

開発環境のネームスペース: PSSをBaselineモード（AuditまたはWarn）で適用します。これにより、開発者は比較的自由にPodを実行できますが、基本的なセキュリティリスクについては警告を受け取ることができます。
本番環境のネームスペース: PSSをRestrictedモード（Enforce）で適用します。これにより、本番環境では、セキュリティ上問題のある設定を持つPodは一切実行できなくなり、クラスタセキュリティが厳格に守られます。

2. コンテナオーケストレーションにおけるセキュリティのガードレール

ポッドセキュリティの役割を理解するために、セキュリティを「マンションの入居規則」に例えてみましょう。

Kubernetesクラスタ全体を巨大なマンション（データセンター）と考えると、Podはその中にある個々の部屋（アプリケーションインスタンス）です。

クラスタセキュリティ（マンション管理組合）: マンション全体の安全を守る責任があります。
Pod Security Standards (PSS)（入居規則）: 「部屋の中で火気厳禁」「玄関の鍵は必ず二重ロック」といった、すべての入居者が守るべきセキュリティルールです。
- Privileged は、「管理人が使う特別な部屋」で、ルールの一部が免除されます。
- Restricted は、「厳重なセキュリティが必要な金庫室」で、窓を開けることすら制限されます。
Pod Security Admission (PSA)（入居審査官）: 新しい入居者（Pod）が引っ越してこようとしたとき、PSAがマニフェスト（入居申込書）をチェックします。もし申込書に「私は部屋で爆竹を使います」と書いてあった場合（セキュリティ違反の設定）、入居審査官（PSA）は即座にそれを拒否（Enforce）し、クラスタセキュリティを維持します。

このように、Pod Securityは、個々のPodがクラスタ全体に迷惑をかけないように、実行前にルールを強制する「セキュリティのガードレール」として機能しているのです。

資格試験向けチェックポイント

ポッドセキュリティは、Kubernetesの管理や運用に関する資格試験（CKA, CKADなど）はもちろん、ITパスポート、基本情報技術者、応用情報技術者といった日本の主要なIT資格においても、クラウド時代のセキュリティとガバナンスの文脈で出題される可能性があります。

頻出ポイントと対策

Kubernetesのセキュリティ機能としての位置づけ:
Pod Securityは、ネットワークポリシー、RBAC（Role-Based Access Control）と並ぶ、Kubernetesのクラスタセキュリティを実現するための主要な手段の一つであることを理解しておきましょう。特に、Podレベルでの権限抑制を目的としている点が重要です。
PSP（Pod Security Policy）からの置き換えの理解:
以前の仕組みであるPSPは複雑すぎたため、よりシンプルで標準化されたPSS/PSAに置き換えられたという経緯は、Kubernetesの歴史的文脈として重要です。「PSPは非推奨となり、PSAが推奨される」という知識は、応用情報技術者試験などで問われる可能性のあるトピックです。
PSSの3つのレベル（Privileged, Baseline, Restricted）:
この3つのプロファイルの違いと、それぞれがどのようなユースケースに対応しているかを把握しておくことが必須です。
- Privileged: 特権的な操作を許可（ほぼ制限なし）。
- Baseline: 一般的なアプリ向け（最低限の制限）。
- Restricted: 高いセキュリティ要件向け（厳格な制限）。
Admission Controllerの役割:
PSAがAPIサーバーのAdmission Controllerとして機能し、Podの作成要求時にセキュリティチェックを行うという仕組みを理解しておくと、Kubernetesの内部構造の理解が深まります。これは、オーケストレーション技術の詳細な仕組みを問う問題で役立ちます。
適用単位はネームスペース:
Pod Securityのポリシー適用は、クラスタ全体ではなく、ネームスペースごとに設定されるという点も、ガバナンス設計の観点から重要です。