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

若要查看叢集中 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"}'

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

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

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

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

有幾種開源 policy-as-code 解決方案可用於Kubernetes. 若要檢閱移轉PSPs至 policy-as-code 解決方案的最佳做法，請參閱上的網繭安全性頁面的 P olicy-as-code 部分 GitHub。

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

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

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

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

我們預期不會對 Windows 工作負載產生任何特定影響。 PodSecurityContext 有一個在適用於視windowsOptions窗的 PodSpec v1 API 中調用的字段Pods。這會使用 Kubernetes 1.25 中的 PSS。如需有關針對 Windows 工作負載強制執行 PSS 的詳細資訊和最佳實務，請參閱 EKS 最佳實務指南和 Kubernetes 文件。