控制對 Kubernetes API 的訪問
本頁面概述瞭如何控制對 Kubernetes API 的訪問。
使用者使用 kubectl、客戶端庫或透過傳送 REST 請求來訪問 Kubernetes API。人類使用者和 Kubernetes 服務賬號都可以被授權訪問 API。當請求到達 API 時，它會經歷幾個階段，如下圖所示。
傳輸安全
預設情況下，Kubernetes API 伺服器在第一個非本地主機網路介面上的 6443 埠監聽，受 TLS 保護。在典型的生產 Kubernetes 叢集中，API 在 443 埠提供服務。埠可以透過 --secure-port 標誌修改，監聽 IP 地址可以透過 --bind-address 標誌修改。
API 伺服器會提供一個證書。此證書可以使用私有證書頒發機構 (CA) 進行簽名，也可以基於連結到公認 CA 的公鑰基礎設施。證書和相應的私鑰可以透過使用 --tls-cert-file 和 --tls-private-key-file 標誌進行設定。
如果你的叢集使用私有證書頒發機構，你需要在客戶端的 ~/.kube/config 中配置該 CA 證書的副本，以便你可以信任連線並確信它未被截獲。
你的客戶端可以在此階段提供 TLS 客戶端證書。
身份驗證
建立 TLS 後，HTTP 請求將進入身份驗證步驟。這在圖中顯示為步驟 1。叢集建立指令碼或叢集管理員配置 API 伺服器以執行一個或多個身份驗證模組。身份驗證器在 身份驗證 中有更詳細的描述。
身份驗證步驟的輸入是整個 HTTP 請求；但是，它通常會檢查請求頭和/或客戶端證書。
身份驗證模組包括客戶端證書、密碼和普通令牌、引導令牌以及 JSON Web 令牌（用於服務賬號）。
可以指定多個身份驗證模組，在這種情況下，它們會按順序嘗試，直到其中一個成功。
如果請求無法透過身份驗證，它將以 HTTP 狀態碼 401 被拒絕。否則，使用者將作為特定的 username 進行身份驗證，該使用者名稱可供後續步驟用於決策。有些身份驗證器還會提供使用者的組成員資格，而其他身份驗證器則不會。
儘管 Kubernetes 使用使用者名稱進行訪問控制決策和請求日誌記錄，但它沒有 User 物件，也不會在其 API 中儲存使用者名稱或其他使用者相關資訊。
授權
在請求被驗證為來自特定使用者後，該請求必須獲得授權。這在圖中標示為步驟 2。
請求必須包含請求者的使用者名稱、請求的操作以及受該操作影響的物件。如果現有策略宣告使用者有權完成請求的操作，則該請求被授權。
例如，如果 Bob 有以下策略，那麼他只能讀取 projectCaribou 名稱空間中的 Pod
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
如果 Bob 發出以下請求，該請求將被授權，因為他被允許讀取 projectCaribou 名稱空間中的物件。
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
如果 Bob 請求寫入（create 或 update）projectCaribou 名稱空間中的物件，他的授權將被拒絕。如果 Bob 請求讀取（get）不同名稱空間（如 projectFish）中的物件，那麼他的授權也將被拒絕。
Kubernetes 授權要求你使用通用的 REST 屬性來與現有組織範圍或雲提供商範圍的訪問控制系統進行互動。使用 REST 格式很重要，因為這些控制系統可能與 Kubernetes API 以外的其他 API 進行互動。
Kubernetes 支援多種授權模組，例如 ABAC 模式、RBAC 模式和 Webhook 模式。當管理員建立叢集時，他們會配置 API 伺服器中應該使用的授權模組。如果配置了多個授權模組，Kubernetes 會檢查每個模組，如果任何模組授權了請求，那麼請求就可以繼續進行。如果所有模組都拒絕了請求，那麼請求就會被拒絕（HTTP 狀態碼 403）。
要了解有關 Kubernetes 授權的更多資訊，包括使用受支援的授權模組建立策略的詳細資訊，請參閱授權。
准入控制
准入控制模組是可以修改或拒絕請求的軟體模組。除了授權模組可用的屬性之外，准入控制模組還可以訪問正在建立或修改的物件的 內容。
准入控制器作用於建立、修改、刪除或連線（代理）物件的請求。准入控制器不作用於僅僅讀取物件的請求。當配置了多個准入控制器時，它們會按順序呼叫。
這在圖中標示為步驟 3。
與身份驗證和授權模組不同，如果任何准入控制器模組拒絕，則請求會立即被拒絕。
除了拒絕物件之外，准入控制器還可以為欄位設定複雜的預設值。
可用的准入控制模組在准入控制器中有所描述。
一旦請求透過所有準入控制器，它將使用相應的 API 物件的驗證例程進行驗證，然後寫入物件儲存（如步驟 4 所示）。
審計
Kubernetes 審計提供了一系列與安全相關的、按時間順序排列的記錄，用於記錄叢集中操作的序列。叢集會審計由使用者、使用 Kubernetes API 的應用程式以及控制平面本身生成的操作。
更多資訊，請參閱審計。
下一步
閱讀更多關於身份驗證、授權和 API 訪問控制的文件。
你可以瞭解
- Pod 如何使用 Secret 獲取 API 憑據。