Kubernetes 如何用細粒度授權保護 Kubelet API？
題幹與適用場景
平台團隊需要允許 kube-apiserver 讀取節點指標，卻不能讓同一身分存取 Kubelet 的偵錯或執行介面。叢集從舊的粗粒度授權行為升級到 Kubernetes v1.36，要求不中斷監控、限制節點越權並保留稽核證據。請說明驗證鏈路、授權屬性、遷移步驟、失敗回滾與驗證指標。
面試官考察點
- 是否區分 Kubelet HTTPS 端點的驗證與授權，而不是只談 RBAC。
- 是否能用 verb、resource、subresource、node 和 namespace 等屬性表達最小權限。
- 是否理解 API Server 使用的 Kubelet 客戶端身分必須擁有明確的授權規則。
- 是否能設計相容遷移、拒絕預設放大、稽核與回滾。
回答前需要釐清的問題
- 哪些呼叫方需要 Kubelet API：僅 API Server、監控代理，還是維運人員也直連節點？
- 需要哪些能力：指標、日誌、執行中容器資訊，還是執行命令和連接埠轉送？
- Kubelet 使用客戶端憑證還是其他驗證方式，API Server 的授權回呼是否可用？
- 升級期間是否允許短暫唯讀降級，監控的不可用預算是多少？
30 秒回答框架
先把鏈路拆成三層：TLS 或其他驗證確認呼叫者身分，Kubelet 授權器把請求映射成屬性，隨後透過 API Server 的授權介面做決策。再用最小權限規則只放行需要的節點端點，尤其把偵錯、執行和代理類能力單獨隔離。遷移時先盤點呼叫矩陣、在稽核模式觀察拒絕、逐步收緊規則，驗證指標和回滾開關後再切換為強制拒絕。
分步驟深入解答
1. 驗證、授權與請求屬性
Kubelet 的 HTTPS 端點先驗證客戶端憑證或設定的驗證方式，得到使用者名稱和群組。授權階段把 HTTP 請求映射為 Kubernetes 授權屬性，例如 verb、resource、subresource、namespace、name 和 node。驗證成功不等於授權成功；每個端點都應經過授權檢查。API Server 存取 Kubelet 時使用 --kubelet-client-certificate 和對應私鑰代表受控身分，該身分必須在授權系統中擁有明確權限。
2. 用子資源表達最小權限
將指標讀取、日誌讀取、容器狀態和偵錯執行視為不同能力。優先授權唯讀的節點相關資源或子資源，並按節點範圍限制；不要為了讓監控工作而授予通配資源或 nodes/proxy 的寬權限。對執行命令、連接埠轉送、偵錯介面單獨建立高風險角色，預設不綁定給 API Server 的服務身分。
3. 遷移與相容策略
先從現有稽核和存取日誌建立呼叫矩陣：身分、路徑、動詞、目標節點、結果和呼叫方版本。啟用細粒度授權後，使用非強制觀察階段記錄將被拒絕的請求，補齊必要的最小規則，再逐批切換節點。Kubernetes v1.36 中 KubeletFineGrainedAuthz 已 GA 並預設啟用，升級前應確認發行版預設值、API Server 客戶端憑證和所有監控元件的請求路徑。
4. 觀測、回滾與安全邊界
為允許和拒絕分別記錄稽核事件、身分、節點、資源和原因，監控授權延遲、拒絕率、指標採集成功率及異常路徑存取。若升級導致監控中斷，先回滾客戶端權限或暫時恢復相容規則，同時保持高風險端點關閉；修復後再逐步收緊。網路層仍應限制 Kubelet 連接埠可達範圍，授權不能取代 TLS、網路隔離和節點身分保護。
高品質示範回答
我會先確認 Kubelet 端點的驗證方式，再把每個請求映射成標準授權屬性。API Server 使用受控客戶端憑證存取 Kubelet，授權系統按 verb、resource、subresource、node 和 namespace 做最小權限判斷。指標採集只獲得必要的唯讀能力，exec、連接埠轉送和偵錯介面使用獨立高風險角色，不把通配權限或 nodes/proxy 綁定給普通服務身分。
遷移分四步：盤點呼叫矩陣；在觀察階段記錄拒絕而不影響現有採集；按節點和元件批次補齊最小規則；最後切換到強制拒絕並設定回滾開關。v1.36 的 KubeletFineGrainedAuthz 已 GA 且預設啟用，但我會驗證發行版設定、API Server 客戶端憑證和監控元件版本。稽核中保留身分、節點、資源、結果與原因，網路策略繼續限制 Kubelet 連接埠，確保授權、傳輸和網路三層同時收斂。
常見錯誤
- 只設定 TLS 驗證，誤以為拿到客戶端憑證就能存取所有 Kubelet API。
- 用通配資源或寬泛的
nodes/proxy解決監控問題。 - 沒有列出呼叫矩陣就直接啟用強制拒絕，導致升級後採集靜默失敗。
- 把 API Server 身分和維運偵錯身分共用同一個高權限角色。
- 只依賴授權規則，忽略 Kubelet 連接埠網路暴露和稽核告警。
追問及應對
追問一：為什麼不能直接給監控身分 nodes/proxy？
nodes/proxy 代表透過 API Server 代理存取節點端點的能力，範圍可能涵蓋遠多於指標讀取的路徑。應先確認實際請求，再授予具體資源或子資源權限；如果實作限制必須使用代理權限，也要配合專用身分、節點範圍和稽核告警。
追問二：升級時如何證明沒有放大權限？
比較升級前後的呼叫矩陣和授權決策，重點檢查新增 verb、資源、子資源和節點範圍。對拒絕事件做差異分析，使用合成請求驗證指標可讀而執行介面不可讀，並將結果納入發布門禁。
追問三：Kubelet 授權服務不可用時怎麼辦？
採用明確的故障關閉策略，避免授權回呼失敗變成預設放行。根據業務預算保留短時唯讀快取或暫停採集，但不能為恢復監控而開放高風險端點；同時告警並在回呼恢復後重試驗證。