PodSecurityPolicy：歷史背景
自 Kubernetes v1.25 起，PodSecurityPolicy (PSP) 准入控制器已被移除。其棄用訊息已在 Kubernetes v1.21 版本的博文 PodSecurityPolicy 棄用：過去、現在和未來 中宣佈和詳細說明。
本文旨在提供有關 PSP 誕生和演變的背景，解釋該功能為何從未進入穩定階段，並說明為何它被移除並由 Pod Security 准入控制所取代。
PodSecurityPolicy 與其他專門的准入控制外掛一樣，作為內建的策略 API，為有關 Pod 安全設定的特定欄位提供了細粒度的許可權。它承認叢集管理員和叢集使用者通常不是同一撥人，並且以 Pod 或任何將建立 Pod 的資源形式建立工作負載不應等同於“叢集上的 root”。它還可以透過突變配置更安全的預設值，並將底層 Linux 安全決策與部署過程解耦，從而鼓勵最佳實踐。
PodSecurityPolicy 的誕生
PodSecurityPolicy 源於 OpenShift 的 SecurityContextConstraints (SCC)，它存在於 Red Hat OpenShift 容器平臺的最初版本中，甚至早於 Kubernetes 1.0。PSP 是 SCC 的精簡版本。
PodSecurityPolicy 的建立起源很難追溯，特別是因為它主要是在 Kubernetes 增強提案 (KEP) 流程之前新增的，當時設計提案仍然存在。實際上，最終的 設計提案 存檔仍然可用。儘管如此，在第一個拉取請求合併後，建立了一個 KEP issue 編號為 5 的問題。
在新增建立 PSP 的第一段程式碼之前，Kubernetes 合併了兩個主要的拉取請求，一個是定義了 Pod 容器新欄位的 SecurityContext 子資源，以及 ServiceAccount API 的首次迭代。
Kubernetes 1.0 於 2015 年 7 月 10 日釋出，沒有任何機制來限制工作負載的安全上下文和敏感選項，除了一個 alpha 質量的 SecurityContextDeny 准入外掛（當時稱為 scdeny）。SecurityContextDeny 外掛 至今仍在 Kubernetes 中（作為 alpha 功能），它建立了一個准入控制器，防止在安全上下文中使用某些欄位。
PodSecurityPolicy 的根源是透過 關於安全策略的第一個拉取請求 新增的，該請求基於 SCC（安全上下文約束）添加了帶有新 PSP 物件的設計提案。這是一個長達九個月的討論，期間在 OpenShift 的 SCC 基礎上反覆修改，多次 rebase，並最終更名為 PodSecurityPolicy，於 2016 年 2 月進入上游 Kubernetes。既然 PSP 物件已經建立，下一步就是新增一個可以強制執行這些策略的准入控制器。第一步是新增 不考慮使用者或組 的准入機制。為了跟蹤進展，建立了一個特定的 使 PodSecurityPolicy 進入可用狀態的問題，並且准入控制器的第一個版本在 2016 年 5 月名為 PSP 准入 的拉取請求中合併。然後大約兩個月後，Kubernetes 1.3 釋出了。
以下是回顧 PodSecurityPolicy 及其准入控制器誕生過程中的主要拉取請求的時間線，以 1.0 和 1.3 版本為參考點。
之後，PSP 准入控制器透過新增最初被擱置的內容得到了增強。於 2016 年 11 月初合併的 授權機制 允許管理員在叢集中使用多個策略，為不同型別的使用者授予不同級別的訪問許可權。後來，於 2017 年 10 月合併的 一個拉取請求 修復了 一個關於 PodSecurityPolicies 在變更和字母順序之間排序的設計問題，並繼續構建我們所知的 PSP 准入。之後，許多改進和修復接踵而至，構建了近期 Kubernetes 版本中的 PodSecurityPolicy 功能。
Pod Security Admission 的興起
儘管它試圖解決一個關鍵問題，但 PodSecurityPolicy 存在一些主要缺陷：
- 有缺陷的授權模型 - 使用者可以在對允許該 Pod 的 PSP 擁有 use 動詞許可權，或者 Pod 的服務賬號對允許的 PSP 擁有 use 許可權時建立 Pod。
- 難以推出 - PSP 是“預設拒絕”的。也就是說，在沒有策略的情況下，所有 Pod 都會被拒絕。這基本上意味著它不能預設啟用，使用者必須在啟用該功能之前為所有工作負載新增 PSP，因此沒有審計模式來發現哪些 Pod 會被新策略所不允許。這種選擇加入的模型也導致了測試覆蓋率不足和由於跨功能不相容而頻繁出現故障。與 RBAC 不同，沒有形成在專案中附帶 PSP 清單的濃厚文化。
- 不一致且無邊界的 API - API 在發展過程中出現了許多不一致性，主要是因為許多針對小眾用例的請求：例如標籤、排程、細粒度的卷控制等。它的可組合性很差，優先順序模型很弱，導致意外的變更優先順序。這使得將 PSP 與其他第三方准入控制器結合起來非常困難。
- 需要安全知識 - 有效使用仍然需要了解 Linux 安全原語。例如 MustRunAsNonRoot + AllowPrivilegeEscalation。
PodSecurityPolicy 的經驗總結出，大多數使用者關心的是兩到三種策略，這導致了 Pod 安全標準 的建立，該標準定義了三種策略：
- Privileged - 不受限制的策略。
- Baseline - 限制最少的策略，允許預設的 Pod 配置。
- Restricted - 安全最佳實踐策略。
PSP 的替代品，新的 Pod Security Admission 是一個內建的、在 Kubernetes v1.25 中穩定的准入外掛，用於在名稱空間級別強制執行這些標準。它使得在沒有深厚安全知識的情況下更容易實施基本的 Pod 安全。對於更復雜的用例，您可能需要一個可以輕鬆與 Pod Security Admission 結合的第三方解決方案。
接下來
有關 SIG Auth 流程的更多細節，涵蓋 PodSecurityPolicy 移除和 Pod Security Admission 的建立，可以觀看 KubeCon NA 2019 上的 SIG auth 更新 和 KubeCon NA 2021 上的 PodSecurityPolicy 替代方案：過去、現在和未來 演講錄影。
特別是在 PSP 移除方面，PodSecurityPolicy 棄用：過去、現在和未來 這篇博文仍然是準確的。
對於新的 Pod Security Admission，已有相關文件。此外，博文 Kubernetes 1.23: Pod Security 升級至 Beta 以及 KubeCon EU 2022 的演講 Pod 安全漫遊指南 提供了很好的實踐教程供學習。