KubernetesでprivilegedコンテナをどこまでAdmission Controlで止めるか――Podセキュリティの設計判断

KubernetesのprivilegedコンテナをAdmission Controlで制御する設計は、「全面禁止か全面許可か」の二択では成立しません。正当な用途を定義し、例外を申請・審査・監査できる仕組みを整えることが核心です。PodSecurityAdmissionの三ポリシーとAdmission Webhookの組み合わせを理解することで、セキュリティと運用性を両立した構造を段階的に作り上げられます。各H2では、どのポリシーをどのタイミングでどの粒度で適用するかという設計判断の軸を順に整理します。

privilegedが必要な正当ユースケースと代替可能なケースの整理

「privilegedでなければならない」ユースケースの条件

privilegedコンテナが本当に必要なのは、ホストカーネルの機能に直接アクセスしなければならないワークロードに限られます。代表例はeBPFベースの観測ツールです。FalcoやDatadogエージェントの一部機能は、カーネルのeBPFサブシステムへのアクセスを要求します。CNIプラグインのインストールコンポーネント（FlannelやCalicoのノードデーモン）は、ホストネットワーク設定の変更のためにprivilegedを要求するケースがあります。GPUやSR-IOVといったハードウェアデバイスへのアクセス、あるいはカーネルモジュールのロードが必要なワークロードも同様です。これらは代替手段が現状では存在しない「真のユースケース」として扱うべき対象です。

Linux Capabilityで代替可能なケースの見分け方

privilegedを指定していても、Linux Capabilityの個別付与で代替できるケースは多くあります。NET_ADMINはネットワーク設定変更、SYS_PTRACEはプロセストレース、DAC_READ_SEARCHはファイルシステムの権限回避に対応します。必要な権限だけを付与することで、攻撃面を大幅に絞り込めます。よくあるつまずきとして、開発時の便宜でprivilegedを設定したマニフェストが本番環境にそのまま使い続けられるケースがあります。既存クラスタでマニフェストを棚卸しすると、全体の3〜5割程度でprivilegedが不要と判断できることがあります（想定例）。このような実態は調査して初めて把握できるため、設計の起点として棚卸しを位置づけることが重要です。

代替可否を判断するための設計アプローチ

どのsyscallが実際に必要かを把握するには、seccompのログ機能をステージング環境で有効にし、呼ばれるsyscallの一覧を収集する方法が有効です。設計判断の軸は「ホストカーネルの名前空間や特権syscallに直接触れる必要があるか」の一点に集約できます。これがNoであれば、Capabilityの最小化や非特権コンテナへの変更を検討できます。seccompプロファイルの具体的な設定手順はインフラ構築の実践書で確認してください。設計フェーズで重要なのは手順ではなく「何を調べれば判断できるか」という情報収集の設計です。

PodSecurityAdmission三ポリシーの比較と適用設計

三ポリシーの制御範囲と位置づけ

Kubernetes 1.25でGAとなったPodSecurityAdmission（PSA）は、privileged・baseline・restrictedの三段階をネームスペース単位で適用します。privilegedは制限なし、baselineはprivilegedコンテナやhostNetworkなど高リスクな設定を禁止しつつ最低限の互換性を維持します。restrictedはSecurityContextの詳細設定まで含む最も厳格なポリシーで、runAsNonRootやallowPrivilegeEscalation: falseが必須要件です。三段階の違いを把握することが、どのネームスペースにどのポリシーを割り当てるかという設計判断の土台になります。

ポリシー	privilegedコンテナ	hostNetwork / hostPID	runAsNonRoot	allowPrivilegeEscalation	主な適用対象
privileged	許可	許可	不問	不問	kube-system等インフラNS
baseline	禁止	禁止	不問	不問	一般アプリNS（移行初期）
restricted	禁止	禁止	必須	false必須	本番アプリNS（長期目標）

適用モード（enforce/audit/warn）の設計的意味

各ポリシーにはenforce・audit・warnの三つの適用モードがあります。enforceはポリシー違反のPodを拒否し、auditはAPIサーバーの監査ログに記録、warnはクライアントに警告を返します。既存クラスタに初めてポリシーを適用する際、いきなりenforceを設定すると既存ワークロードが停止するリスクがあります。auditとwarnから始め、違反件数がゼロに近づいたことを確認してからenforceに切り替えるのが設計上の基本的な順序です。三つのモードは排他ではなく、同じポリシーに対して同時に設定できるため、auditで計測しながらwarnで開発者にフィードバックを返す併用も有効です。

ポリシー適用時の代表的な落とし穴

baselineポリシーを適用しようとするネームスペースに、システムコンポーネントのdaemonSetが混在しているケースが代表的な落とし穴です。kube-systemと同じネームスペースにアプリワークロードが存在すると、baselineを適用できずprivilegedのまま運用が続くことになります。ネームスペース設計を先に整理し、システムコンポーネントとアプリワークロードを分離してからポリシーを適用するという順序が、設計上の重要な判断ポイントです。既存クラスタでこの分離が不十分な場合、ポリシー適用前にネームスペース再設計を挟む工程が必要になります。

Admission Webhookとビルトインポリシーの使い分け境界

ビルトインPSAだけで足りる条件

PSAのビルトインポリシーで十分なのは、制御要件が三段階のいずれかに収まりネームスペース単位の粒度で制御できる場合です。ノード数が100台以下の比較的小規模なクラスタや、ワークロードの種類が限定されているバッチ系の環境では、PSAの三段階とネームスペース分離でほとんどのケースを網羅できます。Admission Webhookを追加しないほうが、アドミッションチェーンのレイテンシと保守コストを抑えられます。まずPSAで設計を完結させ、要件が複雑になった段階でWebhookを追加するという段階的なアプローチが現実的です。

Admission Webhookが必要になる判断基準

ビルトインPSAを超えた制御が必要になるのは、特定のコンテナレジストリからのイメージのみを許可したい、ラベルによって動的にポリシーを変更したい、複数クラスタで共通のポリシーライブラリを管理したい、といった要件が生じた場合です。PSAはPodの仕様を対象にするため、IngressやServiceAccountに対してポリシーを適用したい場合もWebhookが必要になります。組織のコンプライアンス要件がPSAの三段階に収まらないと判断した時点が、Webhook導入を検討するタイミングです。

OPA GatekeeperとKyvernoの使い分け観点

Admission Webhookの代表実装であるOPA GatekeeperとKyvernoは、設計思想が異なります。GatekeeperはRegoという宣言的言語でポリシーを記述し、Constraintオブジェクトとして管理します。ポリシーを汎用的に設計して複数クラスタで再利用したい場合や、監査レポートを細かく制御したい場合に適しています。KyvernoはKubernetesネイティブのYAML形式でポリシーを記述するため、既存のマニフェスト管理フローに統合しやすい特徴があります。どちらも監査モード（既存リソースをスキャンして違反を報告する機能）を持ち、段階的な導入に活用できます。チームのRegoスキルとYAML管理の運用方針を軸に選定するのが実用的な判断基準です。

例外許可の申請フローと審査基準設計

申請に記録すべき情報の設計

privilegedコンテナの例外を許可する際は、「なぜprivilegedが必要か」「代替手段を検討したか」「どのCapabilityが実際に必要か」「次回レビューの期限はいつか」の四点を申請時に記録する設計が有効です。GitOpsフローでネームスペースのLabelをPull Requestで管理し、承認者が記録をレビューする形にすれば、例外が増えた際も経緯を追跡できます。記録のない例外は次回定期レビューで削除対象とするルールを設計段階で定めておくことが重要です。例外の追跡可能性は、後続の監査や見直しで設計の信頼性を保つ基盤になります。

Namespaceラベルによる例外管理の落とし穴

PSAではNamespaceにpod-security.kubernetes.io/enforce: privilegedのラベルを付けることで例外を設定しますが、clusteradmin権限を持つ担当者がkubectl editで直接変更できてしまう構成は危険です。ラベルの変更をGitOpsで管理し、Pull Requestの承認なしに変更できない体制を整えないと、申請なしに例外ラベルが付与されるインシデントが発生します。NamespaceのLabelを書き換えるRBAC権限を別途制限する設計も合わせて検討します。運用上の落とし穴は「技術的に可能な操作」と「組織として許可された操作」のギャップから生まれます。

定期レビューの組み込み方

一度許可した例外ネームスペースは、半年〜1年ごとの定期レビューを仕組みとして組み込んでおくことが望ましいです。レビュー時の判断基準は「ワークロードのバージョンアップで代替手段が生まれていないか」「依存コンポーネントに変更はないか」の二点が軸になります。定期レビューの仕組みがないと、例外が雪だるま式に増えて管理不能になるという一般的な失敗パターンに陥ります。例外ラベルにannotationで有効期限を付け、期限切れをCI/CDパイプラインで検知する仕組みが実用的な選択肢です。

daemonSetとシステムコンポーネントの扱い方設計

システムNamespaceへのポリシー適用設計

kube-systemなどのシステムネームスペースには、原則としてprivilegedポリシーを適用します。KubernetesのコアコンポーネントがhostNetworkやhostPIDを要求するためです。設計上の重要ポイントは、システムネームスペースとアプリネームスペースを明確に分離することです。本番クラスタでは少なくともkube-system・monitoring・ingress-controller・アプリ用NSの4系統以上に分離することが、ポリシー適用の実行可能な前提条件になります（想定例）。この分離が不十分なままポリシーを適用しようとすると、システムコンポーネントへの影響を理由に適用が頓挫する原因になります。

daemonSetのprivileged要件を最小化する設計手法

ノードに配置するdaemonSetはprivilegedを要求しやすいコンポーネントですが、設計段階で要件を精査することで要求を最小化できます。ログ収集エージェントはhostPathマウントだけで動作するものが多く、監視エージェントもCapabilityの個別付与（NET_ADMINなど）で代替できるケースがあります。「daemonSetだからprivileged」という思い込みを避け、各daemonSetが実際に必要とするホストアクセスの種類を1件ずつ確認することが設計上のポイントです。daemonSetの数が10件を超えるクラスタでは、この確認作業を表にまとめて管理すると設計の見通しがよくなります（想定例）。

サードパーティ製品のprivileged要件への対応

セキュリティツールやサービスメッシュのコンポーネントなど、サードパーティ製品がprivilegedを要求してくる場合も設計上の対処が必要です。ベンダーのドキュメントや問い合わせを通じて「なぜprivilegedが必要か」の技術的根拠を確認することが第一歩です。製品によっては特定のCapabilityのみ付与した設定オプションが用意されているケースがあります。根拠を確認せずに要求されたままのprivilegedを許可し続けると、製品アップデートのたびにクラスタ全体のセキュリティ水準が左右されるリスクがあります。

ポリシー違反を検知する監査ログの設計

auditモードで記録される内容の把握

PSAのauditモードはKubernetesのAPIサーバー監査ログにポリシー違反を記録します。記録される内容は、対象ネームスペースのポリシーに違反したPodの作成・更新リクエストです。ログエントリにはネームスペース名、違反したポリシー種別、リクエストを行ったユーザーとサービスアカウントが含まれます。GatekeeperやKyvernoを使う場合はより詳細な制約違反情報を出力できます。監査ログの設計では、どのレベルのイベントをどのストレージに何日間保持するかを事前に定義しておくことが設計判断の基本です。

アラート設計の判断軸

監査ログからアラートを生成する際の判断軸は「頻度」と「実行主体」の二点です。特定のサービスアカウントからprivilegedリクエストが急増している場合は即時アラートが有効です。一方、定常的に低頻度で発生する違反は日次バッチでサマリーを送る設計が保守しやすいです。アラートが多すぎると担当者が慣れて無視するようになるため、閾値は実際の違反件数を2〜3週間計測してから設定するのが実用的な方針です。初期設定を厳しくしすぎないことがアラート設計の重要な原則です。

違反の可視化設計

複数クラスタを横断して管理する場合、ポリシー違反の件数・種別・ネームスペース分布を一覧できる仕組みが設計判断の材料になります。GatekeeperはConstraintStatusに違反情報を記録するため、Prometheusでスクレイプしてダッシュボードに表示する構成がよく用いられます。KyvernoもPolicyReport CRDを通じた可視化が可能です。このダッシュボードの主な用途は「どのネームスペースを優先してenforceに昇格できるか」を判断する材料にすることです。可視化の目的を運用負荷の把握ではなく設計判断の支援と位置づけると、必要な指標が絞り込みやすくなります。

既存クラスタへの段階的ポリシー適用の設計

適用前の現状把握フェーズ設計

既存クラスタへのポリシー適用を始める前に、現状のワークロードがどのポリシーレベルに準拠しているかを把握する調査フェーズが必要です。GatekeeperやKyvernoの監査モード、あるいはPolarisなどのツールを使えば、既存リソースがbaseline・restrictedのどちらに違反しているかを一覧できます。この調査を省略して直接enforceを適用すると、本番ワークロードが停止するリスクがあります。調査フェーズでは違反件数の多いネームスペースを優先度の高いものとして整理し、適用計画を立てることが有効です。調査結果は後続の設計判断を支える基礎データとして文書化しておきます。

warn/auditから始める段階的移行設計

段階的適用の基本は「warn → audit → enforce」の順序で進めることです。warnを設定するとクライアントに警告が返りますが、Podの作成は通過します。これにより開発者はエラーに気づきながら作業を続けられます。auditを追加すると違反の発生頻度と実行主体を把握できます。この状態を2〜4週間維持し、新規の違反が発生しなくなったことを確認してからenforceに切り替えるという判断フローが安全な設計です。warnとauditを同時に設定し、開発チームへのフィードバックと記録を並行して進める方法も有効です。

enforceへの切り替え判断チェックリスト

enforceへの切り替え前に確認すべき判断基準を以下に整理します。すべての条件を満たしていることを確認してから進めることが、ワークロード停止リスクを抑える上で重要です。

• 対象ネームスペースでauditモードの違反件数が7日間連続でゼロであること
• daemonSetを含むすべての管理対象PodのマニフェストをPSA準拠に更新済みであること
• 例外が必要なワークロードに対して申請・承認フローが完了済みであること
• ポリシーをprivilegedに戻すロールバック手順をRunbookに記載済みであること
• 切り替えをトラフィック低負荷時間帯（深夜・休日等）に設定済みであること
• 切り替え後1週間は監視アラートの閾値を通常より低めに設定済みであること

既存クラスタ全体をrestrictedに移行するには、一般的に半年〜1年以上のプロジェクト期間を要します。一度に全ネームスペースを移行しようとするのではなく、新規作成ネームスペースからrestricted適用を始め、既存ネームスペースを計画的に移行する設計が現実的な進め方です。段階的に進めることで、各フェーズで得た知見を次のネームスペースの設計に反映できます。