使用 Microsoft Entra ID 和 Kubernetes RBAC 控制访问

适用于：Azure Local 上的 AKS

可以将 Azure Kubernetes 服务（AKS）配置为使用 Microsoft Entra ID 进行用户身份验证。 在此配置中，将使用 Microsoft Entra 身份验证令牌登录到 Kubernetes 群集。 经过身份验证后，可以根据用户标识或组成员身份使用内置 Kubernetes 基于角色的访问控制 (Kubernetes RBAC) 来管理对命名空间和群集资源的访问权限。

本文介绍如何基于 AKS 中的 Microsoft Entra 组成员身份在 Kubernetes 群集中使用 Kubernetes RBAC 来控制访问。 在 Microsoft Entra ID 中创建演示组和用户。 然后，在群集中创建角色和角色绑定，以授予创建和查看资源的适当权限。

先决条件

在使用 Microsoft Entra ID 设置 Kubernetes RBAC 之前，必须具备以下先决条件：

• Azure Arc 群集启用的 AKS。 如果需要设置群集，请参阅有关使用 Azure 门户 或 Azure CLI 的说明。
• 已安装并配置 Azure CLI。 如果需要安装 CLI 或升级，请参阅 “安装 Azure CLI”。
• Azure CLI 和 connectedk8s 扩展。 Azure 命令行接口 (Azure CLI) 是一组用来创建和管理 Azure 资源的命令。 若要检查是否具有 Azure CLI，请打开命令行工具，然后键入： az -v 此外，安装 connectedk8s 扩展，以便打开 Kubernetes 群集的通道。 有关安装说明，请参阅 如何安装 Azure CLI。
• Kubectl。 使用 Kubernetes 命令行工具 kubectl 可以运行面向 Kubernetes 群集的命令。 若要检查是否已安装 kubectl，请打开命令行工具，然后键入： kubectl version --client 请确保您的 kubectl 客户端版本至少为 v1.24.0。 有关安装说明，请参阅 kubectl。
• 可以使用具有直接模式或代理模式的指定权限访问 Kubernetes 群集。
  • 若要直接使用 az aksarc get-credentials 命令访问 Kubernetes 群集，需要 Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action，该作包含在 Azure Kubernetes 服务 Arc 群集用户 角色权限中
  • 若要从任何位置使用 az connectedk8s proxy 命令通过代理模式访问 Kubernetes 群集，需要 Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action，该作包含在 已启用 Azure Arc 的 Kubernetes 群集用户 角色权限中。 同时，需要验证执行载入过程的代理和计算机是否满足 已启用 Azure Arc 的 Kubernetes 网络要求中的网络要求。

注释

将 kubelogin 版本 2.0 及更高版本与 Azure 本地 AKS 中的 Microsoft Entra 身份验证和 Kubernetes RBAC 配合使用时，可能会遇到运行的每个命令的 Entra 身份验证提示。 有关此已知问题的解决方案，请参阅 使用 Kubernetes RBAC 运行 kubectl 时重复的 Entra 身份验证提示。

可选第一步

如果还没有包含成员的 Microsoft Entra 组，则可能需要创建一个组并添加一些成员，以便可以按照本文中的说明进行作。

若要演示如何使用 Microsoft Entra ID 和 Kubernetes RBAC，可以为应用程序开发人员创建一个Microsoft Entra 组，该组可用于显示 Kubernetes RBAC 和 Microsoft Entra ID 控制对群集资源的访问。 在生产环境中，可以使用 Microsoft Entra 租户中的现有用户和组。

在 Microsoft Entra ID 中创建演示组

首先，使用 az ad group create 命令在租户中为应用程序开发人员在 Microsoft Entra ID 中创建一个组。 以下示例提示登录到 Azure 租户，然后创建名为 appdev 的组：

az login
az ad group create --display-name appdev --mail-nickname appdev

将用户添加到你的组

使用为应用程序开发人员在 Microsoft Entra ID 中创建的示例组后，将用户添加到该 appdev 组。 使用此用户帐户登录到 AKS 群集并测试 Kubernetes RBAC 集成。

使用命令将用户添加到在上一节中创建的az ad group member add组。 如果退出 Azure 会话，请使用 az login 重新连接到 Azure。

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

在 Microsoft Entra 组的 AKS 群集资源上创建自定义 Kubernetes RBAC 角色绑定

配置 AKS 群集以允许Microsoft Entra 组访问群集。 如果要添加组和用户，请参阅 Microsoft Entra ID 中创建演示组。

1. az aksarc get-credentials使用命令获取群集管理员凭据：

   az aksarc get-credentials --name "$aks_cluster_name" --resource-group "$resource_group_name" --admin
   

2. 使用 kubectl create namespace 命令在 Kubernetes 群集中创建命名空间。 以下示例创建名为 dev 的命名空间：

   kubectl create namespace dev
   

在 Kubernetes 中， 角色 定义要授予的权限， RoleBinding 将 权限应用于所需的用户或组。 这些分配可以应用于给定的命名空间或整个群集。 请参阅使用 Kubernetes RBAC 授权了解详细信息。

为 dev 命名空间创建角色。 此角色向命名空间授予完全权限。 在生产环境中，你可能希望为不同的用户或组指定更精细的权限。

1. 创建名为 role-dev-namespace.yaml 的文件，并复制/粘贴以下 YAML 清单：

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-full-access
     namespace: dev
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   

2. 使用 kubectl apply 命令创建角色，并指定 YAML 清单的文件名：

   kubectl apply -f role-dev-namespace.yaml
   

3. 使用 命令获取 appdev 组的资源 ID。az ad group show 此组将设置为在下一步骤中创建的角色绑定的使用者：

   az ad group show --group appdev --query objectId -o tsv
   

   az ad group show 命令返回你用作 groupObjectId 的值：

   38E5FA30-XXXX-4895-9A00-050712E3673A
   

4. 创建名为 rolebinding-dev-namespace.yaml 的文件，并复制/粘贴以下 YAML 清单。 建立角色绑定，使 appdev 组能够使用该 role-dev-namespace 角色进行命名空间访问。 在最后一行中，将 groupObjectId 替换为使用 az ad group show 命令生成的组对象 ID。

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: dev-user-access
     namespace: dev
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: dev-user-full-access
   subjects:
   - kind: Group
     namespace: dev
     name: groupObjectId
   

   小提示

   如果要为单个用户创建 RoleBinding ，请在示例中指定 kind: User 并替换为 groupObjectId 用户主体名称（UPN）。

5. 使用命令创建 kubectl apply，并指定 YAML 清单的文件名：

   kubectl apply -f rolebinding-dev-namespace.yaml
   

   rolebinding.rbac.authorization.k8s.io/dev-user-access created
   

为 AKS 群集资源使用内置 Kubernetes RBAC 角色

Kubernetes 还提供面向用户的内置角色。 这些内置角色包括：

• 超级用户角色 （群集管理员）
• 旨在使用 ClusterRoleBinding 在整个集群范围内授予的角色
• 旨在使用 RoleBindings（管理、编辑、查看）在特定命名空间内授予的角色

有关内置 Kubernetes RBAC 角色的详细信息，请参阅 Kubernetes RBAC 面向用户的角色。

面向用户的角色

默认 ClusterRole	默认 ClusterRoleBinding	DESCRIPTION
集群管理员	system:masters 组	允许超级用户访问，对任何资源执行任何操作。 在 ClusterRoleBinding 中使用时，此角色可完全控制群集和所有命名空间中的每个资源。 在 RoleBinding 中使用时，它将完全控制角色绑定命名空间中的每个资源，包括命名空间本身。
管理员	没有	允许使用旨在通过角色绑定在命名空间内授予的管理员访问权限。 如果在角色绑定中使用，则允许对命名空间中的大多数资源进行读/写访问，包括创建命名空间中的角色和角色绑定的功能。 此角色不允许对资源配额或命名空间本身进行写入访问。 此角色同样不允许对使用 Kubernetes v1.22+ 创建的群集中的端点进行写访问。 有关详细信息，请参阅终结点写入访问权限。
编辑	没有	允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是，此角色允许以命名空间中的任何 ServiceAccount 身份访问机密信息和运行 Pods，因此可用于获取命名空间中任何 ServiceAccount 的 API 访问级别。 此角色同样不允许对使用 Kubernetes v1.22+ 创建的群集中的端点进行写访问。 有关详细信息，请参阅终结点写入访问权限。
视图	没有	允许以只读方式访问以查看命名空间中的大多数对象。 不允许查看角色或角色绑定。 此角色不允许查看密钥，因为读取密钥的内容会使得能够访问命名空间中的 ServiceAccount 凭据，这样可能以命名空间中任何 ServiceAccount 的身份访问 API（即特权提升的一种形式）。

将内置 Kubernetes RBAC 角色与 Microsoft Entra ID 配合使用

若要将内置 Kubernetes RBAC 角色与 Microsoft Entra ID 配合使用，请执行以下步骤：

1. 将内置的 view Kubernetes RBAC 角色应用于 Microsoft Entra 组：

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
   

2. 将内置的 view Kubernetes RBAC 角色应用于每个Microsoft Entra 用户：

   kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
   

访问 Kubernetes 群集

现在，可以使用直接模式或代理模式访问具有指定权限的 Kubernetes 群集。

使用 kubectl 访问群集（直接模式）

若要使用指定权限访问 Kubernetes 群集，Kubernetes 操作员需要 Microsoft Entra kubeconfig，可以通过 az aksarc get-credentials 命令获取。 此命令提供对基于管理员的 kubeconfig 以及基于用户的 kubeconfig 的访问权限。 基于管理员的 kubeconfig 文件包含机密，应定期安全地存储和轮换。 另一方面，基于用户的 Microsoft Entra ID kubeconfig 不包含机密，并且可以分发给从客户端计算机连接的用户。

若要运行此 Azure CLI 命令，需要 Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action，该作包含在 Azure Kubernetes 服务 Arc 群集用户 角色权限中：

az aksarc get-credentials -g $resource_group_name -n $aks_cluster_name --file <file-name>

现在，可以使用 kubectl 管理群集。 例如，可以使用 kubectl get nodes 列出群集中的节点。 首次运行它时，必须登录，如以下示例所示：

kubectl get nodes

从客户端设备（代理模式）访问群集

若要使用 az connectedk8s proxy 命令通过代理模式从任意位置访问 Kubernetes 群集，需要 Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action，该作包含在 已启用 Azure Arc 的 Kubernetes 群集用户 角色权限中。

在另一个客户端设备上运行以下步骤：

1. 使用 Microsoft Entra 身份验证登录。

2. 获取从任何地方（甚至从群集周围的防火墙外）与群集通信所需的群集连接 kubeconfig：

   az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name
   

   注释

   此命令将打开代理并阻止当前 shell。

3. 在不同的 shell 会话中，使用 kubectl 将请求发送到群集：

   kubectl get pods -A
   

现在应会看到来自群集的响应，其中包含 default 命名空间下所有 Pod 的列表。

有关详细信息，请参阅 从客户端设备访问群集

在分配的命名空间之外创建和查看群集资源

若要尝试在 dev 命名空间外部查看 Pod，请使用带有 kubectl get pods 标志的 --all-namespaces 命令：

kubectl get pods --all-namespaces

用户的组成员身份没有允许执行此操作的 Kubernetes 角色。 如果没有权限，该命令将生成错误：

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

后续步骤

• Azure 基于角色的访问控制 (Azure RBAC)