在 Azure Arc 中启用的 AKS 中使用 Microsoft Entra ID 和 Kubernetes RBAC 控制访问

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

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

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

先决条件

在使用Microsoft Entra标识设置 Kubernetes RBAC 之前，需要：

• 在 AKS Arc 中创建的 Kubernetes 群集

  需要一个在 AKS Arc 中创建的 Kubernetes 群集。如果需要设置群集，可以查找有关使用 Windows Admin Center 或 PowerShell 部署 AKS 的说明。

• Azure Arc 连接

  必须与 Kubernetes 群集建立 Azure Arc 连接。 有关启用 Azure Arc 的信息，请参阅将 Azure Stack HCI 上的 Azure Kubernetes 服务 群集连接到已启用 Azure Arc 的 Kubernetes。

• 需要访问以下命令行工具：

  • 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。

  • PowerShell 和 AksHci PowerShell 模块

    PowerShell 是一种跨平台的任务自动化解决方案，由命令行 shell、脚本语言和配置管理框架组成。 如果已安装 AKS Arc，则有权访问 AksHci PowerShell 模块。

可选的前几个步骤

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

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

在 Microsoft Entra ID 中Create演示组

首先，使用 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重新连接到 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 群集资源上Create自定义 Kubernetes RBAC 角色绑定

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

1. 使用 Get-AksHciCredential 命令获取群集管理员凭据：

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

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

   kubectl create namespace dev
   

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

   Create开发命名空间的角色。 此角色授予对命名空间的完全权限。 在生产环境中，可能需要为不同的用户或组指定更精细的权限。

3. Create名为 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 命令Create角色，并指定 YAML 清单的文件名：

   kubectl apply -f role-dev-namespace.yaml
   

5. 使用 az 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. Create名为 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+ 创建的群集中的终结点进行写入访问。 有关详细信息，请参阅 终结点的写入访问权限。
编辑	无	允许对命名空间中的大多数对象进行读/写访问。 此角色不允许查看或修改角色或角色绑定。 但是，此角色允许以命名空间中的任何 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标识处理群集资源

现在，在 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. 建立代理通道后，打开另一个会话，并使用 dev 命名空间中的 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 成功 运行时，会看到以下输出：

   $ kubectl get pods --namespace dev
   
   NAME        READY   STATUS    RESTARTS   AGE
   nginx-dev   1/1     Running   0          4m
   

Create并查看分配的命名空间外的群集资源

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

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 中的安全性