使用 Azure 基于角色的访问控制 （RBAC） 进行 Kubernetes 授权

适用于：Azure Stack HCI 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 Stack HCI 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 群集交互，必须安装 kubectl 和 kubelogin。

• 创建 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 --control-plane-ip $controlplaneIP --enable-azure-rbac

片刻之后，该命令将会完成，并返回有关群集的 JSON 格式信息。

步骤 2：为用户创建角色分配以访问群集

Arc 启用的 AKS 提供以下五个内置角色。 它们与 Kubernetes 内置角色 类似，但存在一些差异，例如支持 CRD。 请查看每个 Azure内置角色允许的操作的完整列表。

可以使用 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 群集用户角色权限中。

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

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

2. 获取群集连接 kubeconfig ，以便从任何位置与群集通信（即使在群集周围的防火墙外部）：

   az connectedk8s proxy -n $CLUSTER_NAME -g $RESOURCE_GROUP
   

   注意

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

3. 在不同的 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"

后续步骤

• Azure 基于角色的访问控制 (Azure RBAC)
• Azure Arc 启用的 AKS 的访问和标识选项
• 使用 Azure CLI 创建 Azure 服务主体
• 混合 + 多云的 可用 Azure 权限