PodSecurityPolicy から PodSecurity アドミッション コントローラに移行する

このページでは、PodSecurityPolicy から PodSecurity アドミッション コントローラに移行することで、Google Kubernetes Engine（GKE）クラスタで多くの Pod レベルのセキュリティ制御を継続的に適用する方法について説明します。

概要

PodSecurityPolicy は Kubernetes アドミッション コントローラであり、これにより Kubernetes Pod Security Standards などの Pod レベルのセキュリティ制御を適用し、デプロイされたワークロードのセキュリティ構成をきめ細かく制御できます。Kubernetes プロジェクトでは PodSecurityPolicy が非推奨になり、機能は Kubernetes v1.25 で完全に削除されました。

現在 GKE クラスタで PodSecurityPolicy を使用している場合は、GKE バージョン 1.25 以降にアップグレードする前に、この機能を無効にしてください。

PodSecurityPolicy の非推奨と削除については、PodSecurityPolicy の非推奨をご覧ください。

PodSecurity と PodSecurityPolicy

PodSecurity アドミッション コントローラは、次の GKE バージョンを実行しているクラスタで使用可能で、デフォルトで有効になっています。

  • バージョン 1.25 以降: 安定版
  • バージョン 1.23 とバージョン 1.24: ベータ版

PodSecurity を使用すると、デプロイしたワークロードに対して、Pod セキュリティ標準で定義されたポリシーを適用できます。PodSecurity を使用すると、PodSecurityPolicy から移行した後も、推奨される Pod レベルのセキュリティ構成を引き続きクラスタに実装できます。PodSecurityPolicy とは異なり、PodSecurity はカスタム構成をサポートしていません。

要件と制限事項

  • PodSecurity は、GKE バージョン 1.23 と 1.24 ではベータ版、GKE バージョン 1.25 以降では安定版で使用できます。
  • PodSecurity は、ノードで実行中の Pod を、適用されたポリシーに違反する場合でも終了しません。
  • PodSecurity はフィールドを変更しません。PodSecurityPolicy の変更フィールドを使用する場合は、Pod 仕様を変更して、ワークロードのデプロイ時にそれらのフィールドが存在するようにします。

始める前に

作業を始める前に、次のことを確認してください。

  • Google Kubernetes Engine API を有効にします。
    • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得します。
  • バージョン 1.23 以降を実行する GKE Autopilot または Standard クラスタがあることを確認します。
  • 変更フィールドの構成について PodSecurityPolicy リソースを確認します。これらのフィールドを Pod マニフェストに追加して、ノードですでに実行されているワークロードが Pod セキュリティ標準で定義されたポリシーに準拠するようにします。手順については、Pod セキュリティ ポリシーを簡素化して標準化するをご覧ください。

クラスタで PodSecurity アドミッション コントローラを構成する

PodSecurity アドミッション コントローラは、名前空間レベルで Pod のセキュリティ標準を適用します。各名前空間で Pod のセキュリティ標準で定義されたポリシーのいずれかを適用するようにコントローラを構成する必要があります。次のポリシーを使用できます。

  • Restricted: 最も厳しいポリシー。Pod の強化のベスト プラクティスに沿っています。
  • Baseline: 既知の権限昇格を防ぐ最小限のポリシー。Pod 仕様のフィールドのデフォルト値をすべて許可します。
  • Privileged: 既知の権限昇格を含め、すべて許可可能な無制限のポリシー。このポリシーは慎重に適用してください。

PodSecurityPolicy 構成を PodSecurity アドミッション コントローラに移行するには、クラスタ内のすべての Namespace で次の操作を行います。これらの手順については、以降のセクションで詳しく説明します。

  1. dry-run モードの Restricted ポリシーを名前空間に適用し、違反を確認します。
  2. Pod が Restricted ポリシーに違反している場合は、dry-run モードの、より制限の少ない Baseline ポリシーを名前空間に適用して、違反をチェックします。
  3. Pod が Baseline ポリシーに違反している場合は、Pod 仕様を変更して違反を修正します。
  4. Baseline ポリシーが違反を返さなくなったら、enforce モードのポリシーを名前空間に適用します。

PodSecurity が新しい Pod を拒否した場合にダウンタイムが発生しないようにするには、ステージング環境でこれらの手順を実行します。または、識別されたポリシーを enforce モードではなく audit モードで適用し、監査ログを確認して拒否された可能性のある Pod を見つけることもできます。

audit モードではポリシーを適用しません。GKE は Pod をデプロイし、GKE 監査ログにエントリを追加します。

クラスタ内のすべての名前空間を一覧表示する

クラスタ内のすべての名前空間のリストを取得します。リスト内のすべての名前空間に対して、次のセクションの手順を繰り返します。

kubectl get ns

次の GKE バージョンでは、GKE は kube-system 名前空間に適用するポリシーを無視します。

  • 1.23.6-gke.1900 以降
  • 1.24.0-gke.1200 以降

以前のバージョンの GKE では、kube-system にポリシーを適用することは避けてください。

Pod セキュリティ標準の各ポリシーをドライラン モードで適用する

次の手順では、最も制限の厳しい Restricted ポリシーから順に、dry-run モードで各ポリシーを適用します。出力に警告が表示された場合は、ポリシー違反の Pod 仕様を変更してポリシーに準拠するか、制限の少ない Baseline ポリシーを試します。出力に警告が表示されない場合は、dry-run モードなしで Baseline ポリシーを適用できます。

  1. dry-run モードで Restricted ポリシーを適用します。

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted

    名前空間内の Pod が Restricted ポリシーに違反している場合、出力は次のようになります。

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled

    Restricted ポリシーに警告が表示された場合は、Pod を変更して違反を修正してから、コマンドを再試行してください。または、次のステップで制限の少ない Baseline ポリシーを試してください。

  2. Baseline ポリシーを dry-run モードで適用します。

    kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

    名前空間内の Pod が Baseline ポリシーに違反している場合、出力は次のようになります。

    Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

Pod が Baseline ポリシーに違反している場合は、Pod を変更して違反を修正し、GKE に警告がなくなるまでこの手順を繰り返します。

名前空間にポリシーを適用する

名前空間で機能するポリシーを特定したら、そのポリシーを enforce モードで名前空間に適用します。

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

POLICY は、ポリシーの名前に置き換えます。restricted、baseline、privileged のいずれかです。

クラスタ内のすべての名前空間に対して、上の手順を繰り返します。

クラスタで PodSecurityPolicy 機能を無効にする

クラスタ内のすべての名前空間に PodSecurity アドミッション コントローラを構成したら、PodSecurityPolicy 機能を無効にします。

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

CLUSTER_NAME を GKE クラスタの名前に置き換えます。

クラスタを GKE バージョン 1.25 にアップグレードすると、GKE は残りのすべての PodSecurityPolicy オブジェクトを自動的に削除します。これには、GKE、Policy Controller、以前に定義した PodSecurityPolicy オブジェクトによって追加されたオブジェクトが含まれます。

推奨事項

  • 可能な限り、制限付きのポリシーを遵守するようにしてください。アプリケーションを監査して、構成をさらに強化できるかどうかを確認してください。
  • 前の手順で kubectl label コマンドに pod-security.kubernetes.io/MODE-version: VERSION ラベルを追加すると、Pod セキュリティ モードを特定の Kubernetes マイナー バージョンにロックできます。VERSION は、Kubernetes のバージョン番号（v1.24 など）に置き換えます。
  • PodSecurityPolicy 機能を無効にした後、実行中のアプリケーションを確認して、セキュリティ構成の中断やギャップを確認します。
  • PodSecurity を構成したら、名前空間作成プロセスを更新して、すべての新しい名前空間に PodSecurity ラベルを自動的に適用します。詳細については、名前空間作成プロセスの確認をご覧ください。

次のステップ