Azure Kubernetes Service (AKS) 的存取與身分識別選項Access and identity options for Azure Kubernetes Service (AKS)

有不同的方式可驗證、控制存取/授權和保護 Kubernetes 叢集。There are different ways to authenticate, control access/authorize and secure Kubernetes clusters. 使用 Kubernetes 角色型存取控制 (Kubernetes RBAC) ,您可以授與使用者、群組和服務帳戶只存取所需資源的存取權。Using Kubernetes role-based access control (Kubernetes RBAC), you can grant users, groups, and service accounts access to only the resources they need. 使用 Azure Kubernetes Service (AKS) ,您可以使用 Azure Active Directory 和 Azure RBAC 進一步增強安全性和許可權結構。With Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure by using Azure Active Directory and Azure RBAC. 這些方法可協助您保護叢集存取,並僅提供開發人員和操作員所需的最低許可權。These approaches help you secure your cluster access and provide only the minimum required permissions to developers and operators.

本文介紹可協助您在 AKS 中驗證和指派許可權的核心概念。This article introduces the core concepts that help you authenticate and assign permissions in AKS.

AKS 服務許可權AKS service permissions

建立叢集時,AKS 會建立或修改建立和執行叢集所需的資源,例如 Vm 和 Nic,代表建立叢集的使用者。When creating a cluster, AKS creates or modifies resources it needs to create and run the cluster, such as VMs and NICs, on behalf of the user creating the cluster. 此身分識別與叢集的身分識別許可權不同,它是在叢集建立期間所建立。This identity is distinct from the cluster's identity permission, which is created during cluster creation.

建立和操作叢集許可權的身分識別Identity creating and operating the cluster permissions

建立和操作叢集的身分識別需要下列許可權。The following permissions are needed by the identity creating and operating the cluster.

權限Permission 原因Reason
Microsoft. Compute/diskEncryptionSets/readMicrosoft.Compute/diskEncryptionSets/read 需要讀取磁片加密集識別碼。Required to read disk encryption set ID.
Microsoft. Compute/proximityPlacementGroups/writeMicrosoft.Compute/proximityPlacementGroups/write 更新鄰近放置群組所需。Required for updating proximity placement groups.
設定應用程式閘道和加入子網所需。Required to configure application gateways and join the subnet.
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/join/action 使用自訂 VNET 時,必須設定子網的網路安全性群組。Required to configure the Network Security Group for the subnet when using a custom VNET.
在 Standard Load Balancer 上設定輸出公用 Ip 所需。Required to configure the outbound public IPs on the Standard Load Balancer.
建立和更新 Log Analytics 工作區和適用于容器的 Azure 監視所需。Required to create and update Log Analytics workspaces and Azure monitoring for containers.

AKS 叢集身分識別許可權AKS cluster identity permissions

AKS 叢集身分識別會使用下列許可權,該身分識別會在建立叢集時建立並與 AKS 叢集建立關聯。The following permissions are used by the AKS cluster identity, which is created and associated with the AKS cluster when the cluster is created. 基於下列原因,會使用每個許可權:Each permission is used for the reasons below:

權限Permission 原因Reason
設定 LoadBalancer 服務的負載平衡器所需。Required to configure the load balancer for a LoadBalancer service.
尋找和設定 LoadBalancer 服務的公用 Ip 時需要。Required to find and configure public IPs for a LoadBalancer service.
Microsoft.Network/publicIPAddresses/join/actionMicrosoft.Network/publicIPAddresses/join/action 設定 LoadBalancer 服務的公用 Ip 所需。Required for configuring public IPs for a LoadBalancer service.
建立或刪除 LoadBalancer 服務的安全性規則所需。Required to create or delete security rules for a LoadBalancer service.
Microsoft. 計算/位置/DiskOperations/讀取Microsoft.Compute/locations/DiskOperations/read
設定 AzureDisks 時所需。Required to configure AzureDisks.
設定 AzureFile 或 AzureDisk 的儲存體帳戶所需。Required to configure storage accounts for AzureFile or AzureDisk.
設定節點的路由表和路由所需。Required to configure route tables and routes for nodes.
Microsoft.Compute/virtualMachines/readMicrosoft.Compute/virtualMachines/read 需要在 VMAS 中尋找虛擬機器的資訊,例如區域、容錯網域、大小和資料磁片。Required to find information for virtual machines in a VMAS, such as zones, fault domain, size, and data disks.
Microsoft.Compute/virtualMachines/writeMicrosoft.Compute/virtualMachines/write 將 AzureDisks 附加至 VMAS 中的虛擬機器所需。Required to attach AzureDisks to a virtual machine in a VMAS.
Microsoft. Compute/virtualMachineScaleSets/virtualmachines/instanceView/readMicrosoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read
需要尋找虛擬機器擴展集中虛擬機器的資訊,例如區域、容錯網域、大小和資料磁片。Required to find information for virtual machines in a virtual machine scale set, such as zones, fault domain, size, and data disks.
Microsoft.Network/networkInterfaces/writeMicrosoft.Network/networkInterfaces/write 將 VMAS 中的虛擬機器新增至負載平衡器後端位址集區的必要項。Required to add a virtual machine in a VMAS to a load balancer backend address pool.
Microsoft.Compute/virtualMachineScaleSets/writeMicrosoft.Compute/virtualMachineScaleSets/write 必須將虛擬機器擴展集新增至負載平衡器後端位址集區,並將虛擬機器擴展集中的節點相應放大。Required to add a virtual machine scale set to a load balancer backend address pools and scale out nodes in a virtual machine scale set.
Microsoft. Compute/virtualMachineScaleSets/virtualmachines/writeMicrosoft.Compute/virtualMachineScaleSets/virtualmachines/write 需要附加 AzureDisks,並將虛擬機器從虛擬機器擴展集新增至負載平衡器。Required to attach AzureDisks and add a virtual machine from a virtual machine scale set to the load balancer.
Microsoft.Network/networkInterfaces/readMicrosoft.Network/networkInterfaces/read 針對 VMAS 中的虛擬機器搜尋內部 Ip 和負載平衡器後端位址集區所需。Required to search internal IPs and load balancer backend address pools for virtual machines in a VMAS.
Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/readMicrosoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read 針對虛擬機器擴展集中的虛擬機器,搜尋內部 Ip 和負載平衡器後端位址集區所需。Required to search internal IPs and load balancer backend address pools for a virtual machine in a virtual machine scale set.
Microsoft. Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfiguration/publicipaddresses/readMicrosoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ ipconfigurations/publicipaddresses/read 需要在虛擬機器擴展集中尋找虛擬機器的公用 Ip。Required to find public IPs for a virtual machine in a virtual machine scale set.
需要確認是否有另一個資源群組中的內部負載平衡器的子網。Required to verify if a subnet exists for the internal load balancer in another resource group.
設定 AzureDisk 的快照集所需。Required to configure snapshots for AzureDisk.
尋找用來尋找 AzureDisk 磁片區限制的虛擬機器大小所需。Required to find virtual machine sizes for finding AzureDisk volume limits.

其他叢集身分識別許可權Additional cluster identity permissions

使用特定屬性建立叢集時,叢集身分識別需要下列其他許可權。The following additional permissions are needed by the cluster identity when creating a cluster with specific attributes. 系統不會自動指派這些許可權,因此您必須在叢集身分識別建立之後,將這些許可權新增至叢集身分識別。These permissions are not automatically assigned so you must add these permissions to the cluster identity after its created.

權限Permission 原因Reason
如果使用另一個資源群組中的網路安全性群組,則為必要項。Required if using a network security group in another resource group. 設定 LoadBalancer 服務的安全性規則所需。Required to configure security rules for a LoadBalancer service.
如果在其他資源群組(例如自訂 VNET)中使用子網,則為必要項。Required if using a subnet in another resource group such as a custom VNET.
如果使用與另一個資源群組中的路由表相關聯的子網(例如自訂路由表的自訂 VNET),則為必要項。Required if using a subnet associated with a route table in another resource group such as a custom VNET with a custom route table. 需要確認子網是否已存在於其他資源群組中的子網。Required to verify if a subnet already exists for the subnet in the other resource group.
Microsoft.Network/virtualNetworks/subnets/readMicrosoft.Network/virtualNetworks/subnets/read 如果使用另一個資源群組中的內部負載平衡器,則為必要項。Required if using an internal load balancer in another resource group. 需要確認資源群組中的內部負載平衡器是否已有子網存在。Required to verify if a subnet already exists for the internal load balancer in the resource group.

Kubernetes 以角色為基礎的存取控制 (Kubernetes RBAC) Kubernetes role-based access control (Kubernetes RBAC)

為了提供使用者可執行之動作的細微篩選,Kubernetes 會使用 Kubernetes 角色型存取控制 (Kubernetes RBAC) 。To provide granular filtering of the actions that users can do, Kubernetes uses Kubernetes role-based access control (Kubernetes RBAC). 此控制機制可讓您指派權限給使用者或使用者群組,以執行像是建立或修改資源,或檢視執行中應用程式工作負載的記錄等動作。This control mechanism lets you assign users, or groups of users, permission to do things like create or modify resources, or view logs from running application workloads. 這些權限可以只限於單一命名空間,或授與給整個 AKS 叢集。These permissions can be scoped to a single namespace, or granted across the entire AKS cluster. 透過 Kubernetes RBAC,您可以建立「角色」來定義權限,然後藉由「角色繫結」將這些角色指派給使用者。With Kubernetes RBAC, you create roles to define permissions, and then assign those roles to users with role bindings.

如需詳細資訊,請參閱 使用 KUBERNETES RBAC 授權For more information, see Using Kubernetes RBAC authorization.

Roles 和 ClusterRolesRoles and ClusterRoles

使用 Kubernetes RBAC 將權限指派給使用者之前,您必須先將這些權限定義為「角色」。Before you assign permissions to users with Kubernetes RBAC, you first define those permissions as a Role. Kubernetes 角色會「授與」權限。Kubernetes roles grant permissions. 拒絕 許可權沒有任何概念。There's no concept of a deny permission.

Roles (角色) 會用來授與一個命名空間內的權限。Roles are used to grant permissions within a namespace. 如果您需要將權限授與整個叢集,或授與指定命名空間外部的叢集資源,可以改用 ClusterRoles。If you need to grant permissions across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoles.

ClusterRole 會以同樣方式將權限授與資源,但這些權限可以套用至整個叢集中的資源,而不是特定命名空間中的資源。A ClusterRole works in the same way to grant permissions to resources, but can be applied to resources across the entire cluster, not a specific namespace.

RoleBindings 和 ClusterRoleBindingsRoleBindings and ClusterRoleBindings

一旦將角色定義為可授與權限給資源,您就可以透過 RoleBinding 指派這些 Kubernetes RBAC 權限。Once roles are defined to grant permissions to resources, you assign those Kubernetes RBAC permissions with a RoleBinding. 如果您的 AKS 叢集 與 Azure Active Directory (Azure AD) 整合 ,系結就是這些 Azure AD 使用者授與的許可權,以在叢集中執行動作,請參閱如何 使用 Kubernetes 角色型存取控制和 Azure Active Directory 身分識別來控制對叢集資源的存取If your AKS cluster integrates with Azure Active Directory (Azure AD), bindings are how those Azure AD users are granted permissions to perform actions within the cluster, see how in Control access to cluster resources using Kubernetes role-based access control and Azure Active Directory identities.

角色繫結會用來為指定命名空間指派角色。Role bindings are used to assign roles for a given namespace. 此方法可讓您以邏輯方式區隔單一 AKS 叢集,讓使用者只能存取獲派命名空間中的應用程式資源。This approach lets you logically segregate a single AKS cluster, with users only able to access the application resources in their assigned namespace. 如果您需要將角色繫結到整個叢集,或繫結到指定命名空間外部的叢集資源,可以改用 ClusterRoleBindings。If you need to bind roles across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoleBindings.

ClusterRoleBinding 會以同樣方式將角色繫結到使用者,但這些角色可以套用至整個叢集中的資源,而不是特定命名空間中的資源。A ClusterRoleBinding works in the same way to bind roles to users, but can be applied to resources across the entire cluster, not a specific namespace. 此方法可讓您允許系統管理員或支援工程師存取 AKS 叢集中的所有資源。This approach lets you grant administrators or support engineers access to all resources in the AKS cluster.


Microsoft/AKS 所採取的任何叢集動作都是在內建 Kubernetes 角色 aks-service 和內建角色系結的使用者同意下進行 aks-service-rolebindingAny cluster actions taken by Microsoft/AKS are made with user consent under a built-in Kubernetes role aks-service and built-in role binding aks-service-rolebinding. 此角色可讓 AKS 對叢集問題進行疑難排解和診斷,但無法修改許可權,也無法建立角色或角色系結,或其他高許可權動作。This role enables AKS to troubleshoot and diagnose cluster issues, but can't modify permissions nor create roles or role bindings, or other high privilege actions. 只有在具有即時 (JIT) 存取權的主動式支援票證下,才會啟用角色存取。Role access is only enabled under active support tickets with just-in-time (JIT) access. 深入瞭解 AKS 支援原則Read more about AKS support policies.

Kubernetes 服務帳戶Kubernetes service accounts

Kubernetes 的其中一個主要使用者類型是「服務帳戶」。One of the primary user types in Kubernetes is a service account. 服務帳戶存在 Kubernetes API 中,並受其管理。A service account exists in, and is managed by, the Kubernetes API. 服務帳戶的認證會儲存為 Kubernetes 祕密,如此便可讓已獲授權的 Pod 用這些認證與 API 伺服器進行通訊。The credentials for service accounts are stored as Kubernetes secrets, which allows them to be used by authorized pods to communicate with the API Server. 大部分的 API 要求會為服務帳戶或一般使用者帳戶提供驗證權杖。Most API requests provide an authentication token for a service account or a normal user account.

一般使用者帳戶可讓人為系統管理員或開發人員提供更傳統的存取權,而不只是服務與處理常式。Normal user accounts allow more traditional access for human administrators or developers, not just services, and processes. Kubernetes 本身不會提供儲存一般使用者帳戶和密碼的身分識別管理解決方案。Kubernetes itself doesn't provide an identity management solution where regular user accounts and passwords are stored. 而是將外部身分識別解決方案整合到 Kubernetes。Instead, external identity solutions can be integrated into Kubernetes. 對 AKS 叢集而言,此整合的身分識別解決方案就是 Azure Active Directory。For AKS clusters, this integrated identity solution is Azure Active Directory.

如需有關 Kubernetes 中身分識別選項的詳細資訊,請參閱 Kubernetes 驗證For more information on the identity options in Kubernetes, see Kubernetes authentication.

Azure Active Directory 整合Azure Active Directory integration

AKS 叢集的安全性可以透過整合的 Azure Active Directory (AD) 來加強。The security of AKS clusters can be enhanced with the integration of Azure Active Directory (AD). 以數十年企業身分識別管理技術為基礎,Azure AD 是多租用戶雲端式目錄,也是身分識別管理服務,可將核心目錄服務、應用程式存取管理、身分識別保護結合在單一解決方案中。Built on decades of enterprise identity management, Azure AD is a multi-tenant, cloud-based directory, and identity management service that combines core directory services, application access management, and identity protection. 透過 Azure AD,您可以將內部部署身分識別整合至 AKS 叢集,以對帳戶管理和安全性提供單一來源。With Azure AD, you can integrate on-premises identities into AKS clusters to provide a single source for account management and security.

整合 Azure Active Directory 與 AKS 叢集

透過與 Azure AD 整合的 AKS 叢集,您可以允許使用者或群組存取命名空間內或叢集上的 Kubernetes 資源。With Azure AD-integrated AKS clusters, you can grant users or groups access to Kubernetes resources within a namespace or across the cluster. 若要取得 kubectl 設定內容,使用者可執行 az aks get-credentials 命令。To obtain a kubectl configuration context, a user can run the az aks get-credentials command. 當使用者接著與 AKS 叢集互動時 kubectl ,系統會提示他們使用 Azure AD 認證登入。When a user then interacts with the AKS cluster with kubectl, they're prompted to sign in with their Azure AD credentials. 此方法可對使用者帳戶管理和密碼認證提供單一來源。This approach provides a single source for user account management and password credentials. 使用者只能存取叢集系統管理員所定義的資源。The user can only access the resources as defined by the cluster administrator.

透過 OpenID Connect 對 AKS 叢集提供 Azure AD 驗證。Azure AD authentication is provided to AKS clusters with OpenID Connect. OpenID Connect 是以 OAuth 2.0 通訊協定為建置基礎的身分識別層。OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. 如需 OpenID Connect 的詳細資訊,請參閱 OPEN ID Connect 檔For more information on OpenID Connect, see the Open ID connect documentation. 從 Kubernetes 叢集內部, Webhook 權杖驗證 用來驗證驗證權杖。From inside of the Kubernetes cluster, Webhook Token Authentication is used to verify authentication tokens. Webhook 權杖驗證已設定並當作 AKS 叢集的一部分管理。Webhook token authentication is configured and managed as part of the AKS cluster.

Webhook 和 API 伺服器Webhook and API server

Webhook 和 API 伺服器驗證流程

如上圖所示,API 伺服器會呼叫 AKS webhook 伺服器,並執行下列步驟:As shown in the graphic above, the API server calls the AKS webhook server and performs the following steps:

  1. Kubectl 會使用 Azure AD 用戶端應用程式,透過 OAuth 2.0 裝置授權授與流程來登入使用者。The Azure AD client application is used by kubectl to sign in users with OAuth 2.0 device authorization grant flow.
  2. Azure AD 提供 access_token、id_token 和 refresh_token。Azure AD provides an access_token, id_token, and a refresh_token.
  3. 使用者使用來自 kubeconfig 的 access_token 提出要求 kubectl。The user makes a request to kubectl with an access_token from kubeconfig.
  4. Kubectl 會將 access_token 傳送至 API 伺服器。Kubectl sends the access_token to API Server.
  5. API 伺服器是使用 Auth WebHook 伺服器設定來執行驗證。The API Server is configured with the Auth WebHook Server to perform validation.
  6. 驗證 webhook 伺服器藉由檢查 Azure AD 公開簽署金鑰來確認 JSON Web 權杖簽章是否有效。The authentication webhook server confirms the JSON Web Token signature is valid by checking the Azure AD public signing key.
  7. 伺服器應用程式會使用使用者提供的認證,從 MS 圖形 API 查詢登入使用者的群組成員資格。The server application uses user-provided credentials to query group memberships of the logged-in user from the MS Graph API.
  8. 回應會傳送至 API 伺服器,其具有使用者資訊,例如使用者主體名稱 (UPN) 存取權杖的宣告,以及使用者的群組成員資格(以物件識別碼為基礎)。A response is sent to the API Server with user information such as the user principal name (UPN) claim of the access token, and the group membership of the user based on the object ID.
  9. API 會根據 Kubernetes 角色/RoleBinding 來執行授權決策。The API performs an authorization decision based on the Kubernetes Role/RoleBinding.
  10. 授權之後,API 伺服器會將回應傳回給 kubectl。Once authorized, the API server returns a response to kubectl.
  11. Kubectl 會將意見反應提供給使用者。Kubectl provides feedback to the user.

在這裡瞭解如何整合 AKS 與 AAD。Learn how to integrate AKS with AAD here.

Azure 角色型存取控制 (Azure RBAC)Azure role-based access control (Azure RBAC)

Azure RBAC 是建置於 Azure Resource Manager 上的授權系統,可提供更細緻的 Azure 資源存取管理。Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

Azure RBAC 是設計用來處理您 Azure 訂用帳戶內的資源,而 Kubernetes RBAC 是設計來處理 AKS 叢集中的 Kubernetes 資源。Azure RBAC is designed to work on resources within your Azure subscription while Kubernetes RBAC is designed to work on Kubernetes resources within your AKS cluster.

透過 Azure RBAC,您可以建立「角色定義」來概述要套用的權限。With Azure RBAC, you create a role definition that outlines the permissions to be applied. 然後,使用者或群組會透過特定 範圍角色指派(可能是個別資源、資源群組或跨訂用帳戶)指派此角色定義。A user or group is then assigned this role definition via a role assignment for a particular scope, which could be an individual resource, a resource group, or across the subscription.

如需詳細資訊,請參閱 什麼是 AZURE RBAC) (azure 角色型存取控制?For more information, see What is Azure role-based access control (Azure RBAC)?

完全操作 AKS 叢集所需的存取層級有兩種:There are two levels of access needed to fully operate an AKS cluster:

  1. 存取 Azure 訂用帳戶中的 AKS 資源Access the AKS resource in your Azure subscription. 此程式可讓您控制使用 AKS Api 來調整或升級叢集的專案,以及提取您的 kubeconfig。This process allows you to control things scaling or upgrading your cluster using the AKS APIs as well as pull your kubeconfig.
  2. 存取 Kubernetes API。Access to the Kubernetes API. 這項存取是透過KUBERNETES RBAC (傳統) 或整合 AZURE RBAC 與 AKS 來 Kubernetes 授權來控制。This access is controlled either by Kubernetes RBAC (traditionally) or by integrating Azure RBAC with AKS for Kubernetes authorization

Azure RBAC 可授權存取 AKS 資源Azure RBAC to authorize access to the AKS resource

使用 Azure RBAC,您可以提供使用者 (或身分識別) ,以細微存取權跨一或多個訂用帳戶 AKS 資源。With Azure RBAC, you can provide your users (or identities) with granular access to AKS resources across one or more subscriptions. 例如,您可能會有 Azure Kubernetes Service 參與者角色 ,可讓您執行調整和升級叢集等動作。For example, you could have the Azure Kubernetes Service Contributor role that allows you to do actions like scale and upgrade your cluster. 另一位使用者可能會擁有只提供提取系統管理員 kubeconfig 許可權的 Azure Kubernetes Service 叢集管理員角色While another user could have the Azure Kubernetes Service Cluster Admin role that only gives permission to pull the Admin kubeconfig.

或者,您可以為您的使用者提供一般 參與者 角色,此角色會包含上述許可權,以及 AKS 資源上可能的每個動作,但管理許可權本身除外。Alternatively you could give your user the general Contributor role, which would encompass the above permissions and every action possible on the AKS resource with the exception of managing permissions itself.

深入瞭解如何使用 Azure RBAC 來保護 kubeconfig 檔案的存取權,以存取 此處的 Kubernetes API。See more how to use Azure RBAC to secure the access to the kubeconfig file that gives access to the Kubernetes API here.

適用于 Kubernetes 授權的 Azure RBAC (預覽版) Azure RBAC for Kubernetes Authorization (Preview)

透過 Azure RBAC 整合,AKS 將會使用 Kubernetes 授權 webhook 伺服器,讓您使用 Azure 角色定義和角色指派來管理 Azure AD 整合式 K8s 叢集資源的許可權和指派。With the Azure RBAC integration, AKS will use a Kubernetes Authorization webhook server to enable you to manage permissions and assignments of Azure AD-integrated K8s cluster resources using Azure role definition and role assignments.

適用于 Kubernetes 的 Azure RBAC 授權流程

如上圖所示,當使用 Azure RBAC 整合時,所有對 Kubernetes API 的要求都會遵循與 Azure Active integration 一節中所述的相同驗證流程。As shown on the above diagram, when using the Azure RBAC integration all requests to the Kubernetes API will follow the same authentication flow as explained on the Azure Active integration section.

但在該情況下,您不需要只依賴 Kubernetes RBAC 進行授權,只要在 AAD 中有提出要求的身分識別,就會將要求授與 Azure 授權。But after that, instead of solely relying on Kubernetes RBAC for Authorization, the request is actually going to be authorized by Azure, as long as the identity that made the request exists in AAD. 如果身分識別不存在於 AAD 中(例如 Kubernetes 服務帳戶),則 Azure RBAC 將不會啟動,而且它將會是一般 Kubernetes RBAC。If the identity doesn't exist in AAD, for example a Kubernetes service account, then the Azure RBAC won't kick in, and it will be the normal Kubernetes RBAC.

在此案例中,您可以為使用者提供四個內建角色的其中一個,或建立自訂角色,就像使用 Kubernetes 角色一樣,但在此案例中使用 Azure RBAC 機制和 Api。In this scenario you could give users one of the four built-in roles, or create custom roles as you would do with Kubernetes roles but in this case using the Azure RBAC mechanisms and APIs.

例如,這項功能可讓您不只為使用者授與跨訂用帳戶 AKS 資源的許可權,還可以設定並提供他們在每個控制 Kubernetes API 存取權的叢集中所擁有的角色和許可權。This feature will allow you to, for example, not only give users permissions to the AKS resource across subscriptions but set up and give them the role and permissions that they will have inside each of those clusters that controls the access to the Kubernetes API. 例如,您可以授與 Azure Kubernetes Service RBAC Viewer 訂用帳戶範圍的角色,其收件者將能夠列出並取得所有叢集的所有 Kubernetes 物件,但無法加以修改。For example, you can grant the Azure Kubernetes Service RBAC Viewer role on the subscription scope and its recipient will be able to list and get all Kubernetes objects from all clusters, but not modify them.

內建角色Built-in roles

AKS 提供下列四個內建角色。AKS provides the following four built-in roles. 它們類似于 Kubernetes 的 內建角色 ,但有一些差異,例如支援 CRDs。They are similar to the Kubernetes built-in roles but with a few differences like supporting CRDs. 如需每個內建角色所允許之動作的完整清單,請參閱 這裡For the full list of actions allowed by each built-in role, see here.

角色Role 描述Description
Azure Kubernetes Service RBAC 檢視器Azure Kubernetes Service RBAC Viewer 允許唯讀存取,以查看命名空間中的大部分物件。Allows read-only access to see most objects in a namespace. 它不允許查看角色或角色系結。It doesn't allow viewing roles or role bindings. 此角色不允許 Secrets 進行查看,因為讀取秘密的內容可讓您存取 ServiceAccount 命名空間中的認證,以允許 API 存取命名 ServiceAccount 空間中的任何憑證 (形式的許可權擴大) This role doesn't allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation)
Azure Kubernetes Service RBAC 寫入器Azure Kubernetes Service RBAC Writer 允許對命名空間中大部分物件的讀取/寫入存取。Allows read/write access to most objects in a namespace. 此角色不允許查看或修改角色或角色系結。This role doesn't allow viewing or modifying roles or role bindings. 不過,此角色可讓您存取和執行 pod Secrets 作為命名空間中的任何 ServiceAccount,因此可以用來取得命名空間中任何 ServiceAccount 的 API 存取層級。However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace.
Azure Kubernetes Service RBAC 管理員Azure Kubernetes Service RBAC Admin 允許系統管理員存取權,可在命名空間中授與。Allows admin access, intended to be granted within a namespace. 允許對命名空間中大部分資源的讀取/寫入存取 (或叢集範圍) ,包括在命名空間內建立角色和角色系結的能力。Allows read/write access to most resources in a namespace (or cluster scope), including the ability to create roles and role bindings within the namespace. 此角色不允許寫入資源配額或命名空間本身的存取權。This role doesn't allow write access to resource quota or to the namespace itself.
Azure Kubernetes Service RBAC 叢集管理員Azure Kubernetes Service RBAC Cluster Admin 允許超級使用者存取在任何資源上執行任何動作。Allows super-user access to perform any action on any resource. 它可讓您完整控制叢集中的每個資源,以及所有命名空間中的資源。It gives full control over every resource in the cluster and in all namespaces.

若要瞭解如何啟用 Azure RBAC 以進行 Kubernetes 授權,請 參閱這裡To learn how to enable Azure RBAC for Kubernetes authorization, read here.


下表摘要說明當 Azure AD 整合啟用時,使用者可以向 Kubernetes 進行驗證的方式。This table summarizes the ways users can authenticate to Kubernetes when Azure AD integration is enabled. 在所有情況下,使用者的命令順序為:In all cases, the user's sequence of commands is:

  1. 執行 az login 以向 Azure 進行驗證。Run az login to authenticate to Azure.
  2. 執行 az aks get-credentials 以將叢集的認證下載至 .kube/configRun az aks get-credentials to download credentials for the cluster into .kube/config.
  3. 執行 kubectl 命令 (第一個命令可能會觸發以瀏覽器為基礎的驗證,以驗證叢集,如下表所述) 。Run kubectl commands (the first of which may trigger browser-based authentication to authenticate to the cluster, as described in the following table).

第二個數據行中所指的角色授與是 Azure 入口網站中 [ 存取控制 ] 索引標籤上所顯示的 Azure RBAC 角色授與。The Role Grant referred to in the second column is the Azure RBAC role grant shown on the Access Control tab in the Azure portal. 叢集系統管理員 Azure AD 群組會顯示在入口網站中的 [ 設定] 索引 標籤上, (或 --aad-admin-group-object-ids Azure CLI) 中的參數名稱。The Cluster Admin Azure AD Group is shown on the Configuration tab in the portal (or with parameter name --aad-admin-group-object-ids in the Azure CLI).

描述Description 需要角色授與Role grant required 叢集系統管理員 Azure AD 群組 (s) Cluster admin Azure AD group(s) 使用時機When to use
使用用戶端憑證的舊版管理員登入Legacy admin login using client certificate Azure Kubernetes 管理員角色Azure Kubernetes Admin Role. 此角色可 az aks get-credentials 用於 --admin 旗標,這會將 舊版 (非 Azure AD) 叢集系統管理員憑證 下載到使用者 .kube/configThis role allows az aks get-credentials to be used with the --admin flag, which downloads a legacy (non-Azure AD) cluster admin certificate into the user's .kube/config. 這是「Azure Kubernetes 管理員角色」唯一的用途。This is the only purpose of "Azure Kubernetes Admin Role". n/an/a 如果您被永久封鎖,但無法存取可存取叢集的有效 Azure AD 群組。If you're permanently blocked by not having access to a valid Azure AD group with access to your cluster.
具有手動 (叢集) RoleBindings 的 Azure ADAzure AD with manual (Cluster)RoleBindings Azure Kubernetes 使用者角色Azure Kubernetes User Role. 「使用者」角色允許在 az aks get-credentials 沒有旗標的情況下使用 --adminThe "User" role allows az aks get-credentials to be used without the --admin flag. (這是「Azure Kubernetes 使用者角色」的唯一用途。 ) 結果,在啟用 Azure AD 的叢集上,會將 空白專案 下載到 .kube/config 中,以在第一次使用瀏覽器式驗證時觸發瀏覽器型驗證 kubectl(This is the only purpose of "Azure Kubernetes User Role".) The result, on an Azure AD-enabled cluster, is the download of an empty entry into .kube/config, which triggers browser-based authentication when it's first used by kubectl. 使用者不在這些群組中。User is not in any of these groups. 由於使用者不在任何叢集系統管理員群組中,因此其權利將由叢集系統管理員所設定的任何 RoleBindings 或 ClusterRoleBindings 完全控制。Because the user is not in any Cluster Admin groups, their rights will be controlled entirely by any RoleBindings or ClusterRoleBindings that have been set up by cluster admins. (Cluster) RoleBindings 提名 Azure AD 的使用者或 Azure AD 群組 作為其 subjectsThe (Cluster)RoleBindings nominate Azure AD users or Azure AD groups as their subjects. 如果未設定這類系結,使用者將無法 excute 任何 kubectl 命令。If no such bindings have been set up, the user will not be able to excute any kubectl commands. 如果您想要更細緻的存取控制,且您未使用 Azure RBAC 進行 Kubernetes 授權。If you want fine-grained access control, and you're not using Azure RBAC for Kubernetes Authorization. 請注意,設定系結的使用者必須以這個表格中所列的其中一種方法來登入。Note that the user who sets up the bindings must log in by one of the other methods listed in this table.
依管理群組成員 Azure ADAzure AD by member of admin group 同上Same as above 使用者是此處所列其中一個群組的成員。User is a member of one of the groups listed here. AKS 會自動產生 ClusterRoleBinding,將所有列出的群組系結至 cluster-admin Kubernetes 角色。AKS automatically generates a ClusterRoleBinding that binds all of the listed groups to the cluster-admin Kubernetes role. 因此,這些群組中的使用者可以執行所有 kubectl 命令 cluster-adminSo users in these groups can run all kubectl commands as cluster-admin. 如果您想要為使用者提供完整的系統管理員許可權,而 是使用 Azure RBAC 進行 Kubernetes 授權,則為。If you want to conveniently grant users full admin rights, and are not using Azure RBAC for Kubernetes authorization.
使用適用于 Kubernetes 授權的 Azure RBAC Azure ADAzure AD with Azure RBAC for Kubernetes Authorization 兩個角色:首先, Azure Kubernetes 使用者角色 (如上) 所示。Two roles: First, Azure Kubernetes User Role (as above). 其次,其中一個「Azure Kubernetes Service RBAC...」以上列出的角色,或您自己的自訂替代方案。Second, one of the "Azure Kubernetes Service RBAC..." roles listed above, or your own custom alternative. 啟用適用于 Kubernetes 授權的 Azure RBAC 時,[設定] 索引標籤上的 [管理員角色] 欄位是不相關的。The admin roles field on the Configuration tab is irrelevant when Azure RBAC for Kubernetes Authorization is enabled. 您正在使用 Azure RBAC 進行 Kubernetes 授權。You are using Azure RBAC for Kubernetes authorization. 這種方法可讓您更精細地控制,而不需要設定 RoleBindings 或 ClusterRoleBindings。This approach gives you fine-grained control, without the need to set up RoleBindings or ClusterRoleBindings.

後續步驟Next steps

如需有關 Kubernetes 及 AKS 核心概念的詳細資訊,請參閱下列文章:For more information on core Kubernetes and AKS concepts, see the following articles: