從舊版 Pod 安全政策遷移 (PSP)

PodSecurityPolicy 是內建的許可控制器，可讓叢集管理員控制 的安全敏感方面 Pod 規格。如果 Pod 符合其 的要求 PSP、Pod 會照常進入叢集。如果 Pod 不符合 PSP 要求、Pod 已被拒絕且無法執行。

這是 中的上游變更 Kubernetes 專案，而不是在 Amazon EKS 中所做的變更。PSP 已在 中取代 Kubernetes 1.21 並在 中移除 Kubernetes 1.25。 的 Kubernetes 社群發現嚴重的可用性問題 PSP。 這些包括意外授予比預期更廣泛的許可，以及難以檢查哪些 PSPs 在指定情況下套用。如果不執行重大變更，就無法解決這些問題。這是為什麼 Kubernetes 社群決定移除 PSP。

檢查您是否正在使用 PSPs 您可以在叢集中執行下列命令：

kubectl get psp

若要查看 Pods 該 PSPs 在叢集中影響，請執行下列命令。此命令會輸出 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"}'

將叢集升級至 之前1.25，您必須遷移您的 PSPs 到下列其中一個替代方案：

為了回應 PSP 棄用和持續控制的需求 Pod 安全，從頭開始 Kubernetes 社群建立了具有 (PSS) 和 Pod Security Admission (PSA) 的內建解決方案。PSA Webhook 會實作 中定義的控制項 PSS.

您可以檢閱遷移的最佳實務 PSPs 至內建 PSS EKS 最佳實務指南。我們也建議您檢閱在 Amazon EKS 中實作 Pod 安全標準的部落格。其他參考包括從 PodSecurityPolicy 遷移至內建 PodSecurity 許可控制器，以及從 Mapping PodSecurityPolicies 遷移至 Pod 安全標準。

Policy-as-code 解決方案提供防護機制來引導叢集使用者，並透過指定的自動化控制項防止不必要的行為。 Policy-as-code 解決方案通常使用 Kubernetes 動態許可控制器來攔截 Kubernetes 使用 Webhook 呼叫的 API 伺服器請求流程。 Policy-as-code 解決方案會根據撰寫並儲存為程式碼的政策來變更和驗證請求承載。

有數個開放原始碼 policy-as-code 解決方案可供 使用 Kubernetes。 檢閱遷移的最佳實務 PSPs 至 a policy-as-code 解決方案，請參閱 Pod Security 頁面 onolicy-as-code 的 PWord GitHub區段。

具有 的 Amazon EKS 叢集 Kubernetes 版本 1.13或更高版本具有預設 PSP 名稱為 eks.privileged。此政策在 1.24 和更早版本的叢集中建立。它不會用於 1.25和更新版本的叢集。Amazon EKS 會自動遷移此 PSP 至 PSS型強制執行。您不需要執行任何動作。

否。除了 之外eks.privileged，這是 PSP Amazon EKS 建立，不會對其他 進行任何變更 PSPs 當您升級至 時，叢集中的 1.25。

否。1.25如果您未遷移至 ，Amazon EKS 不會阻止叢集更新至 版本 PSP 尚未完成。

當包含 的叢集 PSP 已升級至 Kubernetes 版本 1.25，API 伺服器無法識別 PSP 中的資源1.25。這可能會導致 Pods 取得不正確的安全範圍。如需完整的影響清單，請參閱從 PodSecurityPolicy 遷移至內建 PodSecurity 許可控制器。

我們預期不會對 Windows 工作負載造成任何特定影響。 PodSecurityContext 在 API for Windows windowsOptions中有一個稱為 PodSpec v1 的欄位 Pods。 這會使用 PSS in Kubernetes 1.25。 如需強制執行的詳細資訊和最佳實務 PSS 對於 Windows 工作負載，請參閱 EKS 最佳實務指南和 Kubernetes 文件。