PodSecurityPolicy 棄用：過去、現在和未來

PodSecurityPolicy (PSP) 在本週晚些時候釋出的 Kubernetes 1.21 中被棄用。這開啟了其移除的倒計時，但不會改變其他任何事情。PodSecurityPolicy 將在完全移除之前繼續在幾個版本中完全正常執行。與此同時，我們正在開發 PSP 的替代品，以更簡單和可持續的方式涵蓋關鍵用例。

什麼是 Pod 安全策略？我們為什麼需要它們？它們為什麼會被移除，接下來是什麼？這會如何影響您？當我們準備告別 PSP 時，這些關鍵問題會浮現在腦海中，所以讓我們一起來探討一下。我們首先概述一下 Kubernetes 功能是如何被移除的。

在 Kubernetes 中，棄用意味著什麼？

每當 Kubernetes 功能將要被移除時，我們的棄用策略就是我們的指南。首先，該功能被標記為已棄用，然後經過足夠的時間後，它最終可以被移除。

Kubernetes 1.21 啟動了 PodSecurityPolicy 的棄用過程。與所有功能棄用一樣，PodSecurityPolicy 將在幾個版本中繼續完全正常執行。目前的計劃是在 1.25 版本中從 Kubernetes 中移除 PSP。

在此之前，PSP 仍然是 PSP。將有至少一年的時間，最新的 Kubernetes 版本仍將支援 PSP，並且在將近兩年的時間裡，PSP 將完全退出所有受支援的 Kubernetes 版本。

什麼是 PodSecurityPolicy？

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

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

關於 PodSecurityPolicy 還有一件重要的事情需要了解：它與 PodSecurityContext 不同。

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

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

我們為什麼需要 PodSecurityPolicy？

在 Kubernetes 中，我們定義了 Deployment、StatefulSet 和 Service 等資源，它們代表了軟體應用程式的構建塊。Kubernetes 叢集中的各種控制器對這些資源做出反應，建立更多的 Kubernetes 資源或配置一些軟體或硬體以實現我們的目標。

在大多數 Kubernetes 叢集中，RBAC（基於角色的訪問控制）規則控制對這些資源的訪問。list、get、create、edit 和 delete 是 RBAC 關注的 API 操作型別，但 RBAC 不考慮其控制的資源中設定了哪些設定。例如，一個 Pod 可以是幾乎任何東西，從一個簡單的 Web 伺服器到一個特權命令列，提供對底層伺服器節點和所有資料的完全訪問。對 RBAC 來說，它們都一樣：一個 Pod 就是一個 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 的使用相對簡單，只有少量策略並且每個名稱空間都直接繫結到 ServiceAccount，那麼您可能會發現 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。與大家一起完成這項工作是我的榮幸。

• ←上一篇
• 下一篇→