Azure Kubernetes 服务 (AKS) 的访问和标识选项Access and identity options for Azure Kubernetes Service (AKS)

可通过不同的方式来对 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 服务 (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 中并由 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

可通过集成 Azure Active Directory (AD) 增强 AKS 群集的安全性。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. 随后在用户使用 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?

角色和 ClusterRoleRoles 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 are used to grant permissions within a namespace. 若需要针对整个群集或给定命名空间外的群集资源来授予权限,可以改用“ClusterRole”。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.

RoleBinding 和 ClusterRoleBindingRoleBindings 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. 若需要针对整个群集或给定命名空间外的群集资源来绑定角色,可以改用“ClusterRoleBinding”。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.


“Azure 支持”所采取的任何群集操作都是经用户同意,在名为 aks-support-rolebinding 的 Kubernetes“编辑”角色下执行的。Any cluster actions taken by Azure support are made with user consent under a built-in Kubernetes "edit" role of the name aks-support-rolebinding. 使用此角色,可以启用 AKS 支持来编辑群集配置和资源,以便对群集问题进行故障排除和诊断,但该角色不能修改权限,也不能创建角色或角色绑定。With this role AKS support is enabled to edit cluster configuration and resources to troubleshoot and diagnose cluster issues, but the role can not modify permissions nor create roles or role bindings. 仅在具有实时 (JIT) 访问权限的活动支持票证下启用角色访问。Role access is only enabled under active support tickets with just-in-time (JIT) access. 阅读并详细了解 AKS 支持策略Read more about AKS support policies.

后续步骤Next steps

若要开始使用 Azure AD 和 Kubernetes RBAC,请参阅将 Azure Active Directory 与 AKS 集成To 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: