你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

有关 Azure Kubernetes 服务 (AKS) 中的身份验证和授权的最佳做法

在 Azure Kubernetes 服务 (AKS) 中部署和维护群集时,需要实施相应的方法来管理对资源和服务的访问。 如果没有这些控件:

  • 帐户可以访问不必要的资源和服务。
  • 跟踪用于执行更改的凭据可能很困难。

在本文中,我们将讨论群集操作员可以遵循哪些建议的做法来管理 AKS 群集的访问和标识。 将了解如何执行以下操作:

  • 使用 Microsoft Entra ID 对 AKS 群集用户进行身份验证。
  • 使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 控制对资源的访问权限。
  • 使用 Azure RBAC 大规模精确控制对 AKS 资源和 Kubernetes API 的访问权限,以及对 kubeconfig 的访问权限。
  • 使用工作负载标识从 Pod 访问 Azure 资源。

警告

Azure Kubernetes 服务中的开源 Microsoft Entra Pod 托管标识(预览版)已于 2022 年 10 月 24 日弃用。

如果在 AKS 群集上启用了 Microsoft Entra Pod 托管标识或正在考虑实现该标识,建议查看工作负载标识概观文章,了解建议和选项,以便将群集设置为使用 Microsoft Entra Workload ID(预览)。 此身份验证方法将替代 pod 托管标识(预览),后者与 Kubernetes 本机功能集成,以便与任何外部标识提供者联合。

使用 Microsoft Entra ID

最佳实践指南

使用 Microsoft Entra 集成部署 AKS 群集。 使用 Microsoft Entra ID 可以集中处理标识管理层。 访问 AKS 群集时,用户帐户或组状态的任何更改会自动更新。 使用角色、群集角色或绑定将用户或组范围限制为最小权限量。

Kubernetes 群集的开发人员和应用程序所有者需要访问不同的资源。 Kubernetes 缺少一个标识管理解决方案,无法让你控制用户可与之交互的资源。 相反,可以将群集与现有标识解决方案集成,例如企业就绪标识管理解决方案 Microsoft Entra ID。

通过 AKS 中与 Microsoft Entra 集成的群集,可以创建可定义对资源的访问权限的“角色”或“ClusterRoles”。 然后将角色绑定到 Microsoft Entra ID 中的用户或组。 在下一节中详细了解这些 Kubernetes RBAC。 下图显示了 Microsoft Entra 集成,以及如何控制对资源的访问:

Cluster-level authentication for Microsoft Entra integration with AKS

  1. 开发人员可使用 Microsoft Entra ID 进行身份验证。
  2. Microsoft Entra 令牌颁发终结点会颁发访问令牌。
  3. 开发人员可使用 Microsoft Entra 令牌执行操作,例如 kubectl create pod
  4. Kubernetes 使用 Microsoft Entra 验证令牌,并提取开发人员的组成员身份。
  5. 同时应用了 Kubernetes RBAC 和群集策略。
  6. 开发人员的请求成功与否取决于上述 Microsoft Entra 组成员身份的验证结果以及 Kubernetes RBAC 和策略。

要创建使用 Microsoft Entra ID 的 AKS 群集,请参阅《将 Microsoft Entra ID 与 AKS 集成》。

使用 Kubernetes 基于角色的访问控制 (Kubernetes RBAC)

最佳实践指南

使用 Kubernetes RBAC 定义用户或组对群集资源的权限。 创建角色和绑定,用于分配所需的最少量权限。 与 Microsoft Entra 集成,以自动更新任何用户状态或组成员身份更改,并保持对群集资源的访问权限处于最新状态。

在 Kubernetes 中,可以提供对群集资源的精确访问控制。 在群集级别或针对特定命名空间定义权限。 确定可使用哪些权限管理哪些资源。 然后,将这些角色应用到具有绑定的用户或组。 有关角色、群集角色和绑定的详细信息,请参阅 Azure Kubernetes 服务 (AKS) 的访问和标识选项

例如,可以创建一个角色,为其授予对“finance-app”命名空间所含资源的完整访问权限,如以下示例 YAML 清单中所示:

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

然后创建一个 RoleBinding 并为其绑定 Microsoft Entra 用户 developer1@contoso.com,如以下 YAML 清单中所示:

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 命名空间中的资源拥有了完全权限。 这样,即可以逻辑方式隔离和控制对资源的访问权限。 将 Kubernetes RBAC 与 Microsoft Entra ID 集成配合使用。

要了解如何使用 Microsoft Entra 组来通过 Kubernetes RBAC 来控制对 Kubernetes 资源的访问,请参阅《在 AKS 中使用基于角色的访问控制和 Microsoft Entra 标识来控制对群集资源的访问》。

使用 Azure RBAC

最佳实践指南

使用 Azure RBAC 来定义用户或组对一或多个订阅中 AKS 资源所需拥有的最低权限。

完全操作 AKS 群集需要两个级别的访问权限:

  • 访问 Azure 订阅上的 AKS 资源。

    此访问级别允许:

    • 使用 AKS API 控制对群集的扩展或升级
    • 请求 kubeconfig

    若要了解如何控制对 AKS 资源和 kubeconfig 的访问权限,请参阅限制对群集配置文件的访问

  • 访问 Kubernetes API。

    此访问级别由以下其中之一控制:

    • KUBERNETES RBAC(传统做法)或
    • 通过将 Azure RBAC 与 AKS 集成以实现 Kubernetes 授权。

    若要了解如何使用 Azure RBAC 向 Kubernetes API 精确授予权限,请参阅使用 Azure RBAC 进行 Kubernetes 授权

使用 Pod 托管标识

警告

Azure Kubernetes 服务中的开源 Microsoft Entra Pod 托管标识(预览版)已于 2022 年 10 月 24 日弃用。

如果在 AKS 群集上启用了 Microsoft Entra Pod 托管标识或正在考虑实现该标识,建议查看工作负载标识概观文章,了解建议和选项,以便将群集设置为使用 Microsoft Entra Workload ID(预览)。 此身份验证方法将替代 pod 托管标识(预览),后者与 Kubernetes 本机功能集成,以便与任何外部标识提供者联合。

不要在 Pod 或容器映像中使用固定的凭据,因为它们存在泄漏或滥用的风险。 请改用 Pod 标识以通过 Microsoft Entra ID 来自动请求访问权限。

Pod 需要身份验证凭据,才可访问其他 Azure 资源(例如 Azure Cosmos DB、Key Vault 或 Blob 存储)。 可以使用容器映像定义身份验证凭据,或将其作为 Kubernetes 密码插入。 无论采用哪种方式,都需要手动创建和分配这些凭据。 这些凭据通常会在不同的 Pod 之间重复使用,并且不会定期轮换。

使用 Azure 资源的 Pod 托管标识(预览),可通过 Microsoft Entra ID 自动请求对服务的访问权限。 Pod 托管标识目前可在 AKS 预览中查看。 要开始使用,请参阅《在 Azure Kubernetes 服务中使用 Microsoft Entra Pod 托管标识(预览)》文档。

Microsoft Entra Pod 托管标识(预览版)支持两种操作模式:

  • 标准模式:在此模式下,将以下 2 个组件部署到 AKS 群集:

    • 托管标识控制器 (MIC):一种 Kubernetes 控制器,通过 Kubernetes API 服务器监视对 Pod、AzureIdentityAzureIdentityBinding 所做的更改。 检测到相关更改时,MIC 会根据需要添加或删除 AzureAssignedIdentity。 具体而言,如果计划了 Pod,MIC 会将 Azure 上的托管标识分配给节点池在创建阶段使用的基础虚拟机规模集。 删除所有使用该标识的 Pod 时,MIC 会从节点池的虚拟机规模集中删除标识,除非其他 Pod 使用相同的托管标识。 创建或删除 AzureIdentity 或 AzureIdentityBinding 时,MIC 会执行类似的操作。

    • 节点托管标识 (NMI):是在 AKS 群集中每个节点上作为 DaemonSet 运行的 Pod。 NMI 会拦截对每个节点上的 Azure 实例元数据服务的安全令牌请求。 它会将请求重定向到自身并验证 Pod 是否有权访问它为其请求令牌的标识,并代表应用程序从 Microsoft Entra 租户中提取令牌。

  • 托管模式:在此模式下,只有 NMI。 标识需要由用户手动分配和管理。 有关详细信息,请参阅托管模式下的 Pod 标识。 在此模式下,使用 az aks pod-identity add 命令将 Pod 标识添加到 Azure Kubernetes 服务 (AKS) 群集时,它会在 --namespace 参数指定的命名空间创建 AzureIdentityAzureIdentityBinding,而 AKS 资源提供程序将 --identity-resource-id 参数指定的托管标识分配给 AKS 群集中每个节点池的虚拟机规模集。

注意

如果决定改为使用 AKS 群集加载项安装 Microsoft Entra Pod 托管标识,安装程序将使用 managed 模式。

standard模式相比,managed模式具备以下优点:

  • 节点池虚拟机规模集上的标识分配可能需要 40-60 秒。 对于需要访问标识且不能接受分配延迟的定时任务或应用程序,最好使用 managed 模式,因为标识已经预先分配给了节点池的虚拟机规模集。 请手动执行操作或使用 az aks pod-identity add 命令。
  • standard 模式下,MIC 要求对 AKS 群集使用的虚拟机规模集具有写入权限和对用户分配的托管标识的 Managed Identity Operator 权限。 在 managed mode 下运行时,由于没有 MIC,因此不需要角色分配。

Pod 托管标识不会手动定义 Pod 凭据,而是会实时请求访问令牌,并使用该令牌访问仅为它们分配的资源。 在 AKS 中,有两个组件处理操作,以便 Pod 使用托管标识:

  • 节点管理标识 (NMI) 服务器是在 AKS 群集中每个节点上作为守护程序集运行的 pod。 NMI 服务器侦听发送到 Azure 服务的 pod 请求。
  • Azure 资源提供程序查询 Kubernetes API 服务器,并检查是否有与 Pod 相对应的 Azure 标识映射。

当 Pod 从 Microsoft Entra ID 请求安全令牌以访问 Azure 资源时,网络规则会将流量重定向到 NMI 服务器。

  1. NMI 服务器:

    • 根据远程地址请求访问 Azure 资源的 Pod 标识。
    • 查询 Azure 资源提供程序。
  2. Azure 资源提供程序会检查 AKS 群集中的 Azure 标识映射。

  3. NMI 服务器将根据 Pod 的标识映射从 Microsoft Entra ID 请求访问令牌。

  4. Microsoft Entra 会提供对 NMI 服务器的访问权限,然后该权限将返回给 pod。

    • 然后,pod 可以使用此访问令牌请求对 Azure 中资源的访问权限。

在以下示例中,开发人员创建使用托管标识请求 Azure SQL 数据库访问权限的 Pod:

Pod identities allow a pod to automatically request access to other resources.

  1. 当 Pod 请求访问资源时,群集运算符会创建一个服务帐户来映射标识。
  2. NMI 服务器与 Azure 资源提供程序一起部署,以将任何对访问令牌的 Pod 请求中继到 Microsoft Entra ID。
  3. 开发人员使用托管标识部署一个 pod,该 pod 可通过 NMI 服务器请求访问令牌。
  4. 该令牌将返回给 Pod,并用于访问 Azure SQL 数据库

要使用 Pod 托管标识,请参阅《在 Azure Kubernetes 服务中使用 Microsoft Entra Pod 托管标识(预览)

后续步骤

本最佳做法文章重点介绍了群集和资源的身份验证与授权。 若要实施其中的某些最佳做法,请参阅以下文章:

有关 AKS 中的群集操作的详细信息,请参阅以下最佳做法: