ポッド セキュリティ ポリシーからの移行: 包括的なガイド (パート 1: PSA への移行)

導入

Kubernetes が主要なコンテナ オーケストレーション プラットフォームとして成熟し続ける中、コンテナ化されたアプリケーションを展開する組織にとってセキュリティは依然として最大の懸念事項です。 Kubernetes のセキュリティ兵器の基本ツールの中で、 Pod Security Policies (PSP) はかつて極めて重要な役割を果たしていました。 PSP を使用すると、管理者はポッドにセキュリティ制約を細心の注意を払って定義して適用し、特定のセキュリティ標準を満たすコンテナのみがクラスタ内で動作できるようにすることができました。

ただし、Kubernetes セキュリティの状況は急速に進化しており、Kubernetes 1.25 から PSP が非推奨になったことに注意することが重要です (Kubernetes 1.25 緊急リリース ノートへのリンクを参照)。この変更は、PSP ポリシーの管理と維持の複雑さを含むさまざまな要因に起因しており、多くの場合、ユーザーにとって運用上の課題につながります。

非推奨に対応して、組織は現在、PSP に代わる最新の代替手段、セキュリティ要件に対処するだけでなく、 Kubernetesでワークロードを保護するプロセスを合理化する手段を探しています。

この包括的なガイドでは、Pod Security Admission (PSA) への移行に焦点を当てて、Kubernetes セキュリティ実践におけるこの変化をナビゲートする旅に乗り出します。 PSA は利用可能な最も堅牢な代替手段の 1 つであり、この記事では PSA について詳しく説明します。ただし、他の 2 つの代替手段、Kyverno と OPA Gatekeeper については、このシリーズ内の別の記事で取り上げることに言及する価値があります。

この記事では、PSA のセットアップとインストールに関する詳細な手順、PSP から PSA にスムーズに移行するための段階的な移行ガイド、および既存の PSP ルールを PSA に転送するための正確なコマンドを説明します。さらに、PSA に合わせたドライラン コマンドを使用して、名前空間の移行の準備状況を評価するための知識も得られます。

このガイドを読み終えるまでに、PSA の長所と限界を包括的に理解し、組織固有のセキュリティ要件と Kubernetes 環境に基づいて情報に基づいた意思決定を行えるようになります。

このガイドを使用すると、自信を持って Kubernetes セキュリティ プラクティスを最新化し、ポッド セキュリティ ポリシーの時代に別れを告げながらワークロードを保護し続けることができます。

ポッド セキュリティ アドミッション (PSA)

• PSA は Kubernetes セキュリティ標準を強制します: PSA は、コンテナがポッド セキュリティ標準で定義されている Kubernetes のネイティブ セキュリティ標準に準拠していることを保証します。これらの標準は、セキュリティ ポリシーを 3 つの異なるプロファイルに分類し、それぞれに異なる制限レベルがあります。

  
  

  • Privileged : Privileged ポリシーは意図的にオープンであり、完全に制限されていません。通常、このポリシーは、信頼できるユーザーが管理するシステム レベルおよびインフラストラクチャ レベルのワークロードを対象とします。制限がないのが特徴です。 Gatekeeper などのデフォルトで許可するメカニズムは本質的に特権ですが、ポッド セキュリティ ポリシー (PSP) などのデフォルトで拒否するメカニズムでは、特権ポリシーですべての制限を無効にする必要があります。

  • ベースライン: ベースライン ポリシーは、既知の権限昇格を防ぎながら、一般的なコンテナ化されたワークロードで簡単に導入できるように設計されています。アプリケーション オペレーターと、重要ではないアプリケーションの開発者に対応します。

  • Restricted : Restricted ポリシーは、互換性を多少犠牲にする可能性はありますが、厳密な Pod 強化のベスト プラクティスを強制することに重点を置いています。主に、セキュリティ クリティカルなアプリケーションのオペレータと開発者、および信頼性の低いユーザーを対象としています。各プロファイルで強制または禁止する必要がある制御の包括的なリストについては、公式ドキュメントを参照してください。

    
    

• PSP ルールの直接転送がない:他のソリューションとは異なり、PSA はポッド セキュリティ ポリシー (PSP) ルールを直接移行または変更する簡単な方法を提供しません。 PSA の主な焦点は、上記のプロファイルを含む、確立されたKubernetes セキュリティ標準に照らしてポッドを検証することです。

• 突然変異なし: PSA は検証には有効ですが、PSP のようにポッドの仕様を変更したりカスタマイズしたりすることはできません。 PSA の主な目的は、事前定義された Kubernetes セキュリティ標準を強制することであり、ポッド仕様を変更または変更する機能は含まれていません。主に、これらの確立された標準に照らしてポッドを検証することに重点を置いています。

セットアップとインストール

PSA は Kubernetes ネイティブ コンポーネントであるため、これを機能させるには、Pod Security Admission (PSA) コントローラーが Kubernetes クラスターで有効になっていることを確認するだけで済みます。これを行うには、次のコマンドを実行します。

kubectl api-versions | grep admission

移行の準備手順

名前空間の権限を評価する

ポッド セキュリティ アドミッションの制御は、名前空間ラベルの影響を受けます。これは、ネームスペースを更新、パッチ適用、または作成できる個人には、それらのネームスペースのポッド セキュリティ設定を変更する権限も与えられていることを意味します。この変更により、より厳格なセキュリティ ポリシーが回避される可能性があります。続行する前に、名前空間のアクセス許可が信頼された特権ユーザーのみに割り当てられていることを確認することが重要です。このようなアクセスを必要としないユーザーには、これらの昇格されたアクセス許可を付与しないことをお勧めします。名前空間オブジェクトにポッド セキュリティ ラベルを設定するために追加の制約が必要な場合は、アドミッション Webhook を利用してそれらの制約を強制することを検討してください。

PodSecurityPolicy の合理化と正規化

Pod Security Admission (PSA) に移行する前に、PodSecurityPolicies (PSP) を正規化すると有益です。

• サポートされていないフィールドを削除: ポッド セキュリティ標準でカバーされていないオプションを削除します。これらのオプションには次のものが含まれます。

  
  

 .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass

• 純粋に変更するフィールドを削除する: 変更の効果だけを持ち、検証ポリシーに影響を与えないフィールドを削除することでプロセスを開始します。これらのフィールドには、「PodSecurityPolicies とポッド セキュリティ標準のマッピング」リファレンスでも説明されているように、次のものが含まれます。

 .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities

適切なポッドのセキュリティ レベルを決定する

名前空間に適切なポッド セキュリティ レベルを決定する場合、考慮すべき方法がいくつかあります。

名前空間のセキュリティ要件による

名前空間に対して予想されるアクセス レベルとセキュリティ要件を理解している場合は、それらの特定の要件に基づいて適切なポッド セキュリティ レベルを選択できます。このアプローチは、新しいクラスターのセキュリティ設定にアプローチする方法と似ています。

既存の PodSecurityPolicy による:

「PodSecurityPolicies のポッド セキュリティ標準へのマッピング」リファレンスを利用して、既存の各ポッド セキュリティ ポリシー (PSP) を対応するポッド セキュリティ標準レベルにマッピングします。
PSP がもともとポッド セキュリティ標準に基づいていない場合は、決定を下す必要がある場合があります。少なくとも PSP と同じくらい許容的なポッド セキュリティ レベルを選択するか、少なくとも同じくらい制限的なレベルを選択します。特定の名前空間内のポッドにどの PSP が使用されているかを特定するには、次のコマンドを使用します。

 kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u

既存のポッドによる:

ドライランを実施し、次のセクションの label コマンドを適用して、ベースラインと制限付きポッド セキュリティ レベルの両方をテストします。これは、これらのレベルが既存のワークロードに対して十分に許容できるかどうかを評価するのに役立ちます。既存のワークロードに合わせて、最小権限の有効なレベルを選択してください。

ポッドのセキュリティ レベルのテスト

名前空間のポッド セキュリティ レベル (特権レベルを除く) を決定したら、選択したポリシーを検証することが重要です。 Pod Security は、スムーズな展開とセキュリティ標準への準拠を保証するためのテスト オプションを提供します。

ドライランテスト:

この方法は、選択したポリシーを即時に適用せずにその影響を評価する場合に使用します。
ドライ ランを実行するには、次のコマンドを使用します。これにより、指定されたポリシー レベルを満たさない既存のポッドが強調表示されます。

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

監査モードのテスト:

監査モードを使用すると、ポリシー違反を強制せずに記録できます。違反したポッドは、後で確認できるように監査レコードに記録されます。次のコマンドを使用して監査モードを有効にします。

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL

テスト中に予期しないポリシー違反が発生した場合は、次のことが可能です。

• ポリシーに合わせて非準拠のワークロードを更新します。
• ワークロード要件に合わせて、必要に応じて名前空間のポッド セキュリティ レベルを調整します。

ポッドのセキュリティ レベルの強制

選択したポッド セキュリティ レベルが名前空間に適切であると確信できたら、そのレベルの適用に進むことができます。この手順により、必要なセキュリティ標準が名前空間内のワークロードにアクティブに適用されるようになります。

ネームスペースに必要なポッド セキュリティ レベルを適用するには、次のコマンドを使用します。

 kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL

このコマンドを実行すると、指定されたポッド セキュリティ レベルがアクティブ化および強制され、名前空間のセキュリティ体制が強化されます。

PSPのバイパス

名前空間レベルで PodSecurityPolicy を効果的にバイパスするには、完全な特権を持つポッド セキュリティ ポリシー (PSP) を名前空間内のすべてのサービス アカウントにバインドできます。このプロセスにより、名前空間内のポッドは、PodSecurityPolicy によって課される変更や制限の影響を受けなくなります。これは、クラスター レベルまたは個々の名前空間レベルで行うことができます。

クラスタースコープのセットアップ (クラスター全体で 1 回だけ必要):

YAML 構成ファイル ( privileged-psp.yamlなど) を適用して、完全な特権を持つポッド セキュリティ ポリシー (PSP) を作成します。この PSP は、必要なすべての権限をポッドに付与し、Privileged-psp という名前のクラスター ロールを作成して、ポッド セキュリティ ポリシー (PSP) の使用を許可し、それを特権付き PSP に関連付ける必要があります。

 kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged

名前空間ごとの無効化:

ターゲット名前空間にロール バインディングを作成して、privileged-psp クラスター ロールをsystem:serviceaccounts:$NAMESPACEグループに関連付けます。このバインディングは、PodSecurityPolicy をバイパスして、名前空間内のすべてのサービス アカウントに完全な特権を持つ PSP へのアクセスを効果的に許可します。

 kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE

この設定では、特権付き PSP は非変異的であり、PodSecurityPolicy アドミッション コントローラーは常に非変異的 PSP を優先します。その結果、この名前空間内のポッドは PodSecurityPolicy によって変更または制限されなくなります。

このアプローチの利点の 1 つは、可逆性であることです。問題が発生した場合は、PodSecurityPolicy の無効化に関連付けられた RoleBinding を削除することで、変更を簡単にロールバックできます。このプロセス中、既存のポッド セキュリティ ポリシーがそのまま維持されるようにしてください。

PodSecurityPolicy の無効化を元に戻す:

名前空間の PodSecurityPolicy の無効化を元に戻すには、以前に作成した RoleBinding を削除するだけです。

 kubectl delete -n $NAMESPACE rolebinding disable-psp

名前空間作成プロセスを再確認する

ポッド セキュリティ アドミッションを適用するために既存の名前空間が更新されると、新しい名前空間を作成するためのプロセスとポリシーを確認して更新することが不可欠です。これにより、新しい名前空間が最初から適切な Pod Security プロファイルを使用して設定されるようになります。
名前空間の作成プロセスを強化するには、次の手順を検討してください。

1. 名前空間作成ポリシーの調整: 新しい名前空間を作成するための組織のポリシーと手順を更新して、必要なポッド セキュリティ レベルの選択と適用を含めます。セキュリティ標準が作成段階から確立されていることを確認します。

2. 静的構成: Pod Security アドミッション コントローラーを静的に構成して、ラベルのない名前空間のデフォルトの適用、監査、警告レベルを定義できます。このアプローチにより、明示的な Pod Security ラベルのない名前空間でも、デフォルトで指定されたセキュリティ標準に準拠することが保証されます。

   
   

   名前空間の作成プロセスを見直すことで、Pod Security 標準をKubernetes 環境にシームレスに統合し、新旧のすべての名前空間にわたって一貫した安全なアプローチを維持できます。

PodSecurityPolicy を無効にする

PodSecurityPolicy (PSP) アドミッション コントローラーが不要になり、Pod Security Admission (PSA) が正常に実装および検証されたことが確認できたら、PSP アドミッション コントローラーの無効化に進むことができます。

PSP アドミッション コントローラを無効にする手順は次のとおりです。

kube-apiserver 構成を変更します。

• kube-apiserver の構成ファイルを開きます。通常は/etc/kubernetes/manifests/kube-apiserver.yaml.
• --disable-admission-pluginsフラグを追加して、PSP アドミッション コントローラーを無効にします。アクティブなアドミッション プラグインのリストから削除されていることを確認します。

 kube-apiserver --disable-admission-plugins=PodSecurityPolicy

• 設定ファイルを保存します。

kube-apiserver を再起動します。

• kube-apiserver を再起動して、変更を適用します。通常、これを実現するには、Kubernetes コントロール プレーンまたは kube-apiserver ポッド自体を再起動します。

 systemctl restart kubelet

検証：

• kube-apiserver ログまたはそのステータスをチェックして、PSP アドミッション コントローラーが無効になっていることを確認します。

PSP にロールバックする必要がないことを確信できる十分な「ソークタイム」が経過したら、次のステップに進みます。

PSP リソースのクリーンアップ:

PSP アドミッション コントローラーを無効にし、PSA を設定すると、既存の PodSecurityPolicies、および関連するロール、ClusterRole、RoleBinding、および ClusterRoleBinding を安全に削除できます。

 kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true

このクリーンアップ手順により、クラスター内に PSP 構成が残らないことが保証されます。

PSP アドミッション コントローラーを非アクティブ化し、PSP 関連のリソースを削除することで、クラスターのセキュリティ アーキテクチャが簡素化され、Pod Security Admission への移行が完了します。

まとめ

この包括的なガイドでは、 Kubernetes クラスターのセキュリティ フレームワークをポッド セキュリティ ポリシー (PSP) からポッド セキュリティ アドミッション (PSA) にスムーズに移行するための重要な手順と考慮事項について説明しました。この移行により、Kubernetes の進化するセキュリティ標準に準拠しながら、ワークロードが安全に実行され続けることが保証されます。

ポッド セキュリティ アドミッション (PSA) を使用することの長所と短所

長所:

• ネイティブ Kubernetes コンポーネント: PSA は Kubernetes の不可欠な部分であり、サードパーティのツールをインストールする必要がありません。プラットフォームに組み込まれたセキュリティ機能を利用します。
• Kubernetes 標準の適用: PSA は Kubernetes のネイティブ セキュリティ標準に準拠し、プラットフォームのベスト プラクティスへの準拠を保証します。

短所:

• 限定的なカスタマイズ: PSA は、特にポッド仕様の変更を必要とする複雑なセキュリティ ポリシーの場合、PSP と同じレベルのカスタマイズを提供しない場合があります。
• レトロフィットが必要: 既存のワークロードを更新してセキュリティ コンテキスト設定を含める必要があり、YAML ファイルの変更が必要になる場合があります。

このガイドでは、PSP から PSA に自信を持って移行するために必要な知識と手順を説明し、Kubernetes ワークロードを保護しながら安全かつ効率的な移行を保証します。 Kyverno と OPA Gatekeeper への代替移行パスを検討する今後の記事にご期待ください。