具代表性的面試主題

系統設計面試:如何用 Kubernetes PodCertificateRequest 管理工作負載憑證?

系統設計中等
Offer.cc 編輯團隊發佈 更新

題幹

多租戶叢集中的服務需要 mTLS 用戶端憑證,卻不能持有 Kubernetes API 憑據。你會如何設計 Pod 憑證申請、投影、輪換與故障處理?

題幹與適用場景

多租戶 Kubernetes 叢集中,服務需要向內部 API 發起 mTLS 請求。應用只能讀取檔案,不能直接存取 Kubernetes API,也不能把長期私鑰寫入映像檔。請設計 PodCertificateRequest 從申請到簽發、投影、輪換、撤銷與稽核的完整鏈路。

面試官考察點

  • 是否區分 PodCertificateRequest、傳統 CertificateSigningRequest 與簽發者職責。
  • 是否能說明 kubelet 投影卷如何隔離私鑰、憑證與信任根。
  • 是否處理 signer 授權、租戶邊界、輪換窗口、Pod 刪除與節點失陷。
  • 是否識別 Kubernetes v1.35 beta 預設關閉、v1.36 需明確開啟的版本事實。

回答前需要釐清的問題

  1. 憑證用於用戶端認證、伺服器認證,還是雙向 mTLS?
  2. 需要的 SAN、有效期、信任根與撤銷語義是什麼?
  3. 叢集版本、feature gate、執行時設定與 kubelet 是否支援 Pod 憑證投影?
  4. 應用能否在憑證即將過期時重新開啟檔案或監聽目錄變化?

30 秒回答框架

我會讓 kubelet 代表 Pod 申請憑證,簽發者只接受已授權的 signer 與受限身分欄位,再把私鑰、憑證與信任根以唯讀 projected volume 投遞給應用。應用不存取 API,只讀取約定目錄並在輪換時重新載入。申請、簽發、投影與刷新都記錄可稽核事件;失敗時保留仍有效的舊憑證或阻止新連線。由於 PodCertificateRequest 在 v1.35 為 beta 且預設關閉,v1.36 還需要 feature gate 與執行時設定,我會先做版本探測與灰度。

分步驟深入解答

1. 劃分身分與授權邊界

Pod 只宣告用途與目標 signer,不能自行選擇任意 CA。准入策略將命名空間、服務帳號、Pod 標籤與允許的 signer 綁定;簽發者驗證請求來源、SAN 範本與金鑰演算法,拒絕跨租戶主體。API 存取權留在 kubelet 與控制面元件,應用只取得檔案讀取權限。

2. 設計申請與投影鏈路

kubelet 為 Pod 建立憑證請求並取得簽發結果,私鑰在節點側產生,避免把私鑰交給映像檔或業務 API。憑證、私鑰與 trust bundle 分開掛載,目錄權限按容器使用者最小化;投影檔案採原子替換,應用不會讀到半寫入內容。簽發者名稱、有效期與 SAN 寫入可稽核事件。

3. 處理輪換、撤銷與故障

刷新門檻應早於有效期結束,並涵蓋 kubelet 重啟、網路中斷與 CA 暫時不可用。應用同時保留舊憑證直到新憑證通過鏈驗證,載入失敗時拒絕新連線並保留健康檢查訊號。Pod 刪除、服務帳號變更或節點回收後立即移除投影;撤銷依賴 CA 的 CRL、OCSP 或短有效期策略,不能假設 Kubernetes 對所有 signer 提供統一撤銷介面。

4. 規劃版本與觀測

部署前驗證 v1.35 beta 的預設關閉狀態、v1.36 的 feature gate 與 runtime-config,並確認 signer 實作與 kubelet 版本矩陣。監控申請延遲、簽發失敗、剩餘有效期、輪換成功率、檔案權限錯誤與異常 SAN;日誌只記錄請求 UID、命名空間、Pod、signer 與結果,不記錄私鑰或完整憑證內容。灰度期間保留短期的舊憑證投影方案與回滾開關。

高品質示範回答

我會把 Pod 憑證當作由 kubelet 代理的短期身分憑據。准入層先把命名空間與服務帳號綁定到允許的 signer,簽發者再驗證 SAN、演算法、有效期與租戶邊界;私鑰在節點側產生,憑證、私鑰與信任根以唯讀 projected volume 分離投遞。應用不讀 API,只監聽目錄或按請求重新開啟檔案,在新鏈驗證成功後原子切換。輪換提前觸發,短暫故障保留仍有效的舊憑證,過期或身分變更則拒絕新連線並發出告警。刪除 Pod 時清理投影,撤銷依賴 signer 的短有效期或 CRL/OCSP 契約。上線前確認 v1.35 beta 預設關閉、v1.36 的 feature gate 與執行時設定,按節點池灰度並記錄請求 UID、signer、延遲、失敗率與剩餘有效期。

常見錯誤

  • 讓應用持有可建立任意 CSR 的 Kubernetes API token。
  • 允許請求者自由填寫 signer、SAN 或跨命名空間主體。
  • 把私鑰放進映像檔、ConfigMap 或長期 Secret,並忽略節點側權限。
  • 只在啟動時讀取憑證,輪換後繼續使用已過期檔案描述元。
  • 將 beta 能力當作所有叢集版本預設啟用的穩定 API。
  • 記錄完整 PEM、私鑰或可關聯租戶的敏感稽核欄位。

追問及應對

為什麼不直接使用長期 Secret?

長期 Secret 擴大洩露窗口,也難與 Pod 身分和刪除事件綁定。短期憑證配合 kubelet 投影與輪換能縮短憑據壽命,但仍需明確 signer 的撤銷與恢復契約。

節點被攻陷時如何降低影響?

限制節點可讀取的 Pod 目錄和容器使用者權限,憑證使用短有效期與最小 SAN;將高價值身分放到隔離節點或硬體保護的 signer,並透過稽核與異常連線偵測縮短回應時間。

feature gate 未開啟怎麼辦?

部署控制器先探測 API 資源、執行時設定與 kubelet 能力,未滿足時暫停該工作負載或切換到已稽核的舊方案;禁止靜默產生看似成功卻不會輪換的檔案。

公開來源

同類題目

相關面試工具

用 Solve 整理系統設計回答

從澄清需求開始,展開規模、架構、元件選擇和取捨。

查看工具