題目與適用場景
本題面向平台安全工程師。Kubernetes v1.36 引入 alpha 的清單式准入控制。策略從 API Server 本地目錄載入，在處理請求前生效，因此方案必須在 etcd 不可用時工作，並提供檔案式恢復路徑。
面試官考察點
- 啟動策略與 API 管理策略的職責分離。
- 原子校驗、回滾和啟動失敗行為。
- 防止特權刪除策略與 webhook 設定。
- 多 API Server 的設定分發與漂移偵測。
- 維運逃生通道、稽核和故障測試。
要保護哪些資源？
確認只保護 ValidatingAdmissionPolicy，還是也保護 binding、webhook 與 mutating 設定。匹配規則和影響範圍會隨答案改變。
誰擁有恢復權限？
API 不可用或策略阻止自身修復時，權威路徑必須是 API Server 主機或不可變設定流水線。定義誰能改以及如何審核。
有多少 API Server？
每個實例讀取自己的檔案。叢集需要內容定址製品、滾動順序和設定雜湊指標；單實例也要原子替換。
30 秒回答框架
「我會先安裝一條經過審核的清單策略，再啟用 API 管理策略。它拒絕修改或刪除帶保護標籤的物件，名稱使用保留的 .static.k8s.io 後綴。每個 API Server 接收相同版本目錄並暴露設定雜湊。檔案變更先校驗再原子切換；執行時錯誤保留上一版，啟動時錯誤則快速失敗。維運通過主機設定路徑恢復，不能依賴被阻止的 API。」
分步驟深入解答
建立啟動信任邊界
在每個 API Server 啟用 ManifestBasedAdmissionControlConfig，透過既有准入設定檔設定 staticManifestsDir。清單來自唯讀且完成完整性校驗的製品。所有靜態物件名稱以 .static.k8s.io 結尾，讓指標和稽核記錄區分檔案物件與 API 物件。
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
staticManifestsDir: /etc/kubernetes/admission/static撰寫保護規則
啟動策略匹配准入策略、binding 和 webhook 設定的 UPDATE、DELETE。只有舊物件帶 platform.example.com/protected=true 時才拒絕。普通試驗仍可進行，基線受到保護。
讓更新具備事務性
API Server 校驗整個變更集合後原子切換。執行時校驗失敗則保留上一版並記錄錯誤。啟動時任何清單無效都應在接收請求前失敗；靜默啟動會重新製造要解決的啟動空窗。
運營多實例叢集
把相同內容定址 bundle 渲染到每個 API Server，一次只滾動一個實例。比較設定雜湊標籤和准入決策指標。雜湊不一致代表漂移，應停止發布並恢復已知 bundle。
保留逃生通道
靜態策略不能依賴 Service、paramKind 或其他 API 物件，因為叢集狀態可能尚未存在。保留帶稽核的主機級檔案替換路徑，並測試過寬或畸形策略能否在不呼叫 API 時回退。
高品質示範回答
「我會把靜態目錄作為根信任，向每個 API Server 分發簽名的版本化 bundle，用靜態策略拒絕修改帶標籤的准入資源。.static.k8s.io 名稱讓來源可見。執行時編輯先校驗再原子切換，啟動時無效 bundle 直接拒絕服務。每台伺服器匯出設定雜湊，漂移時停止灰度。恢復走經稽核的主機變更，不走 API，並覆蓋啟動、刪除嘗試、畸形更新、重啟和混合 bundle 測試。」
常見錯誤
- 用另一條 API 策略保護策略 → API 無法保護自身設定 → 把保護錨定在靜態檔案。
- 錯誤編輯直接替換活動集合 → 語法錯誤會移除全部保護 → 校驗全集合並保留上一版。
- 帶無效清單啟動 → 伺服器在缺少基線時執行 → 接收請求前快速失敗。
- 假設 API Server 共用檔案 → 實例可能執行不同策略 → 分發 bundle 並比較雜湊。
- 移除所有維運逃生通道 → 策略 bug 變成事故 → 保留特權且有稽核的主機恢復路徑。
評分標準與自檢
評分啟動安全、策略匹配、原子更新、叢集一致性、恢復和測試。強回答應說明靜態設定為何能在無循環准入的情況下保護 API 物件，以及為何必須保留非 API 恢復通道。
追問及應對
API Server 在發布中重啟怎麼辦？
保留舊 bundle，把靜態准入成功載入作為 readiness 條件，重新接流量前比較報告的雜湊。
靜態策略能引用 Service webhook 嗎？
不能。功能須在沒有叢集狀態時自包含；可用 URL-only webhook 或不依賴 API 資源的 CEL 策略，並說明可用性取捨。
如何測試阻止自身刪除的策略？
建立受保護測試物件，透過 API 嘗試更新和刪除，確認拒絕與稽核記錄，再從恢復路徑替換靜態 bundle，驗證物件可恢復管理。
發布不變量是什麼？
每台提供服務的 API Server 都執行相同的已批准 bundle 雜湊，而且即使 API 拒絕設定修改，仍有至少一條經過稽核的恢復路徑。