參考：https://kubernetes.io/zh/docs/concepts/security/controlling-access/

本頁面概述了對 Kubernetes API 的訪問控制。

使用者使用 kubectl、客戶端庫或構造 REST 請求來訪問 Kubernetes API。 人類使用者和 Kubernetes 服務賬戶都可以被鑑權訪問 API。 當請求到達 API 時，它會經歷多個階段，如下圖所示：

傳輸安全

在典型的 Kubernetes 叢集中，API 伺服器在 443 埠上提供服務，受 TLS 保護。 API 伺服器出示證書。 該證書可以使用私有證書頒發機構（CA）簽名，也可以基於連結到公認的 CA 的公鑰基礎架構簽名。

如果你的叢集使用私有證書頒發機構，你需要在客戶端的 ~/.kube/config 檔案中提供該 CA 證書的副本， 以便你可以信任該連線並確認該連線沒有被攔截。

你的客戶端可以在此階段出示 TLS 客戶端證書。

認證

如上圖步驟 1 所示，建立 TLS 後， HTTP 請求將進入認證（Authentication）步驟。 叢集建立指令碼或者叢集管理員配置 API 伺服器，使之執行一個或多個身份認證元件。 身份認證元件在認證節中有更詳細的描述。

認證步驟的輸入整個 HTTP 請求；但是，通常元件只檢查頭部或/和客戶端證書。

認證模組包含客戶端證書、密碼、普通令牌、引導令牌和 JSON Web 令牌（JWT，用於服務賬戶）。

可以指定多個認證模組，在這種情況下，伺服器依次嘗試每個驗證模組，直到其中一個成功。

如果請求認證不通過，伺服器將以 HTTP 狀態碼 401 拒絕該請求。 反之，該使用者被認證為特定的 username，並且該使用者名稱可用於後續步驟以在其決策中使用。 部分驗證器還提供使用者的組成員身份，其他則不提供。

鑑權

如上圖的步驟 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 在 projectCaribou 名字空間中請求寫（create 或 update）物件，其鑑權請求將被拒絕。 如果 Bob 在諸如 projectFish 這類其它名字空間中請求讀取（get）物件，其鑑權也會被拒絕。

Kubernetes 鑑權要求使用公共 REST 屬性與現有的組織範圍或雲提供商範圍的訪問控制系統進行互動。 使用 REST 格式很重要，因為這些控制系統可能會與 Kubernetes API 之外的 API 互動。

Kubernetes 支援多種鑑權模組，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 管理員建立叢集時，他們配置應在 API 伺服器中使用的鑑權模組。 如果配置了多個鑑權模組，則 Kubernetes 會檢查每個模組，任意一個模組鑑權該請求，請求即可繼續； 如果所有模組拒絕了該請求，請求將會被拒絕（HTTP 狀態碼 403）。

要了解更多有關 Kubernetes 鑑權的更多資訊，包括有關使用支援鑑權模組建立策略的詳細資訊， 請參閱鑑權。

准入控制

准入控制模組是可以修改或拒絕請求的軟體模組。 除鑑權模組可用的屬性外，准入控制模組還可以訪問正在建立或修改的物件的內容。

准入控制器對建立、修改、刪除或（通過代理）連線物件的請求進行操作。 准入控制器不會對僅讀取物件的請求起作用。 有多個准入控制器被配置時，伺服器將依次呼叫它們。

這一操作如上圖的步驟 3 所示。

與身份認證和鑑權模組不同，如果任何准入控制器模組拒絕某請求，則該請求將立即被拒絕。

除了拒絕物件之外，准入控制器還可以為欄位設定複雜的預設值。

可用的准入控制模組在准入控制器中進行了描述。

請求通過所有準入控制器後，將使用檢驗例程檢查對應的 API 物件，然後將其寫入物件儲存（如步驟 4 所示）。

API 伺服器埠和 IP

前面的討論適用於傳送到 API 伺服器的安全埠的請求（典型情況）。 API 伺服器實際上可以在 2 個埠上提供服務：

預設情況下，Kubernetes API 伺服器在 2 個埠上提供 HTTP 服務：

1.localhost 埠:
    用於測試和引導，以及主控節點上的其他元件（排程器，控制器管理器）與 API 通訊
    沒有 TLS
    預設為埠 8080，使用 --insecure-port 進行更改
    預設 IP 為 localhost，使用 --insecure-bind-address 進行更改
    請求 繞過 身份認證和鑑權模組
    由准入控制模組處理的請求
    受需要訪問主機的保護

2.“安全埠”：
    儘可能使用
    使用 TLS。 用 --tls-cert-file 設定證書，用 --tls-private-key-file 設定金鑰
    預設埠 6443，使用 --secure-port 更改
    預設 IP 是第一個非本地網路介面，使用 --bind-address 更改
    請求須經身份認證和鑑權元件處理
    請求須經准入控制模組處理
    身份認證和鑑權模組執行