本文說明 Azure Kubernetes Service（AKS）如何決定已認證呼叫者在 Kubernetes API 下可做什麼。 它涵蓋了 AKS 支援的兩種授權模型，以及帶有 Azure ABAC 條件的細緻自訂資源控制。
關於 AKS 如何 最初認證 呼叫者，請參見 叢集認證概念。
關於四種 AKS 身份情境的定位，請參見 AKS 的存取與身份選項。
授權 Kubernetes API
呼叫者認證後，AKS 會評估呼叫者是否被授權執行該請求的動作。 AKS 支援兩種 Kubernetes API 授權模式：
- Kubernetes 基於角色的存取控制（RBAC）。 原生的 Kubernetes 授權模型。 權限定義為
Role和ClusterRole物件，並透過儲存在每個叢集中的RoleBinding和ClusterRoleBinding物件授予主體。 - Microsoft Entra ID 授權。 一個將授權決策委派給 Microsoft Entra ID 的 AKS 授權 Webhook。 權限是以 Azure 角色指派的形式授予 Entra ID 身分識別，並且可以選擇性地透過Azure ABAC 條件進行更精細的調整。
你可以在同一叢集上同時使用這兩種模型。 我們建議預設使用 Microsoft Entra ID 授權，並將 Kubernetes RBAC 保留給細粒度叢集內權限。 本節其餘部分將說明為什麼以及何時使用這些方法。
Kubernetes RBAC
Kubernetes RBAC 是上游的 Kubernetes 授權模型。 你建立Role或ClusterRole物件，這些物件在資源（如pods、deployments）上授予動詞（如get、list、create），並使用RoleBinding或ClusterRoleBinding物件將其綁定到主體（使用者、群組或服務帳號）。 Kubernetes API 伺服器內建的 RBAC 授權者會對每個請求評估這些綁定。
當你想要時，使用 Kubernetes RBAC：
- 以 Kubernetes 資訊清單形式、與其所保護的工作負載一同編寫，且經過細分化的叢集內每個命名空間存取控制。
- GitOps 管理的授權與您的應用程式設定存於同一個可信的資料來源。
- 工作負載用來呼叫 Kubernetes API 的叢集內服務帳號權限。
Kubernetes RBAC 權限範圍限定於單一叢集。 要對多個叢集套用相同政策，你必須將清單套用到每個叢集（通常透過 GitOps）。 在 Kubernetes RoleBinding 和 ClusterRoleBinding 物件中使用 Microsoft Entra 使用者和群組作為主體，這樣人類身份仍來自你的中央目錄。
關於 Kubernetes RBAC 模型的背景，請參閱 上游 Kubernetes RBAC 文件。 關於在 AKS 中的設定，請參見 使用 Kubernetes RBAC 與 Microsoft Entra 整合。
Microsoft Entra ID 授權用於 Kubernetes API
透過 Entra ID 授權，AKS 部署授權 webhook，將 Kubernetes API 授權決策委派給 Microsoft Entra ID。 當請求抵達 API 伺服器時，webhook 會呼叫 Entra ID checkaccess API，評估呼叫者的 Azure 角色指派（及任何附加的 ABAC 條件），並回傳允許或拒絕的決策。
相較於在每個叢集上管理 Kubernetes RBAC 資訊清單，Entra ID 授權能為您帶來以下好處：
- 單一身分識別平面。 管理你 Azure 資源存取的 Microsoft Entra 使用者、群組和服務主體，同時也管理你對 Kubernetes API 的存取。 沒有獨立的使用者目錄可以配置或輪換。
- 指派一次，控管多個叢集。 Azure 角色指派可以在 訂閱、管理群組或資源群組範圍內進行。 在資源群組範圍內指定單一角色，即可授予對該資源群組中所有現有及未來 AKS 叢集的存取權。 使用 Kubernetes RBAC，你必須對每個叢集分別套用清單。
- 條件存取與特權身份管理（PIM）。 叢集存取會自動繼承你組織現有的 Entra ID 條件存取政策（例如多重驗證或基於位置的限制），並可透過 PIM 即時提升。
- 集中式稽核。 每個角色指派變更都會與其他 Azure 資源變更一起記錄在 Azure 活動日誌中，這樣你就有一個叢集存取治理的稽核軌跡。
- 細粒度的自訂資源限制。 透過 ABAC 條件，你可以限制對特定自訂資源（CRD）群組和類型的存取，而無需撰寫每個叢集的 Kubernetes RBAC 清單。
AKS 提供以下內建的 Entra ID 授權角色：
| 角色 | Description |
|---|---|
| Azure Kubernetes Service RBAC Reader | 對命名空間中大多數物件的唯讀存取。 不允許觀看角色、角色綁定或Secrets。 |
| Azure Kubernetes Service RBAC 撰寫者 | 對命名空間中大多數物件的讀寫存取。 不允許查看或修改角色或角色綁定。 |
| Azure Kubernetes Service RBAC 管理員 | 在命名空間中，具有對大多數資源的讀寫權限，並且可以在命名空間內創建角色和角色綁定。 |
| Azure Kubernetes Service RBAC 叢集管理員 | 對叢集中所有資源、跨所有命名空間的完全控制權。 |
對於自訂權限模式，你可以撰寫自訂角色定義，針對特定 Kubernetes API 群組，利用 Microsoft.ContainerService 資源提供者的資料動作。 有關逐步設定與自訂角色範例，請參閱 使用 Microsoft Entra ID 授權以取得 Kubernetes API。
Comparison
| 能力 | Kubernetes RBAC | Entra ID 授權 |
|---|---|---|
| 身份來源 | Kubernetes 使用者、群組、服務帳號 | Microsoft Entra ID 身份識別 |
| 單一補助的範圍 | 一個叢集 | 資源、資源群組、訂閱或管理群組 |
| 多叢集治理 | 對每個叢集（通常是 GitOps）套用清單 | 一個較高範圍的角色分配可管理多個叢集 |
| 條件式存取/PIM | 不支援 | 繼承自 Entra ID |
| 稽核線索 | 叢集稽核日誌 | Azure 活動記錄 |
| 依CRD群組或類型篩選存取 | 針對每個 CRD 撰寫Role物件 |
在角色分配中使用 ABAC 條件屬性 |
以 ABAC 條件限制自訂資源存取
當你透過 Microsoft Entra ID 授權授權廣泛讀取權限，但想限制受指派者能讀取的自訂資源（CRD）時，請在角色指派中附加 Azure ABAC 條件。
如果沒有 ABAC 條件，授權讀取自訂資源需要使用萬用符，例如 Microsoft.ContainerService/managedClusters/*/read，涵蓋範圍內每個叢集中所有的 CRD。 透過 ABAC，你可以附加條件來限制特定 CRD 群組和類型的存取，例如，允許templates.gatekeeper.sh 同時封鎖kyverno.io，而不必撰寫每個叢集的 Kubernetes RBAC 清單。
對於 Kubernetes API 授權，你可以依照 API 群組和類型過濾對自訂資源的存取，使用以下屬性：
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
關於 Azure ABAC 的背景，請參見「 Azure 角色分配條件是什麼？」。 關於逐步設定，請參見 「使用 ABAC 條件限制自訂資源存取」。