PodSecurityPolicy：歷史背景
PodSecurityPolicy (PSP) 准入控制器已在 Kubernetes v1.25 中移除。其棄用已在 Kubernetes v1.21 版本發布的部落格文章 PodSecurityPolicy 棄用：過去、現在和未來 中宣布和詳述。
本文旨在提供關於 PSP 的誕生和演變的歷史背景，解釋為什麼該功能從未達到穩定狀態，並說明為什麼它被移除並由 Pod 安全性許可控制取代。
PodSecurityPolicy 與其他專門的准入控制外掛程式一樣，在關於 Pod 安全性設定的特定欄位上提供了細緻的權限，作為內建的策略 API。它承認叢集管理員和叢集使用者通常不是同一個人，並且以 Pod 或任何將建立 Pod 的資源的形式建立工作負載不應等同於「叢集上的 root」。它還可以透過突變和將低階 Linux 安全性決策與部署過程分離，來鼓勵最佳實務，從而配置更安全的預設值。
PodSecurityPolicy 的誕生
PodSecurityPolicy 源自 OpenShift 的 SecurityContextConstraints (SCC)，後者甚至在 Kubernetes 1.0 之前就已在 Red Hat OpenShift Container Platform 的第一個版本中推出。PSP 是 SCC 的精簡版本。
PodSecurityPolicy 的創建起源很難追蹤，主要是因為它主要是在 Kubernetes 增強提案 (KEP) 流程之前添加的，當時設計提案仍然是一回事。實際上，最終 設計提案 的存檔仍然可用。儘管如此，在第一個提取請求合併後，還是創建了一個 KEP 議題編號五。
在添加創建 PSP 的第一段程式碼之前，兩個主要的提取請求已合併到 Kubernetes 中，一個是定義 Pod 容器上新欄位的 SecurityContext 子資源，另一個是 ServiceAccount API 的第一個迭代。
Kubernetes 1.0 於 2015 年 7 月 10 日發布，除了 Alpha 品質的 SecurityContextDeny 准入外掛程式（當時稱為 scdeny）之外，沒有任何機制來限制工作負載的安全上下文和敏感選項。SecurityContextDeny 外掛程式 今天仍然存在於 Kubernetes 中（作為 Alpha 功能），並創建了一個准入控制器，以防止使用安全上下文中的某些欄位。
PodSecurityPolicy 的根源是透過 關於安全策略的第一個提取請求 添加的，該請求添加了包含新 PSP 物件的設計提案，該物件基於 SCC（安全上下文約束）。經過九個月的漫長討論，來回於 OpenShift 的 SCC，多次重新定基，以及最終在 2016 年 2 月使其成為上游 Kubernetes 的 PodSecurityPolicy 更名。既然 PSP 物件已經創建，下一步是添加一個可以強制執行這些策略的准入控制器。第一步是添加准入 而無需考慮使用者或群組。添加了一個特定的 將 PodSecurityPolicy 提升到可用狀態的議題，以追蹤進度，並且在 2016 年 5 月的 名為 PSP 准入的提取請求 中合併了准入控制器的第一個版本。然後大約兩個月後，Kubernetes 1.3 發布了。
以下時間軸回顧了 PodSecurityPolicy 誕生及其准入控制器的主要提取請求，並以 1.0 和 1.3 版本作為參考點。
在那之後，透過添加最初被擱置的功能，增強了 PSP 准入控制器。 授權機制 於 2016 年 11 月初合併，允許管理員在叢集中使用多個策略，以便為不同類型的使用者授予不同層級的存取權限。稍後，於 2017 年 10 月合併的 提取請求 修復了 關於在突變和字母順序之間排序 PodSecurityPolicy 的設計問題，並繼續建構我們所知的 PSP 准入。在那之後，許多改進和修復接踵而至，以建構最新 Kubernetes 版本的 PodSecurityPolicy 功能。
Pod 安全性許可的興起
儘管 PodSecurityPolicy 試圖解決關鍵問題，但它仍然存在一些重大缺陷
- 有缺陷的授權模型 - 如果使用者對允許該 Pod 的 PSP 具有 use 動詞，或者 Pod 的服務帳戶對允許的 PSP 具有 use 權限，則使用者可以建立 Pod。
- 難以推廣 - PSP 預設為失敗關閉。也就是說，在沒有策略的情況下，所有 Pod 都會被拒絕。這主要表示預設情況下無法啟用它，並且使用者必須在啟用該功能之前為所有工作負載添加 PSP，因此不提供稽核模式來發現哪些 Pod 不會被新策略允許。選擇加入模型還導致測試覆蓋率不足，以及由於跨功能不相容而導致的頻繁崩潰。而且與 RBAC 不同，沒有強大的文化來隨專案一起發布 PSP 清單。
- 不一致的無界限 API - API 已經發展，存在許多不一致之處，特別是因為許多針對利基用例的請求：例如標籤、排程、細緻的卷控制等。它的可組合性差，優先順序模型薄弱，導致意外的突變優先順序。這使得將 PSP 與其他協力廠商准入控制器結合起來非常困難。
- 需要安全知識 - 有效使用仍然需要了解 Linux 安全性原語。例如 MustRunAsNonRoot + AllowPrivilegeEscalation。
PodSecurityPolicy 的經驗總結出，大多數使用者關心兩個或三個策略，這促成了 Pod 安全性標準 的創建，該標準定義了三個策略
- 特權 - 無限制策略。
- 基準 - 最小限制性策略，允許預設 Pod 配置。
- 受限 - 安全最佳實務策略。
PSP 的替代品，新的 Pod 安全性許可 是一個樹內、Kubernetes v1.25 的穩定版准入外掛程式，用於在命名空間層級強制執行這些標準。它使得在沒有深入安全知識的情況下更容易強制執行基本的 Pod 安全性。對於更複雜的用例，您可能需要一個可以輕鬆與 Pod 安全性許可結合的協力廠商解決方案。
下一步是什麼
有關 SIG Auth 流程的更多詳細資訊，包括 PodSecurityPolicy 移除和 Pod 安全性許可的創建，請參閱 KubeCon NA 2019 上的 SIG 身份驗證更新 和 PodSecurityPolicy 替代：過去、現在和未來 在 KubeCon NA 2021 的演示記錄。
特別是關於 PSP 移除，PodSecurityPolicy 棄用：過去、現在和未來 部落格文章仍然準確。
對於新的 Pod 安全性許可，文件已可用。此外，部落格文章 Kubernetes 1.23：Pod 安全性升級到 Beta 版 以及 KubeCon EU 2022 演示文稿 Pod 安全性搭便車指南 提供了很好的實務教學課程來學習。