有关 Azure Kubernetes 服务 (AKS) 中的身份验证和授权的最佳做法Best practices for authentication and authorization in Azure Kubernetes Service (AKS)

在 Azure Kubernetes 服务 (AKS) 中部署和维护群集时,需要实施相应的方法来管理对资源和服务的访问。As you deploy and maintain clusters in Azure Kubernetes Service (AKS), you need to implement ways to manage access to resources and services. 如果不采用这些控制措施,帐户可能会有权访问它们不需要访问的资源和服务。Without these controls, accounts may have access to resources and services they don't need. 此外,可能难以跟踪用于做出更改的凭据集。It can also be hard to track which set of credentials were used to make changes.

本最佳做法文章重点介绍群集操作员如何管理 AKS 群集的访问和标识。This best practices article focuses on how a cluster operator can manage access and identity for AKS clusters. 在本文中,学习如何:In this article, you learn how to:

  • 使用 Azure Active Directory 对 AKS 群集用户进行身份验证Authenticate AKS cluster users with Azure Active Directory
  • 使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 控制对资源的访问权限Control access to resources with Kubernetes role-based access control (Kubernetes RBAC)
  • 使用 Azure RBAC 大规模精细控制对 AKS 资源和 Kubernetes API 的访问权限,以及对 kubeconfig 的访问权限。Use Azure RBAC to granularly control access to the AKS resource and the Kubernetes API at scale, as well as to the kubeconfig.
  • 使用托管标识在其他服务中对 Pod 本身进行身份验证Use a managed identity to authenticate pods themselves with other services

使用 Azure Active DirectoryUse Azure Active Directory

最佳做法指导 - 使用 Azure AD 集成部署 AKS 群集。Best practice guidance - Deploy AKS clusters with Azure AD integration. 使用 Azure AD 可以集中化标识管理组件。Using Azure AD centralizes the identity management component. 访问 AKS 群集时,用户帐户或组状态的任何更改会自动更新。Any change in user account or group status is automatically updated in access to the AKS cluster. 根据下一部分所述,使用角色或群集角色和绑定,将用户或组的权限范围限定为所需的最少量权限。Use Roles or ClusterRoles and Bindings, as discussed in the next section, to scope users or groups to least amount of permissions needed.

Kubernetes 群集的开发人员和应用程序所有者需要访问不同的资源。The developers and application owners of your Kubernetes cluster need access to different resources. Kubernetes 不提供标识管理解决方案来控制哪些用户可与哪些资源交互。Kubernetes doesn't provide an identity management solution to control which users can interact with what resources. 通常,你会将群集与现有的标识解决方案相集成。Instead, you typically integrate your cluster with an existing identity solution. Azure Active Directory (AD) 提供企业就绪的标识管理解决方案,并可与 AKS 群集相集成。Azure Active Directory (AD) provides an enterprise-ready identity management solution, and can integrate with AKS clusters.

使用 AKS 中与 Azure AD 集成的群集,创建角色或群集角色用于定义对资源的访问权限。 With Azure AD-integrated clusters in AKS, you create Roles or ClusterRoles that define access permissions to resources. 然后,从 Azure AD 将角色绑定到用户或组。You then bind the roles to users or groups from Azure AD. 下一部分将介绍这些 Kubernetes 基于角色的访问控制 (Kubernetes RBAC)。These Kubernetes role-based access control (Kubernetes RBAC) are discussed in the next section. 下图显示了 Azure AD 集成,以及如何控制对资源的访问:The integration of Azure AD and how you control access to resources can be seen in the following diagram:

与 AKS 集成的 Azure Active Directory 的群集级身份验证

  1. 开发人员在 Azure AD 中进行验证身份。Developer authenticates with Azure AD.
  2. Azure AD 令牌颁发终结点颁发访问令牌。The Azure AD token issuance endpoint issues the access token.
  3. 开发人员使用 Azure AD 令牌执行操作,例如 kubectl create podThe developer does an action using the Azure AD token, such as kubectl create pod
  4. Kubernetes 使用 Azure Active Directory 验证令牌,并提取开发人员的组成员身份。Kubernetes validates the token with Azure Active Directory and fetches the developer's group memberships.
  5. 应用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 和群集策略。Kubernetes role-based access control (Kubernetes RBAC) and cluster policies are applied.
  6. 开发人员的请求成功或失败,具体取决于前面的 Azure AD 组成员身份和 Kubernetes RBAC 验证以及策略。Developer's request is successful or not based on previous validation of Azure AD group membership and Kubernetes RBAC and policies.

若要创建使用 Azure AD 的 AKS 群集,请参阅将 Azure Active Directory 与 AKS 集成To create an AKS cluster that uses Azure AD, see Integrate Azure Active Directory with AKS.

使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC)Use Kubernetes role-based access control (Kubernetes RBAC)

最佳做法指导 - 使用 Kubernetes RBAC 定义用户或组对群集中的资源拥有的权限。Best practice guidance - Use Kubernetes RBAC to define the permissions that users or groups have to resources in the cluster. 创建角色和绑定,用于分配所需的最少量权限。Create roles and bindings that assign the least amount of permissions required. 与 Azure AD 集成,使用户状态或组成员身份的任何更改可自动更新,并使群集资源访问权限保持最新状态。Integrate with Azure AD so any change in user status or group membership is automatically updated and access to cluster resources is current.

在 Kubernetes 中,可以针对群集中的资源提供精细的访问控制。In Kubernetes, you may provide granular control of access to resources in the cluster. 在群集级别或者针对特定的命名空间定义权限。Permissions are defined at the cluster level, or to specific namespaces. 可以定义能够使用哪些权限管理哪些资源。You can define what resources can be managed, and with what permissions. 然后,将这些角色通过绑定应用于用户或组。These roles are then applied to users or groups with a binding. 有关角色、群集角色和绑定的详细信息,请参阅 Azure Kubernetes 服务 (AKS) 的访问和标识选项For more information about Roles, ClusterRoles, and Bindings, see Access and identity options for Azure Kubernetes Service (AKS).

例如,可以创建一个角色,用于授予对名为 finance-app 的命名空间中的资源的完全访问权限,如以下示例 YAML 清单中所示:As an example, you can create a Role that grants full access to resources in the namespace named finance-app, as shown in the following example YAML manifest:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

然后创建 RoleBinding,用于将 Azure AD 用户 developer1@contoso.com 绑定到该 RoleBinding,如以下 YAML 清单所示:A RoleBinding is then created that binds the Azure AD user developer1@contoso.com to the RoleBinding, as shown in the following YAML manifest:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

developer1@contoso.com 通过 AKS 群集进行身份验证后,便对 finance-app 命名空间中的资源拥有了完全权限。When developer1@contoso.com is authenticated against the AKS cluster, they have full permissions to resources in the finance-app namespace. 这样,即可以逻辑方式隔离和控制对资源的访问权限。In this way, you logically separate and control access to resources. 应根据上一部分中所述,将 Kubernetes RBAC 与 Azure AD 集成结合使用。Kubernetes RBAC should be used in conjunction with Azure AD-integration, as discussed in the previous section.

若要了解如何使用 Azure AD 组通过 Kubernetes RBAC 来控制对 Kubernetes 资源的访问,请参阅在 AKS 中使用基于角色的访问控制和 Azure Active Directory 标识来控制对群集资源的访问To see how to use Azure AD groups to control access to Kubernetes resources using Kubernetes RBAC, see Control access to cluster resources using role-based access control and Azure Active Directory identities in AKS.

使用 Azure RBACUse Azure RBAC

最佳做法指导 - 使用 Azure RBAC 来定义用户或组对一个或多个订阅中 AKS 资源拥有的所需最低权限。Best practice guidance - Use Azure RBAC to define the minimum required permissions that users or groups have to AKS resources in one or more subscriptions.

完全操作 AKS 群集需要两个级别的访问权限:There are two levels of access needed to fully operate an AKS cluster:

  1. 访问 Azure 订阅上的 AKS 资源。Access the AKS resource on your Azure subscription. 具有此访问级别,可以使用 AKS API 来控制群集的缩放或升级,还可以拉取 kubeconfig。This access level allows you to control things scaling or upgrading your cluster using the AKS APIs as well as pull your kubeconfig. 要查看如何控制对 AKS 资源和 kubeconfig 的访问权限,请参阅限制对群集配置文件的访问To see how to control access to the AKS resource and the kubeconfig, see Limit access to cluster configuration file.

  2. 访问 Kubernetes API。Access to the Kubernetes API. 此访问级别可通过 Kubernetes RBAC(传统上)进行控制,或通过将 Azure RBAC 与 AKS 集成以实现 Kubernetes 授权来进行控制。This access level is controlled either by Kubernetes RBAC (traditionally) or by integrating Azure RBAC with AKS for kubernetes authorization.

使用 pod 标识Use pod identities

最佳做法指导 - 不要在 pod 或容器映像中使用固定的凭据,因为它们存在泄漏或滥用的风险。Best practice guidance - Don't use fixed credentials within pods or container images, as they are at risk of exposure or abuse. 应该使用 pod 标识通过中心 Azure AD 标识解决方案来自动请求访问权限。Instead, use pod identities to automatically request access using a central Azure AD identity solution. Pod 标识仅适用于 Linux Pod 和容器映像。Pod identities are intended for use with Linux pods and container images only.

当 pod 需要访问其他 Azure 服务(例如 Cosmos DB、Key Vault 或 Blob 存储)时,pod 需要访问凭据。When pods need access to other Azure services, such as Cosmos DB, Key Vault, or Blob Storage, the pod needs access credentials. 可以使用容器映像定义这些访问凭据或将其注入为 Kubernetes 机密,但需要手动创建并分配这些凭据。These access credentials could be defined with the container image or injected as a Kubernetes secret, but need to be manually created and assigned. 通常,凭据会在不同的 pod 之间重复使用,并且不会定期轮换。Often, the credentials are reused across pods, and aren't regularly rotated.

使用 Azure 资源的托管标识(目前作为关联的 AKS 开源项目来实现)可以通过 Azure AD 自动请求服务访问权限。Managed identities for Azure resources (currently implemented as an associated AKS open source project) let you automatically request access to services through Azure AD. 不要手动定义 pod 的凭据。pod 会实时请求访问令牌,并可以使用该令牌来访问仅为它们分配的服务。You don't manually define credentials for pods, instead they request an access token in real time, and can use it to access only their assigned services. 在 AKS 中,群集操作员会部署两个组件,以允许 pod 使用托管标识:In AKS, two components are deployed by the cluster operator to allow pods to use managed identities:

  • 节点管理标识 (NMI) 服务器 是在 AKS 群集中每个节点上作为守护程序集运行的 pod。The Node Management Identity (NMI) server is a pod that runs as a DaemonSet on each node in the AKS cluster. NMI 服务器侦听发送到 Azure 服务的 pod 请求。The NMI server listens for pod requests to Azure services.
  • 托管标识控制器 (MIC) 是一个中心 pod,它有权查询 Kubernetes API 服务器,并检查对应于某个 pod 的 Azure 标识映射。The Managed Identity Controller (MIC) is a central pod with permissions to query the Kubernetes API server and checks for an Azure identity mapping that corresponds to a pod.

当 pod 请求 Azure 服务访问权限时,网络规则会将流量重定向到节点管理标识 (NMI) 服务器。When pods request access to an Azure service, network rules redirect the traffic to the Node Management Identity (NMI) server. NMI 服务器根据远程地址识别请求 Azure 服务访问权限的 pod,并查询托管标识控制器 (MIC)。The NMI server identifies pods that request access to Azure services based on their remote address, and queries the Managed Identity Controller (MIC). MIC 检查 AKS 群集中的 Azure 标识映射,然后,NMI 服务器根据 pod 的标识映射从 Azure Active Directory (AD) 请求访问令牌。The MIC checks for Azure identity mappings in the AKS cluster, and the NMI server then requests an access token from Azure Active Directory (AD) based on the pod's identity mapping. Azure AD 提供对 NMI 服务器的访问权限,该访问权限将返回给 pod。Azure AD provides access to the NMI server, which is returned to the pod. 然后,pod 可以使用此访问令牌请求对 Azure 中服务的访问权限。This access token can be used by the pod to then request access to services in Azure.

在以下示例中,开发人员创建使用托管标识请求 Azure SQL 数据库访问权限的 Pod:In the following example, a developer creates a pod that uses a managed identity to request access to Azure SQL Database:

pod 标识可让 pod 自动请求对其他服务的访问权限

  1. 群集操作员首先创建一个服务帐户,当 pod 请求服务访问权限时,可以使用该帐户来映射标识。Cluster operator first creates a service account that can be used to map identities when pods request access to services.
  2. 部署 NMI 服务器和 MIC,以便将访问令牌的任何 pod 请求中继到 Azure AD。The NMI server and MIC are deployed to relay any pod requests for access tokens to Azure AD.
  3. 开发人员使用托管标识部署一个 pod,该 pod 可通过 NMI 服务器请求访问令牌。A developer deploys a pod with a managed identity that requests an access token through the NMI server.
  4. 该令牌将返回给 Pod,并用于访问 Azure SQL 数据库The token is returned to the pod and used to access Azure SQL Database

备注

托管 Pod 标识是开源项目,Azure 技术支持部门不为其提供支持。Managed pod identities is an open source project, and is not supported by Azure technical support.

若要使用 Pod 标识,请参阅 Kubernetes 应用程序的 Azure Active Directory 标识To use pod identities, see Azure Active Directory identities for Kubernetes applications.

后续步骤Next steps

本最佳做法文章重点介绍了群集和资源的身份验证与授权。This best practices article focused on authentication and authorization for your cluster and resources. 若要实施其中的某些最佳做法,请参阅以下文章:To implement some of these best practices, see the following articles:

有关 AKS 中的群集操作的详细信息,请参阅以下最佳做法:For more information about cluster operations in AKS, see the following best practices: