PSP のポリシーからポリシー バンドルへの移行

※この投稿は米国時間 2023 年 4 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

多くの組織が Pod Security Policy（PSP）を利用して Kubernetes の Pod に制限を適用しています。Kubernetes v1.25 での PSP の廃止を受け、セキュリティ体制を維持するために PSP と同等のポリシーが必要であるというフィードバックがユーザーから寄せられています。Pod Security Standards に移行する場合も PSP のポリシーの継続性を維持する場合も、Policy Controller によってビジネス目標を達成できます。

Policy Controller には、PSP の移行以外にも複数の機能があります。たとえば、あらゆる環境にあるクラスタのフリート全体のポリシー違反と修正のための推奨事項を表示する一元的なダッシュボードや、複数の適用ポイント（CI / CD、アドミッション、監査）および複数の適用タイプ（dryrun、deny）で必要なガバナンスとコンプライアンスに対応するために Google が構築、管理しているポリシー コンテンツなどです。

Policy Controller 以外の PSP 移行手段

Policy Controller を使用した PSP の移行

既存の PSP は主に検証用のアドミッション コントローラであるとみなされることが多いのですが、PSP の構成によっては、ミューテーション アドミッション コントロールも含まれることがあります。今回の投稿では、まず Pod Security Policy（PSP）v2022 のポリシー バンドルを使用した PSP の検証機能の移行について解説し、続けて PSP ミューテーション移行の 2 つの主なオプションを取り上げます。

PSP の検証機能の移行

PSP バンドルは、Pod Security Policy の監査または適用を支援する制約のグループです。PSP バンドルをクラスタにインストールする場合は、Policy Controller v1.11.1 以上を使用します。含まれているポリシーは、デフォルトでは「監査」モードで構成されているので、既存または新しいワークロードに影響しません。これらのポリシーを適用するには、kubectl（後述）、kpt、または Config Sync を使用します。

1. 手順を開始する前に PSP バンドルの設定を完了し、カスタマイズした PSP バンドル用の新しいフォルダを作成します（例: org-restricted-psp）。

3. PSP バンドルの対応表を使用して、既存の PSP のフィールドに一致する関連制約を構成します。

たとえば、PSP「restricted」には「allowPrivilegeEscalation: false」が含まれています。この動作を構成するには、psp-allow-privilege-escalation-container.yaml の制約を org-restricted-psp フォルダにコピーします。

制約の中には、フィールド名の値に基づいたカスタマイズが必要なものもあります。たとえば、PSP「restricted」には「requiredDropCapabilities: [“ALL”]」が含まれています。この動作を構成するには、psp-capabilities.yaml の制約を org-restricted-psp フォルダにコピーし、allowedCapabilities パラメータを削除して、requiredDropCapabilities パラメータを [“ALL”] に設定します。

注: マッピングされた PSP フィールド名が既存の PSP に含まれていないフォルダには制約をコピーしないでください。

4. kubectl を使用して、カスタマイズしたポリシー制約を適用します。

5. ポリシーの制約がインストールされていることを確認し、クラスタ全体で違反の存在を確認します。

PSP のミューテーション

既存の Pod Security Policy には、検証機能に加えて、デフォルトを構成するためのミューテーション用アドミッション コントロールが含まれている場合があります。現在 PSP ミューテーションを利用していない場合は、ミューテーションの移行も構成も不要です。たとえば、PSP「privileged」の例にはミューテーションが含まれていません。PSP ミューテーションを利用する場合は、以前に PSP ミューテーションによって設定された値すべてを含めるように Pod と PodTemplate の構成を直接更新するとよいでしょう。移行前にすべての PSP ミューテーションを削除することをおすすめします。これは、ミューテーションによって、ポリシーの GitOps とシフトレフトの実装が難しくなるためです。ただし、ビジネス上の理由から必要な場合は、Policy Controller を使用してミューテーションを実装できます。

ミューテーションの移行

既存の PSP が変更を加えているかどうかを確認するには、Pod および PodTemplate のソース構成を PSP クラスタ上で実行されているリソースと比較し、ソース構成にすべての変更を追加します。

ミューテーションの構成

Policy Controller のリソース ミューテーション機能を使用して、ご自身の環境に同様のミューテーションを実装することもできます。Policy Controller のデフォルトではミューテーションは無効になっているため、使用する前に有効にする必要があります。Policy Controller のミューテーションは GKE Autopilot クラスタではサポートされていません。

変更のテスト

既存の PSP を無効にする前に、ミューテーションを含まない「privileged」PSP を適用してワークロードのサンプルをテストする必要があります。問題を発見した場合は、必要に応じて既存の Pod Security Policy とアドレスに簡単にロールバックできます。該当する場合は、PSP バンドルを deny 適用アクションに設定できます。構成を一定期間、十分にテストしたら、既存の PSP を無効にできます。

ダッシュボードでの Pod Security Policy 違反の確認

クラスタでの Pod Security Policy バンドル違反のモニタリング

PSP バンドルでは、デフォルトで適用アクションが dryrun に設定されています。この構成では、リソースをブロックまたは中止することなく Policy Controller によって違反が表示されます。これにより、クラスタの監査、ワークロード オーナーとの違反の共有、重要なセキュリティ問題の共同修正が可能になります。

Cloud Monitoring を使用して、ポリシー違反向けにログベースのアラートを設定することもできます。

Policy Controller には、制約の数、制約テンプレート、検出された監査違反などをはじめとする、ポリシーの使用に関連する指標が含まれています（公開された指標のリストを参照）。インストール時にこれらの指標を Cloud Monitoring と Prometheus、またはそのどちらかにエクスポートできます（ブログ投稿、ドキュメント）。また、指標に基づいてアラートを設定することもできます。

まとめ

Policy Controller により、Google によって作成、管理されるポリシー バンドルとカスタム ポリシーの両方をクラスタに適用できます。これにより、Kubernetes API に対する変更がセキュリティ、運用、コンプライアンスの管理に違反することを防止します。また、リソースのミューテーションを実装するとき、または Kubernetes クラスタへのデプロイ前にコンプライアンスを確認するために構成を分析するときに、必要に応じて Policy Controller を使用することもできます。

今すぐ使用を開始する

Policy Controller の使用を開始する際は、Policy Controller をインストールし、Google によって作成、管理されている他のポリシー バンドルを試す方法が最も簡単です。

• Anthos Service Mesh セキュリティ

• CIS Kubernetes Benchmark v1.5.1

• PCI-DSS v3.2.1

• Pod Security Standards Baseline

• Pod Security Standards Restricted

• Policy Essentials