レガシーポッドセキュリティポリシー (PSP) からの移行

PodSecurityPolicy は Kubernetes1.21 で非推奨となり、Kubernetes1.25 で削除されました。クラスターで PodSecurityPolicy を使用している場合は、ワークロードの中断を避けるために、クラスターをバージョン 1.25 にアップグレードする前に、組み込みの Kubernetes ポッドセキュリティ標準 (PSS) または Policy as Code ソリューションに移行する必要があります。詳細については、よくある質問を選択してください。

PSP について

PodSecurityPolicy は、クラスター管理者が Pod 仕様のセキュリティセンシティブな側面を制御できるようにする組み込みのアドミッションコントローラーです。Pod がその PSP の要件を満たしている場合、その Pod は通常どおりクラスターに受け入れられます。Pod が PSP の要件を満たしていない場合、Pod は拒否され、実行できません。

PSP の削除は Amazon EKS に固有のものですか? それともアップストリーム Kubernetes で削除されていますか?

これは Kubernetes プロジェクトにおけるアップストリームの変更であり、Amazon EKS で行われた変更ではありません。PSP は、Kubernetes 1.21 で非推奨となり、Kubernetes 1.25 で削除されました。Kubernetes コミュニティは、PSP の深刻なユーザビリティの問題を特定しました。これらには、意図したよりも広範な許可の誤った付与や、特定の状況で PSPs が適用する検査における困難が含まれます。これらの問題は、重大な変更を加えることなく対処することができませんでした。これを主な理由として、Kubernetes コミュニティは PSP を削除することを決定しました。

Amazon EKS クラスターで PSPs を使用しているかどうかを確認するにはどうすればよいですか?

クラスターで PSPs を使用しているかどうかを確認するために、次のコマンドを実行できます。

kubectl get psp

クラスター内の PSPs が影響を与えている Pods を確認するには、次のコマンドを実行します。このコマンドは Pod 名、名前空間、PSPs を出力します。

kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'

Amazon EKS クラスターで PSPs を使用している場合、どうすればよいですか?

クラスターを 1.25 にアップグレードする前に、PSPs を次のいずれかに移行する必要があります。

• Kubernetes PSS.

• Kubernetes 環境からの Policy as Code ソリューション。

PSP が非推奨となったことや、最初から Pod セキュリティを制御することに対する継続的なニーズに対応して、Kubernetes コミュニティは (PSS) と Pod Security Admission (PSA) を使用して組み込みソリューションを作成しました。PSA ウェブフックは、PSS で定義されているコントロールを実装します。

組み込みの PSS に PSPs を移行するためのベストプラクティスは、「EKS ベストプラクティスガイド」で確認できます。また、「Amazon EKS でのポッドセキュリティ標準の実装」のブログを確認することをお勧めします。追加のリファレンスには、「PodSecurityPolicy から組み込み PodSecurity アドミッションコントローラーへの移行」、および「PodSecurityPolicies からポッドセキュリティ標準へのマッピング」が含まれます。

Policy as Code ソリューションは、クラスターユーザーをガイドするガードレールを提供し、規定の自動化されたコントロールを通じて望ましくない動作を防止します。Policy as Code ソリューションは通常、Kubernetes ダイナミックアドミッションコントローラーを使用して、ウェブフック呼び出しで Kubernetes API サーバーリクエストのフローをインターセプトします。Policy as Code ソリューションは、コードとして記述および保存されたポリシーに基づいて、リクエストペイロードを変更および検証します。

Kubernetes で利用できるオープンソースの Policy as Code ソリューションがいくつかあります。PSPs を Policy as Code ソリューションに移行するためのベストプラクティスを確認するには、GitHub のポッドセキュリティのページの「Policy as Code」セクションを参照してください。

クラスターで PSP が eks.privileged を呼び出しました。これは何ですか? そして、これについてどのように対応すればよいですか?

Kubernetes バージョン 1.13 以降の Amazon EKS クラスターには、eks.privileged という名前のデフォルトの PSP があります。このポリシーは、1.24 および以前のクラスターで作成されます。1.25 以降のクラスターでは使用されません。Amazon EKS は、この PSP を PSS ベースの適用に自動的に移行します。お客様側でのご対応は不要です。

クラスターをバージョン 1.25 に更新すると、Amazon EKS は既存のクラスターに存在する PSPs に対して変更を加えますか?

いいえ。Amazon EKS によって作成された PSP である eks.privileged に加えて、1.25 にアップグレードしても、クラスター内の他の PSPs は変更されません。

PSP から移行していない場合、クラスターのバージョン 1.25 への更新は Amazon EKS によって妨げられますか?

いいえ。まだ PSP から移行していない場合でも、クラスターのバージョン 1.25 への更新が Amazon EKS によって妨げられることはありません。

クラスターをバージョン 1.25 に更新する前に、PSPs を PSS/PSA または Policy as Code ソリューションに移行するのを忘れた場合はどうなりますか? クラスターを更新した後に移行できますか?

PSP を含むクラスターが Kubernetes バージョン 1.25 にアップグレードされると、API サーバーは 1.25 の PSP リソースを認識しません。これにより、Pods が誤ったセキュリティスコープを取得する可能性があります。影響の詳細なリストについては、「PodSecurityPolicy から組み込みの PodSecurity アドミッションコントローラーに移行する」を参照してください。

この変更は、Windows ワークロードのポッドセキュリティにどのように影響しますか?

Windows ワークロードに対する特定の影響はないと想定されています。PodSecurityContext は、Windows Pods の PodSpec v1 API で windowsOptions というフィールドを持っています。これは Kubernetes 1.25 で PSS を使用します。Windows ワークロードの PSS の適用に関する詳細とベストプラクティスについては、「EKS ベストプラクティスガイド」と Kubernetes ドキュメントを参照してください。