系統設計面試：如何設計 Kubernetes 稽核策略與可靠日誌管道？
題干與適用場景
一個多租戶叢集需要回答「誰在何時從哪裡修改了什麼」，同時控制 API Server 記憶體、日誌成本和 Secret 洩漏風險。請設計 audit policy、日誌或 webhook 後端、取樣與告警、故障處理和取證驗證。
面試官考察點
- 是否理解規則按順序匹配、
None、Metadata、Request、RequestResponse的差異。 - 是否能區分
RequestReceived、ResponseStarted、ResponseComplete等階段。 - 是否考慮長連線、敏感請求本體、後端阻塞和日誌完整性。
- 是否把稽核目標映射到告警、留存、存取控制和演練。
回答前需要釐清的問題
- 需要稽核的高風險資源、動詞、租戶和主體範圍是什麼？
- 哪些請求本體含 Secret、權杖或個人資料，合規留存多久？
- 選擇本地檔案、webhook 還是兩者，允許多大日誌延遲與遺失窗口？
- 取證要求不可否認、跨區域複製和誰能讀取原始日誌嗎？
30 秒回答框架
先列出高風險 API 和資料邊界，規則按最具體到兜底的順序匹配。大多數資源記錄 Metadata，關鍵變更按需記錄 Request，謹慎使用 RequestResponse，避免把 Secret 寫入日誌。只在確有需要時省略早期階段，按後端能力選擇檔案、webhook 或雙寫。日誌管道要有緩衝、限速、加密、完整性校驗、存取稽核和明確的遺失告警，並用演練驗證故障時的行為。
分步驟深入解答
1. 先定義取證問題
把「誰、何時、從哪裡、對什麼做了什麼」拆成欄位和查詢。高風險物件包括 Secret、RoleBinding、Webhook、節點和租戶配額；普通健康檢查不必記錄完整請求本體。稽核策略必須服務具體調查問題，而非追求所有欄位。
2. 設計有序規則
規則從最具體到兜底排列，第一條匹配決定稽核級別。高風險變更設定 Request 或必要的 RequestResponse，常規讀取用 Metadata，明確噪聲用 None，最後用低級別兜底，避免漏記未知資源。
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- RequestReceived
rules:
- level: Request
resources:
- group: ""
resources: ["secrets"]
- level: Metadata
omitStages: ["RequestReceived"]
resources:
- group: ""
resources: ["pods"]
- level: None
users: ["system:kube-probe"]3. 控制階段和敏感欄位
長連線會產生 ResponseStarted，完成時才有 ResponseComplete；裁剪階段可能降低重複量，但不能假設每種請求只有一個事件。對 Secret 和身分材料優先記錄元資料、雜湊或受控摘要，禁止把原始值送到普通日誌系統。
4. 選擇和保護後端
檔案後端要輪換、壓縮、加密並可靠轉發；webhook 後端要有 TLS、認證、佇列和背壓。日誌管道應按租戶和風險分區，寫入只追加儲存，附帶 audit ID、策略版本和接收時間。下游消費者不能反向阻塞 API Server。
5. 定義故障語意
明確後端不可達、磁碟滿、佇列溢出和網路分區時是丟棄、阻塞還是降級。高風險變更可選擇 fail-closed，但必須量化對控制面的影響；一般請求可有限緩衝並告警。每種策略都要記錄遺失計數和恢復後的補償掃描範圍。
6. 驗證與持續改進
用已知使用者、ServiceAccount、代理和長連線生成事件，檢查規則命中、階段、租戶和欄位脫敏。故意製造 webhook 延遲、磁碟滿和策略更新，驗證告警、恢復和取證查詢。定期比較事件量、遺失率、延遲、成本和真實調查覆蓋率。
高品質示範回答
我先把調查問題映射到欄位和高風險資源，再按最具體到兜底排列規則。常規請求記錄 Metadata，Secret 只留受控元資料，關鍵變更才提升到 Request；對長連線明確階段裁剪。後端採用加密檔案或 TLS webhook，帶緩衝、背壓、不可竄改儲存和存取稽核，且不讓下游阻塞 API Server。故障時定義有限緩衝、遺失計數和告警，必要時對高風險寫入 fail-closed。最後用合成事件、長連線和故障演練驗證規則、完整性與恢復。
常見錯誤
- 所有請求都用
RequestResponse→ 敏感資料洩漏和成本爆炸 → 按風險分級。 - 規則順序隨意 → 兜底規則提前吞掉高風險事件 → 由具體到通用排列。
- 只看日誌檔案存在 → 後端阻塞或遺失未被發現 → 監控佇列、延遲和遺失計數。
- 忽略階段語意 → 長連線調查缺少關鍵時間點 → 明確各階段和裁剪原因。
- 讓 webhook 下游同步阻塞 API Server → 控制面雪崩 → 緩衝、逾時和背壓隔離。
追問及應對
為什麼不把所有 Secret 請求記錄為 RequestResponse？
請求本體可能包含 Secret 明文。多數調查只需要主體、物件、動詞和結果；若必須深入，應使用脫敏、隔離權限和短期受控留存。
webhook 不可用時應該阻斷 API 請求嗎？
取決於風險和可用性目標。高風險寫入可在量化影響後選擇 fail-closed，普通請求則有限緩衝並告警；無論選擇哪種，都要記錄遺失和恢復範圍。
如何證明規則沒有漏記未知資源？
保留低級別兜底規則，並用資源發現清單、合成請求和策略版本對照檢查事件覆蓋；新 API 出現時觸發規則評審，而不是依賴人工發現。