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

适用于：Azure Stack HCI 23H2 上的 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 网络要求中的 网络要求。

可选的前几个步骤

如果还没有包含成员的 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命令将用户添加到在上一节中创建的 appdev 组。 如果退出会话，请使用 az login..

$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 授权。

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

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. 使用 az ad group showaz ad group show 命令获取 appdev 组的资源 ID。 下一步中，此组设置为 RoleBinding 的主题：

   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命令创建 RoleBinding，并指定 YAML 清单的文件名：

   kubectl apply -f rolebinding-dev-namespace.yaml
   

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

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

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

• 超级用户角色 (cluster-admin)
• 旨在使用 ClusterRoleBinding 在群集范围授予的角色
• 旨在使用 RoleBinding 在特定命名空间中授予的角色（admin、edit、view）

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

面向用户的角色

默认 ClusterRole	默认 ClusterRoleBinding	说明
cluster-admin	system:masters group	允许超级用户访问，对任何资源执行任何操作。 在 ClusterRoleBinding 中使用时，此角色可完全控制群集和所有命名空间中的每个资源。 在 RoleBinding 中使用时，将授予对该角色绑定的命名空间中每个资源（包括该命名空间本身）的完全控制权。
管理员	无	允许使用角色绑定在命名空间中授予管理员访问权限。 如果在角色绑定中使用，则允许对命名空间中的大多数资源进行读/写访问，包括创建命名空间中的角色和角色绑定的功能。 此角色不允许对资源配额或命名空间本身进行写入访问。 此角色也不允许对使用 Kubernetes v1.22+ 创建的群集中的终结点进行写入访问。 有关详细信息，请参阅 终结点的写入访问。
edit	无	允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是，此角色允许以命名空间中的任何 ServiceAccount 身份访问机密和运行 Pod，因此可用于获取命名空间中任何 ServiceAccount 的 API 访问级别。 此角色也不允许对使用 Kubernetes v1.22+ 创建的群集中的终结点进行写入访问。 有关详细信息，请参阅 终结点的写入访问。
view	无	允许进行只读访问并查看命名空间中的大多数对象。 不允许查看角色或角色绑定。 此角色不允许查看机密，因为读取机密的内容允许访问命名空间中的 ServiceAccount 凭据，这将允许 API 访问作为命名空间中的任何 ServiceAccount（特权升级形式）。

将内置 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 的列表。

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

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

若要尝试查看开发命名空间外部的 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)