PodSecurityPolicy 棄用：回顧、現況與未來

PodSecurityPolicy (PSP) 將在 Kubernetes 1.21 中被棄用，並於本週稍後發布。這啟動了倒數計時，直到它被移除，但不會改變任何其他事情。PodSecurityPolicy 在完全移除之前，在接下來的幾個版本中將繼續完全正常運作。同時，我們正在開發 PSP 的替代方案，以更輕鬆且永續的方式涵蓋關鍵使用案例。

什麼是 Pod 安全策略？我們為什麼需要它們？它們為什麼要被淘汰，以及接下來會發生什麼？這對您有什麼影響？當我們準備告別 PSP 時，這些關鍵問題浮現在腦海中，因此讓我們一起瀏覽這些問題。我們將從概述 Kubernetes 中功能如何被移除開始。

在 Kubernetes 中，棄用是什麼意思？

每當 Kubernetes 功能設定為淘汰時，我們的棄用政策是我們的指南。首先，該功能會被標記為已棄用，然後在經過足夠的時間後，最終可以將其移除。

Kubernetes 1.21 開始了 PodSecurityPolicy 的棄用程序。與所有功能棄用一樣，PodSecurityPolicy 在接下來的幾個版本中將繼續完全正常運作。目前的計劃是在 Kubernetes 1.25 版本中移除 PSP。

在那之前，PSP 仍然是 PSP。至少有一年的時間，最新的 Kubernetes 版本仍將支援 PSP，並且將近兩年的時間，PSP 將完全從所有受支援的 Kubernetes 版本中淘汰。

什麼是 PodSecurityPolicy？

PodSecurityPolicy 是一個內建的准入控制器，允許叢集管理員控制 Pod 規範中對安全性敏感的方面。

首先，在叢集中建立一個或多個 PodSecurityPolicy 資源，以定義 Pod 必須滿足的要求。然後，建立 RBAC 規則以控制哪個 PodSecurityPolicy 適用於給定的 Pod。如果 Pod 符合其 PSP 的要求，它將像往常一樣被准入到叢集。在某些情況下，PSP 也可以修改 Pod 欄位，有效地為這些欄位建立新的預設值。如果 Pod 不符合 PSP 要求，它將被拒絕，並且無法執行。

關於 PodSecurityPolicy，還有一件重要的事情要知道：它與 PodSecurityContext 不同。

Pod 規範的一部分 PodSecurityContext（及其每個容器的對應物 SecurityContext）是指定 Pod 多個安全性相關設定的欄位集合。安全性內容指示 kubelet 和容器運行時如何實際執行 Pod。相比之下，PodSecurityPolicy 僅約束（或預設）可以在安全性內容上設定的值。

PSP 的棄用不會以任何方式影響 PodSecurityContext。

我們為什麼需要 PodSecurityPolicy？

在 Kubernetes 中，我們定義了諸如 Deployments、StatefulSets 和 Services 等資源，這些資源代表軟體應用程式的建構區塊。Kubernetes 叢集內部的各種控制器會對這些資源做出反應，建立更多 Kubernetes 資源或配置某些軟體或硬體以實現我們的目標。

在大多數 Kubernetes 叢集中，RBAC（基於角色的存取控制）規則控制對這些資源的存取。list、get、create、edit 和 delete 是 RBAC 關心的 API 操作類型，但RBAC 不考慮正在將哪些設定放入其控制的資源中。例如，Pod 幾乎可以是任何東西，從簡單的網路伺服器到提供對底層伺服器節點和所有資料的完整存取權限的特權命令提示字元。對於 RBAC 來說，這一切都是一樣的：Pod 就是 Pod。

若要控制叢集中定義的資源中允許哪些類型的設定，除了 RBAC 之外，您還需要准入控制。自 Kubernetes 1.3 以來，PodSecurityPolicy 一直是用於對安全性相關的 Pod 欄位執行此操作的內建方式。使用 PodSecurityPolicy，您可以防止「建立 Pod」自動意味著「每個叢集節點上的 root 權限」，而無需部署額外的外部准入控制器。

PodSecurityPolicy 為什麼要被淘汰？

自 PodSecurityPolicy 首次推出以來的幾年中，我們意識到 PSP 存在一些嚴重的使用性問題，這些問題在不進行重大變更的情況下無法解決。

PSP 應用於 Pod 的方式已被證明對幾乎所有嘗試使用它們的人來說都很困惑。很容易意外地授予比預期更廣泛的權限，並且難以檢查在給定情況下適用哪些 PSP。 「變更 Pod 預設值」功能可能很方便，但僅支援某些 Pod 設定，並且不清楚它們何時會或不會應用於您的 Pod。在沒有「試執行」或稽核模式的情況下，將 PSP 安全地改裝到現有叢集是不切實際的，並且 PSP 永遠不可能預設啟用。

有關這些和其他 PSP 困難的更多資訊，請查看 SIG Auth 的 KubeCon NA 2019 維護者軌道會議影片

如今，您不僅限於部署 PSP 或編寫自己的自訂准入控制器。有幾個外部准入控制器可用，它們結合了從 PSP 中吸取的教訓，以提供更好的使用者體驗。K-Rail、Kyverno 和 OPA/Gatekeeper 都是知名的，並且各有其擁護者。

儘管現在有其他不錯的選擇，但我們相信，作為使用者的選擇，擁有一個內建的准入控制器仍然有價值。考慮到這一點，我們轉向以從 PSP 中吸取的教訓為靈感，建構接下來的內容。

接下來是什麼？

Kubernetes SIG Security、SIG Auth 和其他社群成員的多樣化集合已經合作了數月，以確保接下來推出的功能將會很棒。我們開發了一個 Kubernetes 增強提案 (KEP 2579) 和一個新功能的原型，目前暫時稱為「PSP 替代策略」。我們的目標是在 Kubernetes 1.22 中發布 Alpha 版本。

PSP 替代策略從意識到既然已經有一個穩健的外部准入控制器生態系統可用，PSP 的替代方案就不需要滿足所有人的所有需求開始。與外部 Webhook 相比，內建准入控制器的主要優勢在於部署和採用的簡便性，因此我們專注於如何最好地利用該優勢。

PSP 替代策略旨在盡可能簡單實用，同時提供足夠的彈性，以便在生產環境中大規模真正有用。它具有軟性部署功能，可實現將其改裝到現有叢集，並且具有足夠的可配置性，使其最終可以預設為啟用。它可以部分或完全停用，以便與外部准入控制器共存以用於進階使用案例。

這對您意味著什麼？

這一切對您意味著什麼取決於您目前的 PSP 情況。如果您已經在使用 PSP，則有充足的時間來規劃您的下一步行動。請查看 PSP 替代策略 KEP，並思考它在多大程度上適合您的使用案例。

如果您正在廣泛使用 PSP 的彈性，並使用眾多 PSP 和複雜的繫結規則，您可能會發現 PSP 替代策略的簡潔性過於侷限。利用接下來的一年來評估生態系統中的其他准入控制器選項。有資源可用於簡化此轉換，例如 Gatekeeper 策略庫。

如果您的 PSP 使用相對簡單，每個命名空間中只有少數策略和與服務帳戶的直接繫結，您可能會發現 PSP 替代策略非常適合您的需求。將您的 PSP 與 Kubernetes Pod 安全標準 進行比較，以了解您將能夠在何處使用「受限」、「基準」和「特權」策略。請關注或貢獻 KEP 和後續開發，並在 PSP 替代策略的 Alpha 版本可用時試用。

如果您才剛開始您的 PSP 之旅，您將透過保持簡單來節省時間和精力。您今天可以使用 Pod 安全標準的 PSP 來近似 PSP 替代策略的功能。如果您透過將「基準」或「受限」策略繫結到 system:serviceaccounts 群組來設定叢集預設值，然後在某些命名空間中根據需要提供更寬鬆的策略 使用 ServiceAccount 繫結，您將避免許多 PSP 陷阱，並輕鬆遷移到 PSP 替代策略。如果您的需求比這複雜得多，那麼您可能最好花費精力採用上述功能更完善的外部准入控制器之一。

我們致力於使 Kubernetes 成為我們所能做到的最佳容器協調工具，有時這意味著我們需要移除長期存在的功能，為即將到來的更好的事物騰出空間。當這種情況發生時，Kubernetes 棄用政策可確保您有充足的時間來規劃您的下一步行動。在 PodSecurityPolicy 的情況下，有多種選項可滿足各種需求和使用案例。立即開始提前規劃 PSP 的最終移除，並請考慮為其替代方案做出貢獻！祝您安全無虞！

致謝： 創造出色的軟體需要一個出色的團隊。感謝所有為 PSP 替代方案做出貢獻的人，特別是（按字母順序排列）Tim Allclair、Ian Coldwater 和 Jordan Liggitt。很高興與你們一起完成這項工作。

• ←上一篇
下一篇→