Compartir a través de

有关 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 授权

后续步骤

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

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