系統設計面試：如何把 Kubernetes Pod 安全策略安全遷移到 enforce？
題干與適用場景
平台團隊要把多個命名空間遷移到 Kubernetes Pod Security Standards 的 restricted 級別。現有工作負載來源複雜，既有生產服務也有臨時建置任務。請設計發現、整改、例外、切換與回滾流程。
面試官考察點
- 是否理解
enforce、audit、warn的不同副作用。 - 是否能把命名空間、工作負載和例外納入治理邊界。
- 是否用觀測資料驅動整改，而不是直接全域拒絕。
- 是否考慮版本固定、稽核留痕和緊急回滾。
回答前需要釐清的問題
- 叢集和命名空間的 Kubernetes 版本、租戶邊界與發布工具是什麼？
- 目標是
baseline還是restricted，是否允許按命名空間分級？ - 哪些工作負載需要特權、hostPath 或主機網路？
- 回滾是暫時降低策略，還是保留舊叢集承接流量？
30 秒回答框架
先按命名空間啟用 audit 與 warn，收集違規物件並讓提交者看到修復提示；不要直接全域 enforce。按風險和業務重要性分批整改，使用固定策略版本，所有例外必須有負責人、原因、期限和替代方案。小範圍試運行通過後切到 enforce，持續觀察拒絕率與發布成功率；緊急回滾只降低受影響命名空間的策略並保留稽核記錄。
分步驟深入解答
1. 建立資產和策略基線
盤點命名空間、Pod 模板、控制器和發布來源，按生產、共享基礎設施、開發和臨時任務分組。為每組選擇目標級別與版本，記錄允許的例外，不把未標註命名空間當成「安全」。
2. 先觀察再阻斷
先設定 audit 記錄違規，再設定同級別 warn 給用戶端回饋。彙整稽核事件，按規則、團隊和映像歸因，形成可排序整改隊列。如此能在不阻斷現有流量的情況下暴露風險。
metadata:
labels:
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted3. 修復工作負載
優先移除不必要的特權、hostNetwork、hostPID、hostPath 和可寫 root filesystem；補齊非 root、seccomp 與 capability 限制。把策略檢查放進 CI，在提交階段失敗並給出具體欄位，而不是等叢集拒絕。
4. 治理例外
例外只按命名空間或明確受控入口發放，記錄業務影響、負責人、到期日和補償控制。Admission exemption 不是永久白名單；每次續期都要重新審查，禁止把所有系統命名空間無條件豁免。
5. 分批切換 enforce
先在低風險命名空間執行 enforce，觀察拒絕率、發布失敗、重啟和租戶投訴，再擴大範圍。策略版本固定，升級版本先在 warn/audit 中預演，避免 latest 的隱性行為變化。
6. 回滾與驗證
發布控制器要能暫停並恢復舊模板。若核心服務受阻，暫時把單個命名空間降回較寬級別，同時保留 audit 和事件。驗證應涵蓋新建 Pod、Deployment 模板、滾動升級、Job、例外到期和策略版本升級。
高品質示範回答
我會先盤點命名空間和工作負載，固定目標策略版本，再以 audit 加同級 warn 收集違規並推動修復。CI 階段提前檢查安全上下文，例外必須有負責人、原因和到期日。低風險命名空間先切 enforce，逐步擴大並監控拒絕率、發布成功率和業務錯誤。版本升級先用 warn/audit 預演。出現阻斷時只回滾受影響命名空間的策略，保留稽核記錄並修復根因，不做全域永久放寬。
常見錯誤
- 直接全域
enforce→ 大量發布同時失敗 → 先 audit/warn 再分批切換。 - 把未標註命名空間視為安全 → 策略覆蓋出現盲區 → 明確標註並納入盤點。
- 用永久豁免解決所有失敗 → 風險長期隱藏 → 例外必須限時和可稽核。
- 只在叢集中發現違規 → 修復回饋太晚 → 把檢查前移到 CI 和模板評審。
- 使用
latest卻不做預演 → 版本升級產生意外拒絕 → 固定版本並提前觀測。
追問及應對
warn 和 audit 都不阻斷，為什麼需要同時啟用？
warn 讓提交用戶端立即看到回饋，audit 把違規寫入稽核記錄。兩者分別服務開發修復和平台度量，不能互相取代。
例外應該按 Pod 還是按命名空間？
優先使用可治理的命名空間邊界，並限制受控入口；按單個 Pod 放行容易被複製和繞過。例外仍需負責人、期限和補償控制。
如何證明遷移沒有降低可用性？
用分批切換前後的拒絕率、發布成功率、重啟、SLO 和租戶錯誤對比，並對滾動升級和 Job 等非常駐工作負載做回放。