使用 Azure 基于角色的访问控制 （RBAC） 进行 Kubernetes 授权
适用于：Azure 本地版本 23H2 上的 AKS
基础结构管理员可以使用 Azure 基于角色的访问控制（Azure RBAC）来控制谁可以访问 kubeconfig 文件和他们拥有的权限。 Kubernetes 操作员可以使用基于给定权限的 kubectl 工具与 Kubernetes 群集进行交互。 Azure CLI 提供了一种简单的方法来获取访问凭据和 kubeconfig 配置文件，以使用 kubectl 连接到 AKS 群集。
在 Microsoft Entra ID 和 AKS 之间使用集成身份验证时，可以使用 Microsoft Entra 用户、组或服务主体作为 Kubernetes 基于角色的访问控制（Kubernetes RBAC）中的主体。 使用此功能，你无需分别管理 Kubernetes 的用户标识和凭据。 但是，仍必须单独设置和管理 Azure RBAC 和 Kubernetes RBAC。
本文介绍如何通过 Microsoft Entra ID 和 Azure 角色分配使用 Azure RBAC 进行 Kubernetes 群集授权。
有关概念性概述，请参阅 由 Azure Arc 启用的适用于 AKS 的 Azure RBAC for Kubernetes 授权 。
开始之前
在开始之前，请确保具备以下先决条件：
Azure 本地版本 23H2 上的 AKS 目前仅支持在 Kubernetes 群集创建期间启用 Azure RBAC。 创建 Kubernetes 群集后，无法启用 Azure RBAC。
安装最新版本的 aksarc 和 connectedk8s Azure CLI 扩展。 请注意，需要运行 aksarc 扩展 1.1.1 或更高版本才能启用 Azure RBAC。 运行
az --version即可找到当前版本。 如果需要安装或升级 Azure CLI，请参阅 “安装 Azure CLI”。az extension add --name aksarc az extension add --name connectedk8s如果已安装扩展
aksarc，请将扩展更新为最新版本：az extension update --name aksarc az extension update --name connectedk8s创建 Kubernetes 群集时，需要具有以下权限才能启用 Azure RBAC：
- 若要创建 Kubernetes 群集，需要Azure Kubernetes 服务 Arc 参与者角色。
- 若要使用
--enable-azure-rbac参数，需要基于角色访问控制管理员角色才能访问 Microsoft.Authorization/roleAssignments/write 权限。 有关详细信息，请参阅 Azure 内置角色。 - 新角色分配可能需要最多 5 分钟完成传播并由授权服务器更新。
启用 Azure RBAC 后，可以使用直接模式或代理模式访问具有给定权限的 Kubernetes 群集。
- 若要直接使用
az aksarc get-credentials命令访问 Kubernetes 群集，需要 Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action，该操作包含在 Azure Kubernetes 服务 Arc 群集用户角色权限中。 - 若要使用
az connectedk8s proxy命令或从 Azure 门户 的代理模式从任意位置访问 Kubernetes 群集，需要Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action 操作操作，该操作包含在已启用 Azure Arc 的 Kubernetes 群集用户角色权限中。 同时，必须验证执行载入过程的代理和计算机是否满足已启用 Azure Arc 的 Kubernetes 网络要求中指定的 网络要求。
- 若要直接使用
若要使用 kubectl，可以使用 Azure RBAC 或 AAD 管理组访问它。
- 若要将 kubectl 与 Azure RBAC 配合使用，需要 将 Azure Arc Kubernetes 查看器 角色限定为连接的群集资源。
- 若要将 kubectl 与 AAD 管理组一起使用，不需要任何特定角色，但必须确保位于连接的群集资源的外接程序管理员组列表中的某个组。
步骤 1：创建已启用 Azure RBAC 的 Kubernetes 群集
可以创建已启用 Azure RBAC 的 Kubernetes 群集进行授权，并创建用于身份验证的 Microsoft Entra ID。
az aksarc create -n $aks_cluster_name -g $resource_group_name --custom-location $customlocation_ID --vnet-ids $logicnet_Id --generate-ssh-keys --enable-azure-rbac
片刻之后，该命令将会完成，并返回有关群集的 JSON 格式信息。
步骤 2：为用户创建角色分配以访问群集
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 中使用时，它会完全控制角色绑定命名空间中的每个资源，包括命名空间本身。 |
可以使用 az role assignment create 该命令创建角色分配。
首先，获取 $ARM-ID 要向其分配角色的目标群集。
$ARM_ID = (az connectedk8s show -g "$resource_group_name" -n $aks_cluster_name --query id -o tsv)
然后，使用 az role assignment create 命令将角色分配给 Kubernetes 群集。 必须提供 $ARM_ID 第一步和 assignee-object-id 此步骤。 assignee-object-id可以是Microsoft Entra ID 或服务主体客户端 ID。
以下示例将 Azure Arc Kubernetes 查看器 角色分配给 Kubernetes 群集：
az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <assignee-object-id> --scope $ARM_ID
在此示例中，范围是群集的 Azure 资源管理器 ID。 它也可以是包含 Kubernetes 群集的资源组。
创建自定义角色定义
可以选择创建自己的角色定义，以便在角色分配中使用。
以下示例演示一个角色定义，该定义允许用户仅读取部署。 有关详细信息，请参阅可用于构造角色定义的数据操作完整列表。 有关创建自定义角色的详细信息，请参阅 创建自定义角色的步骤
若要创建自定义角色定义，请将以下 JSON 对象复制到名为 custom-role.json的文件中。 请将 <subscription-id> 占位符替换为实际订阅 ID。 自定义角色使用其中一项数据操作，并让你可查看创建角色分配所在作用域（群集或命名空间）内的所有部署。
{
"Name": "AKS Arc Deployment Reader",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<YOUR SUBSCRIPTION ID>"
]
}
有关自定义角色以及如何创作这些角色的信息，请参阅 Azure 自定义角色。
使用 az role definition create 命令创建角色定义，将 --role-definition 参数设置为 在上一步中创建的 deploy-view.json文件：
az role definition create --role-definition @deploy-view.json
使用 az role assignment create 以下命令将角色定义分配给用户或其他标识：
az role assignment create --role "AKS Arc Deployment Reader" --assignee <assignee-object-id> --scope $ARM_ID
步骤 3：访问 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 群集用户角色权限中。
在另一个客户端设备上运行以下步骤：
使用 Microsoft Entra 身份验证登录
获取群集连接 kubeconfig ，以便从任何位置与群集通信（即使在群集周围的防火墙外部）：
az connectedk8s proxy -n $CLUSTER_NAME -g $RESOURCE_GROUP注意
此命令将打开代理并阻止当前 shell。
在不同的 shell 会话中，使用
kubectl将请求发送到群集：kubectl get pods -A
现在应会看到来自群集的响应，其中包含 default 命名空间下所有 Pod 的列表。
有关详细信息，请参阅 从客户端设备访问群集。
清理资源
删除角色分配
# List role assignments
az role assignment list --scope $ARM_ID --query [].id -o tsv
# Delete role assignments
az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
删除角色定义
az role definition delete -n "AKS Arc Deployment Reader"