Azure Arc 启用的 AKS 的访问和标识选项

项目
08/01/2024

适用于：Azure 本地版本 23H2 上的 AKS

可以通过多种方式对 Kubernetes 群集进行身份验证、授权、保护和控制对 Kubernetes 群集的访问：

使用 Kubernetes 基于角色的访问控制（Kubernetes RBAC），可以授予用户、组和服务帐户仅访问所需的 Kubernetes 资源的访问权限。
使用 Azure RBAC 启用 AKS 群集后，可以使用 Microsoft Entra ID 和 Azure RBAC 进一步增强安全性和权限结构。

Kubernetes RBAC 和 Azure RBAC 可帮助你保护群集访问权限，并仅向开发人员和操作员提供所需的最低权限。

本文介绍了有助于在 AKS 中进行身份验证和分配权限的核心概念。

Kubernetes RBAC

Kubernetes RBAC 提供对用户操作的精细筛选。借助此控制机制：

可向用户或用户组分配权限来创建和修改资源，或者查看正在运行的应用程序工作负载的日志。
可将这些权限的范围限制为单个命名空间，也可面向整个 AKS 群集。
可创建角色来定义权限，然后通过角色绑定将这些角色分配给用户。

有关详细信息，请参阅使用 Kubernetes RBAC 授权。

角色和 ClusterRole

角色

在使用 Kubernetes RBAC 向用户分配权限之前，请将用户权限定义为角色。使用角色授予 Kubernetes 命名空间中的权限。

Kubernetes 角色可授予权限，它们不会拒绝权限。若要向整个群集或给定命名空间外部的群集资源授予权限，可以使用 ClusterRoles。

ClusterRole

ClusterRole 可授予权限并将权限应用于整个群集中的资源，而不是特定命名空间。

RoleBinding 和 ClusterRoleBinding

定义角色以向资源授予权限后，可以使用 RoleBinding 分配这些 Kubernetes RBAC 权限。如果 AKS 群集与 Microsoft Entra ID 集成，RoleBinding 会向 Microsoft Entra 用户授予权限来在群集中执行操作。请参阅使用 Microsoft Entra ID 和 Kubernetes RBAC 控制访问

RoleBinding

针对给定命名空间，使用 RoleBinding 向用户分配角色。借助 RoleBinding，可从逻辑上分离各 AKS 群集，使用户只能访问向其分配的命名空间中的应用程序资源。

若要在整个群集中绑定角色，或绑定到给定命名空间之外的群集资源，请使用 ClusterRoleBindings。

ClusterRoleBinding

通过 ClusterRoleBinding，可将角色绑定到用户，并应用于整个群集中的资源，而不是特定命名空间。使用此方法，可向管理员或支持工程师授予对 AKS 群集中所有资源的访问权限。

Kubernetes 服务帐户

服务帐户是 Kubernetes 中的主要用户类型之一。 Kubernetes API 保存和管理服务帐户。服务帐户凭据存储为 Kubernetes 机密，允许授权 Pod 使用这些凭据与 API 服务器通信。大多数 API 请求都会提供服务帐户或普通用户帐户的身份验证令牌。

普通用户帐户允许人工管理员或开发人员进行更为传统的访问，而不仅仅是服务和进程。尽管 Kubernetes 没有提供用于存储常规用户帐户和密码的标识管理解决方案，但你可将外部标识解决方案集成到 Kubernetes 中。对于 AKS 群集，这种集成的标识解决方案就是 Microsoft Entra ID。

有关 Kubernetes 中的标识选项的详细信息，请参阅 Kubernetes 身份验证。

Azure 基于角色的访问控制

Azure 基于角色的访问控制（RBAC）是基于 Azure 资源管理器构建的授权系统，可提供对 Azure 资源的精细访问管理。

RBAC 系统	说明
Kubernetes RBAC	旨在处理 AKS 群集中的 Kubernetes 资源。
Azure RBAC	旨在处理 Azure 订阅中的资源。

使用 Azure RBAC，可创建“角色定义”，描述要应用的权限。然后，可通过特定范围的角色分配为用户或组分配此角色定义。范围可以是单个资源、资源组或整个订阅。

有关详细信息，请参阅什么是 Azure 基于角色的访问控制 (Azure RBAC)？

若要完全运行 AKS Arc 群集，需要两个级别的访问：

访问 Azure 订阅中的 AKS 资源。
- 使用 Azure Arc API 启用的 AKS 控制缩放或升级群集。
- 拉取管理员基于证书的 kubeconfig。
- 拉取已启用 Entra ID 的 kubeconfig。
访问 Kubernetes API。此访问权限由以下项控制：
- Kubernetes RBAC 或
- 将 Azure RBAC 与 AKS 集成以进行 Kubernetes 授权。

使用 Azure RBAC 授予对 AKS 资源的访问权限

使用 Azure RBAC，可为用户（或标识）提供对一个或多个订阅中的 AKS 资源的精细访问权限。此控制平面操作有三个角色：Azure Kubernetes 服务 Arc 群集管理员角色、Azure Kubernetes 服务 Arc 群集用户角色和Azure Kubernetes 服务 Arc 参与者角色。每个角色都具有不同的权限范围，如用于容器的 Azure 内置角色中所述。例如，可以使用 Azure Kubernetes 服务 Arc 参与者角色创建、缩放和升级群集。同时，具有 Azure Kubernetes 服务 Arc 群集管理员角色的另一个用户仅有权拉取管理员 kubeconfig。

Azure RBAC 用于 Kubernetes 授权

通过 Azure RBAC 集成，AKS 使用 Kubernetes 授权 Webhook 服务器，以便可以使用 Azure 角色定义和角色分配来管理 Microsoft Entra 集成的 Kubernetes 群集资源权限和分配。

如图所示，使用 Azure RBAC 集成时，对 Kubernetes API 的所有请求都遵循与 Microsoft Entra 集成中所述相同的身份验证流。

如果发出请求的标识存在于 Microsoft Entra ID 中，则具有 Kubernetes RBAC 的 Azure 团队授权请求。如果标识存在于 Microsoft Entra ID（例如 Kubernetes 服务帐户）之外，授权将延迟到正常的 Kubernetes RBAC。

在这种情形下，请使用 Azure RBAC 机制和 API 来分配用户内置角色或创建自定义角色，就像在使用 Kubernetes 角色时一样。

使用此功能，不仅可为用户提供跨订阅的 AKS 资源权限，还可在每个控制 Kubernetes API 访问权限的群集中配置角色和权限。有四个内置角色可用于此数据平面操作，每个角色都有自己的权限范围，如内置角色部分中所述。

重要

在执行角色分配之前，必须为 Kubernetes 授权启用 Azure RBAC。有关更多详细信息和分步指南，请参阅使用 Azure RBAC 进行 Kubernetes 授权。

内置角色

Arc 启用的 AKS 提供以下五个内置角色。它们与 Kubernetes 内置角色类似，但存在一些差异，例如支持 CRD。请查看每个 Azure内置角色允许的操作的完整列表。

角色	说明
已启用 Azure Arc 的 Kubernetes 群集用户	允许检索基于群集 Connect 的 kubeconfig 文件，以便从任何位置管理群集。
Azure Arc Kubernetes 查看者	允许进行只读访问并查看命名空间中的大多数对象。不允许查看机密，因为对机密的读取权限允许访问命名空间中的 ServiceAccount 凭据。这些凭据反过来又允许通过 ServiceAccount 值（特权升级形式）进行 API 访问。
Azure Arc Kubernetes 写入者	允许对命名空间中的大多数对象进行读/写访问。不允许查看或修改角色或角色绑定。但是，此角色允许以命名空间中的任何 ServiceAccount 值的形式访问机密和运行 Pod，因此可用于获取命名空间中任何此类 ServiceAccount 值的 API 访问级别。
Azure Arc Kubernetes 管理员	授予管理员访问权限。它旨在通过 RoleBinding 在命名空间中授予。如果在 RoleBinding 中使用，则允许对命名空间中的大多数资源进行读/写访问，包括能够在命名空间中创建角色和角色绑定。此角色不允许对资源配额或命名空间本身进行写入访问。
Azure Arc Kubernetes 群集管理员	允许“超级用户”访问对任何资源执行任何操作。在 ClusterRoleBinding 中使用时，它会完全控制群集和所有命名空间中的每个资源。在 RoleBinding 中使用时，它会完全控制角色绑定命名空间中的每个资源，包括命名空间本身。

Microsoft Entra 集成

通过 Microsoft Entra 集成增强 AKS 群集安全性。基于企业标识管理体验，Microsoft Entra ID 是一种多租户的基于云的目录和标识管理服务，它结合了核心目录服务、应用程序访问管理和标识保护。借助 Microsoft Entra ID，可以将本地标识集成到 AKS 群集中，提供帐户管理和安全性的单一源。

使用 Microsoft Entra 集成的 AKS 群集，可以授予用户或组对命名空间内或跨群集的 Kubernetes 资源的访问权限。

若要获取 kubectl 配置上下文，请运行 az aksarc get-credentials 命令。
当用户使用 kubectl 与 AKS 群集交互时，系统会提示他们使用其Microsoft Entra 凭据登录。

此方法提供用户帐户管理和密码凭据的单一源。用户只能访问 Kubernetes 群集管理员定义的资源。

Microsoft使用 OpenID Connect 向 AKS 群集提供 Entra 身份验证。 OpenID Connect 是构建在 OAuth 2.0 协议顶层的标识层。有关 OpenID Connect 的详细信息，请参阅 OpenID Connect 文档。在 Kubernetes 群集内部， Webhook 令牌身份验证用于验证身份验证令牌。 Webhook 令牌身份验证作为 AKS 群集的一部分进行配置和管理。

总结

下表汇总了启用 Microsoft Entra 集成时用户如何向 Kubernetes 进行身份验证。在所有情况下，命令序列为：

运行 az login 以向 Azure 进行身份验证。
运行 az aksarc get-credentials 以将 Kubernetes 群集的凭据下载到 .kube/config。
运行 kubectl 命令。
- 第一个命令可以触发基于浏览器的身份验证以向 Kubernetes 群集进行身份验证，如下表所述。

说明	需要的角色授予	群集管理员Microsoft Entra 组	使用时机
使用客户端证书进行管理员登录	Azure Kubernetes 服务 Arc 群集管理员角色。此角色允许 `az aksarc get-credentials` 与标志一起使用 `--admin` ，该标志将非Microsoft Entra 群集管理员证书下载到用户的 .kube/config 中。这是 Azure Kubernetes 管理员角色的唯一用途。	不适用	如果你被永久阻止，不能访问对你的群集具有访问权限的有效 Microsoft Entra 组。
使用手动角色绑定Microsoft Entra ID	Azure Kubernetes 服务 Arc 群集用户角色。用户角色允许`az aksarc get-credentials`在没有标志的情况下`--admin`使用。这是Azure Kubernetes 服务群集用户角色的唯一用途。在启用了 entra ID 的群集Microsoft，结果是将空条目下载到 .kube/config 中，该条目在 kubectl 首次使用时触发基于浏览器的身份验证。	由于用户不在任何群集管理员组中，因此其权限完全由群集管理员设置的任何 RoleBindings 或 ClusterRoleBinding 控制。（群集） RoleBindings 提名Microsoft Entra 用户或Microsoft Entra 组作为主题。如果未设置此类绑定，则用户无法执行任何 kubectl 命令。	如果你想要进行精细的访问控制，并且不使用 Azure RBAC 进行 Kubernetes 授权。请注意，设置绑定的用户必须使用此表中列出的其他方法之一登录。
按群集管理员Microsoft Entra 组的成员Microsoft Entra ID（在 Azure CLI 中使用 `--aad-admin-group-object-ids` 标志设置）	与前面相同。	用户是此处列出的其中一个组的成员。 AKS 会自动生成一个 ClusterRoleBinding，后者将所有列出的组绑定到 `cluster-admin` Kubernetes 角色。因此，这些组中的用户可以作为 `cluster-admin` 运行所有 `kubectl` 命令。	如果想要授予用户完全管理员权限，并且不使用 Azure RBAC 进行 Kubernetes 授权。
使用用于 Kubernetes 授权的 Azure RBAC Microsoft Entra ID	两个角色： Azure Kubernetes 服务 Arc 群集用户角色（如前所述）。前面所述的 Azure Arc Kubernetes 角色之一，或你自己的自定义替代角色之一。	启用用于 Kubernetes 授权的 Azure RBAC 时，“配置”选项卡上的“管理员角色”字段无关。	使用 Azure RBAC 进行 Kubernetes 授权。此方法提供了精细的控制，无需设置 RoleBinding 或 ClusterRoleBinding。

后续步骤

若要开始使用 Kubernetes RBAC 进行 Kubernetes 授权，请参阅使用 Microsoft Entra ID 和 Kubernetes RBAC 控制访问
若要开始使用用于 Kubernetes 授权的 Azure RBAC，请参阅使用 Azure RBAC 进行 Kubernetes 授权

通过