リクルーティングサイト
テックカリキュラム

Pod Security Standardsとの統合 ── Kubernetes標準セキュリティとOPA Gatekeeperの最適設計

Pod Security Standardsとの統合 ── Kubernetes標準セキュリティとOPA Gatekeeperの最適設計

はじめに

Kubernetes 1.25以降、従来のPodSecurityPolicy（PSP）は完全に廃止され、代わりにPod Security Standards（PSS）が標準化されました。

しかし、PSSはあくまで「ベースラインのセキュリティ標準」であり、組織ごとの詳細なルールや高度な制御まではカバーしきれません。

そこで重要になるのが、PSS + OPA Gatekeeperの統合設計です。

  • PSSでベースラインを担保
  • Gatekeeperで高度・組織固有ルールを適用

KubernetesではNamespaceラベルによってPSSを適用します。

1. Pod Security Standards（PSS）とは？

PSSはKubernetesが定義するセキュリティ標準で、3つのレベルがあります。

レベル説明用途
Privileged制限なし特別用途
Baseline基本的なセキュリティ制限一般用途
Restricted最も厳格な制限本番環境推奨

Restrictedで制限される主な項目

  • privilegedコンテナ禁止
  • hostPath使用制限
  • rootユーザー禁止（runAsNonRoot必須）
  • CAP_SYS_ADMINなど危険なCapabilities禁止

<h2>2. PSSの有効化方法（Namespace単位）</h2>

KubernetesではNamespaceラベルによってPSSを適用します。

kubectl label namespace prod \ pod-security.kubernetes.io/enforce=restricted \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/warn=restricted

3つのモード

  • enforce：違反時は拒否
  • audit：ログのみ
  • warn：警告表示

3. PSSの限界

PSSは強力ですが、特定イメージレジストリのみ許可やNamespaceごとに異なるルール適用、タグ名（latest禁止）、リソース制限の詳細な制御、組織固有ラベルの必須化のような高度制御はできません。

ここでOPA Gatekeeperの出番です。

4. PSS + Gatekeeper の統合アーキテクチャ

 Kubernetes API Server ↓ Pod Security Admission（PSS） ↓ OPA Gatekeeper ↓ 許可 or 拒否

PSSが「標準的なセキュリティベースライン」を担保し、 Gatekeeperが「組織固有ルール」を補完します。

5. 実践例：PSSでは不足する制御をGatekeeperで補完

① 特定レジストリのみ許可

package k8sregistry violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not startswith(container.image, "123456789.dkr.ecr.ap-northeast-1.amazonaws.com/") msg := sprintf("許可されていないレジストリです: %v", [container.image]) }

② runAsNonRootを強制（PSS補強）

package k8snonroot violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "runAsNonRootを必須とします" }

③ 本番環境ではhostNetwork禁止

package k8shostnetwork violation[{"msg": msg}] { input.review.object.metadata.namespace == "prod" input.review.object.spec.hostNetwork == true msg := "prod環境ではhostNetworkは禁止です" }

6. ベストプラクティス：段階的統合戦略

Step1：PSSを全Namespaceに適用（Baseline）

Step2：本番環境はRestrictedへ引き上げ

Step3：Gatekeeperで追加制御

  • イメージ制限
  • リソース制限
  • 環境別制御
  • コスト制御

7. 監査（Audit）との連携

Gatekeeperでは既存リソースの監査も可能です。 

kubectl get constraint kubectl describe constraint

さらに、Prometheusと連携すれば違反メトリクスも収集可能です。

8. 実務での統合モデル

レイヤー役割
PSSベースラインセキュリティ
Gatekeeper組織固有ポリシー
CI/CD（OPA）事前チェック
Terraform Sentinelインフラ作成制御

この多層構造が、ゼロトラスト型Kubernetes運用の基本形となります。

まとめ

  • PSSはKubernetes標準のセキュリティ基盤
  • Restrictedレベルは本番環境で推奨
  • Gatekeeperで高度な組織ポリシーを補完
  • CI/CD・IaCとも連携することで完全自動統制が可能

重要なのは、「単一ツール依存ではなく、レイヤードセキュリティを設計すること」です。

関連カリキュラム