使用适用于 Windows Server 的 Microsoft Entra ID 和 Kubernetes RBAC 控制访问

适用于：Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS

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

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

先决条件

在使用 Microsoft Entra ID 设置 Kubernetes RBAC 之前，需要满足以下先决条件：

• 在 AKS Arc 中创建的 Kubernetes 群集。如果需要设置群集，请参阅使用 Windows Admin Center 或 PowerShell 部署 AKS 的说明。
• Azure Arc 连接。 必须具有与 Kubernetes 群集的 Azure Arc 连接。 有关启用 Azure Arc 的信息，请参阅将 Azure 本地群集上的Azure Kubernetes 服务连接到已启用 Azure Arc 的 Kubernetes。
• 需要访问以下命令行工具：
  • Azure CLI 和 connectedk8s 扩展。 Azure CLI 是一组用于创建和管理 Azure 资源的命令。 若要检查是否具有 Azure CLI，请打开命令行工具，然后键入： az -v 此外，安装 connectedk8s 扩展 ，以便打开 Kubernetes 群集的通道。 有关安装说明，请参阅 如何安装 Azure CLI。
  • Kubectl。 使用此 Kubernetes 命令行工具可以运行面向 Kubernetes 群集的命令。 若要检查是否安装了 kubectl，请打开命令提示符并键入： kubectl version --client 请确保 kubectl 客户端版本至少为 v1.24.0 版本。 有关安装说明，请参阅 kubectl。
  • PowerShell 和 AksHci PowerShell 模块。 PowerShell 是一种跨平台任务自动化解决方案，包括命令行 shell、脚本语言和配置管理框架。 如果安装了 AKS Arc，则有权访问 AksHci PowerShell 模块。
  • 若要从任何位置使用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. 使用 Get-AksHciCredential 以下命令获取群集管理员凭据：

   Get-AksHciCredential -name <name-of-your-cluster>
   

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

   kubectl create namespace dev
   

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

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

3. 创建名为 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: ["*"]
   

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

   kubectl apply -f role-dev-namespace.yaml
   

5. 使用 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
   

6. 创建名为 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)。

7. 使用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 中使用时，将授予对该角色绑定的命名空间中每个资源（包括该命名空间本身）的完全控制权。
admin	无	允许使用角色绑定在命名空间中授予管理员访问权限。 如果在角色绑定中使用，则允许对命名空间中的大多数资源进行读/写访问，包括创建命名空间中的角色和角色绑定的功能。 此角色不允许对资源配额或命名空间本身进行写入访问。 此角色也不允许对使用 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>
   

使用 Microsoft Entra ID 处理群集资源

现在，在 Kubernetes 群集中创建和管理资源时测试预期的权限。 在这些示例中，你将在用户分配的命名空间中计划和查看 Pod。 然后，尝试在分配的命名空间之外计划和查看 Pod。

1. 使用 $AKSDEV_ID 指定为命令输入 az ad group member add 的用户帐户登录到 Azure。 az connectedk8s proxy运行以下命令以打开群集的通道：

   az connectedk8s proxy -n <cluster-name> -g <resource-group>
   

2. 建立代理通道后，打开另一个会话，并使用kubectl run开发命名空间中的命令计划 NGINX Pod：

   kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   

   成功计划 NGINX 时，应会看到以下输出：

   pod/nginx-dev created
   

3. 现在，使用 kubectl get pods 命令查看命名空间中的 dev Pod：

   kubectl get pods --namespace dev
   

   成功运行 NGINX 时，应会看到以下输出：

   NAME        READY   STATUS    RESTARTS   AGE
   nginx-dev   1/1     Running   0          4m
   

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

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

后续步骤

• 详细了解 Windows Server 上的 AKS Arc 中的安全性