Kubernetes API 是整個 Kubernetes 集群的核心。它負責處理所有的操作請求，包括創建、更新、刪除和查詢 Kubernetes 資源。因此，保護 Kubernetes API 是保障整個集群安全的關鍵。這可以確保所有進出 Kubernetes 的操作都受到嚴密的監控和保護。這對於維護系統穩定性、避免潛在攻擊和未經授權的訪問非常重要。

Kubernetes API 存取控制的過程

不論是通過 kubectl 客戶端還是 REST 請求訪問 K8s 集群，最終都需要經過 API Server 來進行資源的操作，生效結果會被持久化至 etcd 中。etcd 是 Kubernetes 的關鍵資料存儲系統，它保存了集群中的所有狀態和配置。因此，etcd 中的資料安全就變得十分重要。為了保證 etcd 的安全性，K8s 只允許 API Server 去訪問操作 etcd，此時 API Server 就擔負起了整個 etcd 的安全。K8s 是如何管控和保障 API Server 訪問過程的安全呢？

controlling-access

如圖所示，整個過程可以分為四個階段：

請求方向 K8s API 發起請求，該請求依次經過 Authentication（身份驗證）、Authorization（授權）和 AdmissionControl（准入控制）三個階段的檢查。最終，請求會被轉化為對 K8s 對象的變更操作，並持久化至 etcd 中。這個流程確保了只有經過認證和授權的請求才能夠進行實際的資源操作，保護了整個集群的安全。

K8s 的使用者模型

從圖 controlling-access 中我們可以看出，K8s 的使用者主要分為兩類：

• 通過客戶端進行連接的人類操作者，例如使用 kubectl 來管理資源的開發人員或操作員。
• K8s 內部諸如處理程序、控制器等非人類操作的客戶端，例如部署在集群中的控制器負責自動調整資源或監控系統狀態的 Pod。

我們稱前者為 Normal Users（常見使用者），後者為 Service Account（服務帳戶）。因為 K8s 內沒有為 Normal Users 定義儲存對象，我們無法像操作 Pod 一樣在 K8s 內部管理這類使用者，它們通常是由外部服務進行管理，借由證書憑證或者靜態組態檔案進行認證。而 Service Account 可由 K8s API 直接進行管理，並且能夠與 Kubernetes 的內部資源緊密集成。

我們用表格來呈現兩者的差異:

與 AWS 的使用者模型比較

K8s 使用者模型的概念跟 AWS IAM 基本是一致的：

• Normal User 對應 IAM User
• Service Account 對應 IAM instance profile

將 AWS EC2 當作處理程序，當要啟動一個 EC2 Instance 時，我們可以指定 IAM instance profile 給 EC2 Instance，讓 EC2 通過驗證並獲得指定的授權。這樣的類比使得 Kubernetes 的使用者模型更加直觀理解，有助於理解如何有效地分配和管理權限，確保每個組件只能執行它們被授權的操作，避免潛在的安全風險。

默認 Service Account

事實上，所有 Pod 運行都會有 Service Account，沒有指派的配置會默認帶入運行 Namespace 的 default 服務帳號給這個 Pod。我們可以驗證一下：

• 創建 Pod

kubectl run nginx --image=nginx

• 查詢該 Pod，使用 kubectl describe pod nginx 命令，結果如下

Name:             nginx
Namespace:        default
Priority:         0
Service Account:  default
[...]

這表示即使我們不明確指派 Service Account，Pod 也會使用默認的 default 服務帳戶。這種默認行為雖然方便，但在某些情況下可能會引入安全風險，因此在生產環境中，我們應謹慎配置 Service Account，以確保只賦予必要的權限。

Authentication 認證

當請求發起方建立與 API Server 的 TLS 安全連接後，進入請求的認證階段（圖 controlling-access 中步驟 1）。

認證的方式主要有：

• client certificates (客戶端證書)
• password (v1.19 版已廢棄)
• plain tokens
• bootstrap token
• JSON Web Tokens (主要用於 Service Account)。

認證模組會檢查要求標頭或者客戶端證書的內容，我們可以同時使用一種或幾種方式對請求進行認證。多種認證方式會被依次執行，只要一種方式通過，請求便得到合法認證。

當所有方式都未通過時，會返回 HTTP 401 狀態碼並中斷請求。認證解決的問題是校驗訪問方是否合法並識別其身份。認證是 Kubernetes 安全模型中的第一道防線，它確保只有可信任的客戶端可以進一步與集群進行交互。

Authorization 授權

當上面的認證階段通過後，接下來就會走到授權階段 (圖 controlling-access 中步驟 2)。

這個階段就是對使用者的操作合法性進行校驗。如果現有策略聲明使用者具有完成請求操作的權限，則對請求進行授權。簡單來說，Authorization 是為了判別使用者的操作權限範圍。

Kubernetes 支援多種授權模組：

• Node：基於節點的存取控制，適用於節點級別的授權，通常用於確保節點只訪問與其相關的資源，適合小型集群或對節點權限進行精細控制的場景。
• ABAC（Attribute-Based Access Control）：基於屬性的存取控制，適用於需要高度靈活性的場景，可以根據請求者的屬性來設置授權策略，但由於策略管理較為複雜，不適合大型集群。
• RBAC（Role-Based Access Control）：基於角色的存取控制，適合大部分場景，特別是在多租戶環境下。通過定義角色和角色綁定，可以輕鬆管理權限，權限管理靈活且易於維護。
• Webhook：自訂鑑權方式，通過 webhook 呼叫外部服務進行決策，適用於需要自定義授權邏輯的場景，能根據特定業務需求進行更精細的授權控制，但需要額外的基礎設施支持。

在 K8s 中，經常使用 RBAC 實現授權。RBAC 通過定義角色和角色綁定來管理權限，這使得權限管理更為靈活和精細化。我們可以針對不同的 Namespace 和資源定義不同的角色，從而確保使用者只能執行其應有的操作。Webhook 則提供了一種自定義的擴展方式，允許企業根據自身需求創建更加複雜的授權規則。

Admission Control 准入控制

准入控制階段 (圖 controlling-access 中步驟 3) 可以理解成 middleware。

它在用戶的請求通過認證階段，到達 API Server 後，進入 etcd 之前，執行一系列的處理和校驗。就像中間件一樣，Admission Controllers 可以修改請求內容（Mutating）或者檢查請求是否合法（Validating），以確保集群的安全性和穩定性。

例如，我們可以使用 Mutating Admission Controllers 來自動添加一些必要的標籤，或者使用 Validating Admission Controllers 來阻止不符合要求的配置進行應用。這樣的控制使得 Kubernetes 的資源管理更加安全可靠，確保只有符合規範的配置和資源才能被部署。

小結

本章節中，我們了解到 Kubernetes API 是如何在叢集中運作的，也認識到中途會經歷的階段。通過身份認證、授權和准入控制三個主要階段，Kubernetes 提供了一套完善的安全控制流程，確保了每個操作請求的合法性和安全性。這些機制共同協作，為 Kubernetes 集群的安全提供了強有力的保障。理解這些安全機制對於管理和保護 Kubernetes 集群至關重要，能有效防止未經授權的訪問，並確保集群的穩定運行。

參考

• AWS IAM Role And Instance Profile Explained (devopscube.com)
• Kubernetes API 存取控制 | Kubernetes