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

适用于：Azure Local 上的 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 Local 上的 AKS 目前仅支持在 Kubernetes 群集创建期间启用 Azure RBAC。 创建 Kubernetes 群集后，无法启用 Azure RBAC。

• 可以使用 Azure CLI 或 Azure 门户启用 Azure RBAC。 若要使用 Azure CLI，必须安装最新版本的 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 权限。

  • 若要分配这些角色，请使用 az role assignment create CLI 命令，或使用 Azure CLI 遵循分配 Azure 角色：

    az role assignment create --assignee <assignee-object-id> --role <role-name-or-id> --scope $ARM_ID
    

  • 新角色分配最多可能需要 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

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

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

可以使用 az role assignment create 该命令创建角色分配。

$ARM_ID = (az connectedk8s show -g "$resource_group_name" -n $aks_cluster_name --query id -o tsv)

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <assignee-object-id> --scope $ARM_ID

创建自定义角色定义

可以选择创建自己的角色定义，以便在角色分配中使用。

以下示例演示了一个角色定义，该定义仅允许用户读取部署信息。 有关详细信息，请参阅可用于构造角色定义的数据操作完整列表。 有关创建自定义角色的详细信息，请参阅 创建自定义角色的步骤

若要创建自定义角色定义，请将以下 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 权限
• 通过遵循 Azure Arc 启用的 AKS 安全手册中的指导，以其他方式来帮助保护群集。