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

向 Kubernetes 叢集進行驗證及保護 Kubernetes 叢集的方式有很多種。There are different ways to authenticate with and secure Kubernetes clusters. 若使用角色型存取控制 (RBAC),您可以只授與使用者或群組所需資源的存取權。Using role-based access controls (RBAC), you can grant users or groups access to only the resources they need. 透過 Azure Kubernetes Service (AKS),您可以使用 Azure Active Directory 進一步加強安全性和權限結構。With Azure Kubernetes Service (AKS), you can further enhance the security and permissions structure by using Azure Active Directory. 這些方法可協助您保護應用程式工作負載和客戶資料。These approaches help you secure your application workloads and customer data.

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

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 authenticationFor 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-認證命令。To obtain a kubectl configuration context, a user can run the az aks get-credentials command. 當使用者之後透過 kubectl 與 AKS 叢集互動時,系統會提示他們使用其 Azure AD 認證登入。When a user then interacts with the AKS cluster with kubectl, they are 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.

AKS 叢集中的 Azure AD 驗證會使用 OpenID Connect (在 OAuth 2.0 通訊協定上方建置的身分識別層)。Azure AD authentication in AKS clusters uses OpenID Connect, an identity layer built on top of the OAuth 2.0 protocol. OAuth 2.0 會定義取得及使用存取權杖的機制,以存取受保護的資源,而 OpenID Connect 會實作驗證,以作為 OAuth 2.0 授權程序的延伸模組。OAuth 2.0 defines mechanisms to obtain and use access tokens to access protected resources, and OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. 如需 OpenID Connect 的詳細資訊, 請參閱OPEN ID connect 檔For more information on OpenID Connect, see the Open ID Connect documentation. 若要驗證透過 OpenID Connect 從 Azure AD 取得的驗證權杖,AKS 叢集會使用 Kubernetes Webhook 權杖驗證。To verify the authentication tokens obtained from Azure AD through OpenID Connect, AKS clusters use Kubernetes Webhook Token Authentication. 如需詳細資訊, 請參閱Webhook 權杖驗證檔For more information, see the Webhook Token Authentication documentation.

角色型存取控制 (RBAC)Role-based access controls (RBAC)

若要更細微地篩選使用者可以執行的動作,Kubernetes 會使用角色型存取控制 (RBAC)。To provide granular filtering of the actions that users can perform, Kubernetes uses role-based access controls (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.

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

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

另一個控制資源存取的機制是 Azure 角色型存取控制 (RBAC)。One additional mechanism for controlling access to resources is Azure role-based access controls (RBAC). Kubernetes RBAC 會用於處理您 AKS 叢集內的資源,而 Azure RBAC 會用於處理您 Azure 訂用帳戶內的資源。Kubernetes RBAC is designed to work on resources within your AKS cluster, and Azure RBAC is designed to work on resources within your Azure subscription. 透過 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 for a particular scope, which could be an individual resource, a resource group, or across the subscription.

如需詳細資訊, 請參閱什麼是 AZURE RBAC?For more information, see What is Azure RBAC?

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 is 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 使用者得到權限來執行叢集內動作的方式。If your AKS cluster integrates with Azure Active Directory, bindings are how those Azure AD users are granted permissions to perform actions within the cluster.

角色繫結會用來為指定命名空間指派角色。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.

後續步驟Next steps

若要開始使用 Azure AD 和 Kubernetes RBAC, 請參閱整合 Azure Active Directory 與 AKSTo get started with Azure AD and Kubernetes RBAC, see Integrate Azure Active Directory with AKS.

如需相關的最佳作法, 請參閱AKS 中驗證和授權的最佳做法For associated best practices, see Best practices for authentication and authorization in AKS.

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