在启用了 Azure Arc 的 Kubernetes 群集上使用 Azure RBAC

可以使用 Microsoft Entra ID 和 Azure 基于角色的访问控制（Azure RBAC）来控制启用Azure Arc的 Kubernetes 群集的授权检查。通过Azure角色分配，可以精细控制哪些用户可以读取、写入和删除 Kubernetes 对象，例如部署、Pod 和服务。 Kubernetes ClusterRoleBinding 和 RoleBinding 对象类型可以帮助你以本机方式在 Kubernetes 中定义授权。

有关此功能的概念性概述，请参阅 Azure RBAC 在启用了 Azure Arc 的 Kubernetes 上的应用。

先决条件

install 或将 Azure CLI 升级到最新版本。
安装最新版本的 connectedk8s Azure CLI 扩展：
```
az extension add --name connectedk8s
```
如果已安装 connectedk8s 扩展，则可以使用以下命令将其更新到最新版本：
```
az extension update --name connectedk8s
```
连接已启用Azure Arc的现有 Kubernetes 群集：
- 如果你尚未连接群集，请使用我们的快速入门。
- 将代理升级到最新版本。

注意

Red Hat OpenShift 或托管的 Kubernetes 产品/服务不支持Azure RBAC，其中用户对 API 服务器的访问权限受到限制（例如 Amazon Elastic Kubernetes 服务（EKS）或 Google Kubernetes 引擎（GKE））。

Azure RBAC 目前不支持在 Arm64 体系结构上运行的 Kubernetes 群集。对于这些群集，请使用 Kubernetes RBAC 来管理访问控制。

对于 Azure Kubernetes Service (AKS) 群集，此功能原生可用，并且不需要将 AKS 群集连接到 Azure Arc。

在群集上启用 Azure RBAC

通过运行以下命令来获取群集 MSI 标识：

az connectedk8s show -g <resource-group> -n <connected-cluster-name>

从输出获取 ID (identity.principalId) 并运行以下命令，将“连接的群集托管标识 CheckAccess 读者”角色分配给群集 MSI：
```
az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
```
运行以下命令，在启用了Azure Arc的 Kubernetes 群集上启用Azure基于角色的访问控制（RBAC）：
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
注意

运行 enable-features 命令之前，请确保计算机上的 kubeconfig 文件指向要启用 Azure RBAC 的群集。

使用 --skip-azure-rbac-list 配合此命令，可以获取正在使用 Kubernetes 本机 ClusterRoleBinding 和 RoleBinding 对象（而非 Azure RBAC）进行授权检查的用户名、电子邮件和 OpenID 连接的逗号分隔列表。

接下来，请遵循相应部分中的步骤，具体取决于使用的是未在规范上运行 apiserver 协调器的泛型群集，还是使用群集 API 创建的群集。

未在 apiserver 规范上运行协调器的泛型群集

通过 SSH 连接到群集的每个主节点，然后完成以下步骤：

如果 kube-apiserver 是静态 Pod：

azure-arc-guard-manifests 命名空间中的 kube-system 机密包含两个文件：guard-authn-webhook.yaml 和 guard-authz-webhook.yaml。将这些文件复制到节点的 /etc/guard 目录。

sudo mkdir -p /etc/guard
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml

在编辑模式下打开 apiserver 清单：

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

在 volumes 下添加以下规范：

- hostPath:
    path: /etc/guard
    type: Directory
name: azure-rbac

在 volumeMounts 下添加以下规范：

- mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

如果 kube-apiserver 不是静态 Pod：

在编辑模式下打开 apiserver 清单：

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

在 volumes 下添加以下规范：

- name: azure-rbac
    secret:
    secretName: azure-arc-guard-manifests

在 volumeMounts 下添加以下规范：

- mountPath: /etc/guard
    name: azure-rbac
    readOnly: true

添加下列 apiserver 参数：

- --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
- --authentication-token-webhook-cache-ttl=5m0s
- --authorization-webhook-cache-authorized-ttl=5m0s
- --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
- --authorization-webhook-version=v1
- --authorization-mode=Node,RBAC,Webhook

设置以下 apiserver 参数：

- --authentication-token-webhook-version=v1

保存并关闭编辑器以更新 apiserver Pod。

使用群集 API 创建的群集

将包含身份验证和授权 Webhook 配置文件的保护机密从工作负载群集复制到计算机上：
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
将 azure-arc-guard-manifests.yaml 文件中的 namespace 字段更改为管理群集内的命名空间，你要将在其中应用自定义资源以创建工作负载群集。

应用以下清单：

kubectl apply -f azure-arc-guard-manifests.yaml

通过运行 KubeadmControlPlane，编辑 kubectl edit kcp <clustername>-control-plane 对象：

在 files 下添加以下规范：

- contentFrom:
    secret:
      key: guard-authn-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authn-webhook.yaml
  permissions: "0644"
- contentFrom:
    secret:
      key: guard-authz-webhook.yaml
      name: azure-arc-guard-manifests
  owner: root:root
  path: /etc/kubernetes/guard-authz-webhook.yaml
  permissions: "0644"

在 apiServer>extraVolumes 下添加以下规范：

- hostPath: /etc/kubernetes/guard-authn-webhook.yaml
    mountPath: /etc/guard/guard-authn-webhook.yaml
    name: guard-authn
    readOnly: true
- hostPath: /etc/kubernetes/guard-authz-webhook.yaml
    mountPath: /etc/guard/guard-authz-webhook.yaml
    name: guard-authz
    readOnly: true

在 apiServer>extraArgs 下添加以下规范：

authentication-token-webhook-cache-ttl: 5m0s
authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
authentication-token-webhook-version: v1
authorization-mode: Node,RBAC,Webhook
authorization-webhook-cache-authorized-ttl: 5m0s
authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
authorization-webhook-version: v1

保存并关闭以更新 KubeadmControlPlane 对象。请等待这些更改出现在工作负载群集上。

创建角色分配以便用户访问群集

已启用Azure Arc的 Kubernetes 资源的所有者可以使用内置角色或自定义角色授予其他用户对 Kubernetes 群集的访问权限。

内置角色

以下内置角色提供对 Kubernetes 群集执行常见任务的访问权限。可以将这些角色授予 Microsoft Entra ID 用户、组或服务主体。

角色	说明
Azure Arc Kubernetes Viewer	允许进行只读访问并查看命名空间中的大多数对象。此角色不允许查看机密，这是因为机密的 `read` 权限允许访问命名空间中的 `ServiceAccount` 凭据。这些凭据进而会允许使用该 `ServiceAccount` 值进行 API 访问（一种特权提升形式）。
Azure Arc Kubernetes 编写器	允许对命名空间中的大多数对象进行读/写访问。此角色不允许查看或修改角色或角色绑定。但是，此角色允许访问机密和运行 Pod（机密和 Pod 都作为命名空间中的 `ServiceAccount` 值），因此它可用于获取命名空间中 `ServiceAccount` 值的 API 访问级别。
Azure Arc Kubernetes 管理员	授予管理员访问权限。此角色通常通过`RoleBinding`对象在命名空间中授予。如果在 `RoleBinding` 中使用，则允许对命名空间中的大部分资源进行读/写访问，包括能够在该命名空间内创建角色和角色绑定。但是，此角色不允许对资源配额或命名空间本身进行写入访问。
Azure Arc Kubernetes 群集管理员	允许在授予范围内对任何资源执行任何操作。在 `ClusterRoleBinding` 中使用时，它提供对群集和所有命名空间中每种资源的完全控制。在 `RoleBinding` 中使用时，即授予对该角色绑定的命名空间中每种资源（包括该命名空间本身）的完全控制权。

可以使用 Azure 门户或 Azure CLI 中创建作用于群集的内置角色分配。但是，只有使用 Azure CLI 才能创建限定在命名空间的角色分配。

若要在 Azure 门户中创建适用于支持 Azure Arc 的 Kubernetes 群集的角色分配，请导航至群集，然后从服务菜单中选择访问控制 (IAM)。

若要使用Azure CLI创建角色分配，请使用以下命令：

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

AZURE-AD-ENTITY-ID 可以是用户名（例如）， testuser@mytenant.partner.onmschina.cn也可以 appId 是服务主体的值。

若要创建范围为群集内的特定命名空间的角色分配，请调整范围：

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

自定义角色

可以选择创建自己的角色定义，以便在角色分配中使用。有关详细信息，请参阅可用于构造角色定义的数据操作完整列表。

以下示例显示了一个自定义角色定义，该定义允许用户读取部署，但不提供其他访问权限。自定义角色使用其中一项数据操作，并让你可查看创建角色分配所在作用域（群集或命名空间）内的所有部署。

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

若要使用此角色定义，请将以下 JSON 对象复制到名为 custom-role.json的文件中。请将 <subscription-id> 占位符替换为实际订阅 ID。然后，完成以下步骤：

通过从保存了“custom-role.json”的文件夹运行以下命令来创建角色定义：
```
az role definition create --role-definition @custom-role.json
```

创建角色分配以分配此自定义角色定义：

az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

使用用户凭据来配置 kubectl

可通过两种方法获取访问群集所需的 kubeconfig 文件：

使用 Azure Arc 启用的 Kubernetes 群集中的集群连接功能 (az connectedk8s proxy)。
群集管理员可以与每个用户共享 kubeconfig 文件。

使用集群连接

运行以下命令以启动代理进程：

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

该代理进程运行后，你可以在控制台中打开另一个选项卡，开始向群集发送请求。

使用共享 kubeconfig 文件

运行以下命令，以便为用户设置凭据。将 serverApplicationId 指定为 6256c85f-0aad-4d50-b960-e6e9b21efe35，并将 clientApplicationId 指定为 3f4439ff-e698-4d6d-84fe-09c9d574f06b：

kubectl config set-credentials <testuser>@<mytenant.partner.onmschina.cn> \
--auth-provider=azure \
--auth-provider-arg=environment=AzureChinaCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

打开先前创建的 kubeconfig 文件。在 contexts 下，确认与该群集相关联的上下文指向上一步中创建的用户凭据。要使用这些用户凭据设置当前上下文，请运行以下命令：
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.partner.onmschina.cn>
```

在 user> 下，添加 config-mode 设置config：

name: testuser@mytenant.partner.onmschina.cn
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzureChinaCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

Exec 插件是一种 Kubernetes 身份验证策略，允许 kubectl 执行外部命令来接收要发送到 apiserver 的用户凭据。从 Kubernetes 版本 1.26 开始，若要使用 exec 插件接收用户凭据，必须使用 Azure kubelogin，这是实现Azure身份验证的 client-go 凭据（exec）插件。若要安装 Azure kubelogin，
- 对于 Windows 或 Mac，请按照 Azure kubelogin 安装说明作。
- 对于 Linux 和 Ubuntu，请下载最新版的 kubelogin，然后运行以下命令：
```
curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 

unzip kubelogin-linux-amd64.zip 

sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 

sudo chmod +x /usr/local/bin/kubelogin 
```
Kubelogin 可以通过请求 PoP（所有权证明）令牌来与支持 Azure Arc 的群集进行身份验证。使用 kubelogin 将 kubeconfig 转换，以选择支持 PoP 令牌的相应登录模式。对于与Microsoft Entra用户交互登录，命令如下所示：
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig -l interactive --pop-enabled --pop-claims "u=/ARM/ID/OF/CLUSTER"
```

发送请求到群集

运行任何 kubectl 命令。例如：
- kubectl get nodes
- kubectl get pods
系统提示进行基于浏览器的身份验证后，请复制设备登录 URL (https://microsoft.com/deviceloginchina)，并在 Web 浏览器中打开它。
输入显示在控制台上的代码。将终端上的代码复制并粘贴到设备身份验证输入提示中。
输入用户名 (testuser@mytenant.partner.onmschina.cn) 和关联的密码。
如果看到一条错误消息，指出用户无权访问Azure中的资源，这意味着你无权访问请求的资源。在这种情况下，Azure租户中的管理员需要创建一个新的角色分配，授权此用户有权访问资源。

将条件访问与Microsoft Entra ID配合使用

将Microsoft Entra ID与已启用Azure Arc的 Kubernetes 群集集成后，还可以使用 Conditional Access 来控制对群集的访问。

注意

Microsoft Entra 条件访问是 Microsoft Entra ID P2 的一项功能。有关Microsoft Entra ID SKU 的详细信息，请参阅 pricing 指南。

若要创建用于群集的示例条件访问策略：

在Azure门户顶部，搜索并选择Microsoft Entra ID。
在服务菜单中的“ 管理”下，选择 “企业应用程序”。
在服务菜单中的 “安全性”下，选择 “条件访问”。
在服务菜单中，选择“ 策略”。然后选择“ 创建新策略”。
输入策略的名称，例如 arc-k8s-policy。
在“分配”下，选择“用户或工作负载标识”下的当前值。然后，在“ 此策略适用于什么？”下，验证是否选择了 “用户和组 ”。
在“包括”下，选择“选择用户和组”。然后选择要应用策略的用户和组。对于此示例，请选择对群集具有管理访问权限的同一Microsoft Entra组。
在“云应用或操作”下选择当前值。然后，在 “选择此策略适用的内容”下，验证是否选择了 云应用 。
在“包括”下，选择“选择资源”。然后，搜索并选择之前创建的服务器应用程序。
在 “访问控制”下，选择 “授予”下的当前值。然后选择 “授予访问权限”。
选中“ 要求设备标记为合规”框，然后选择“ 选择”。
在“启用策略”下，选择“开”。
若要应用条件访问策略，请选择“创建”。

再次访问群集。例如，运行 kubectl get nodes 命令来查看群集中的节点：

kubectl get nodes

若要确认策略已正确应用，请按照说明再次登录。错误消息指出您已成功登录，但管理员要求请求访问的设备必须由 Microsoft Entra ID 管理，才能访问资源。按照以下步骤查看更多详细信息：

在Azure门户中，转到 Microsoft Entra ID。
在服务菜单中的“ 管理”下，选择 “企业应用程序”。
在服务菜单中的 “活动”下，选择 “登录日志”。
选择顶部显示“状态失败”和“条件访问成功”的条目。然后，在 “详细信息”下，选择 “条件访问”。 你将看到你创建的条件访问策略，要求设备必须合规。

使用 Microsoft Entra ID 配置实时群集访问

群集访问控制的另一个选项是特权身份管理（Privileged Identity Management，PIM），这为用户启用了更高级别的访问权限以满足按需请求。

注意

Microsoft Entra PIM 是Microsoft Entra ID P2 功能。有关Microsoft Entra ID SKU 的详细信息，请参阅 pricing 指南。

若要为一组用户配置实时访问请求，请完成以下步骤：

在Azure门户顶部，搜索并选择Microsoft Entra ID。
在服务菜单中的“ 管理”下，选择“ 组”。然后选择新建组。
对于 组类型，请验证是否选择了 “安全性 ”。输入组名称，例如 myJITGroup。进行任何其他选择，然后选择“ 创建”。

&截图显示有关 Azure 门户中新组的详细信息。
你将返回到“组”页。搜索并选择您新创建的组。
在服务菜单中的 Activity 下，选择 Privileged Identity Management。然后选择 “为此组启用 PIM”。
选择“添加分配”开始授予访问权限。
在 “选择角色”下，选择 “成员”。然后选择要向其授予群集访问权限的用户和组。组管理员可以随时修改这些分配。准备好继续操作时，选择“下一步”。

截图显示如何在 Azure 门户中添加分配。
选择“活动”分配类型，选择所需的持续时间，并提供理由。准备好继续操作时，选择“分配”。

有关这些步骤和选项的详细信息，请参阅在 Privileged Identity Management 中为组分配资格。

完成任务分配后，通过访问群集来验证即时访问是否正常工作。例如，使用 kubectl get nodes 命令来查看群集中的节点：

kubectl get nodes

请注意身份验证要求，并按照步骤完成身份验证。如果身份验证成功，应会看到类似于此内容的输出：

To sign in, use a web browser to open the page https://microsoft.com/deviceloginchina and enter the code AAAAAAAAA to authenticate.

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

维护 Azure RBAC 证书

Azure Arc 启用的 Kubernetes 群集上的 RBAC 使用 Azure Arc Guard 授权 webhook。在非托管 Kubernetes 群集（如 k3s）上，防护 Webhook 证书存储在磁盘上，需要手动轮换。防护 Webhook 证书在创建或上次刷新日期起一年内过期，应在到期前每年更新一次。可以通过 guard-authz-webhook 证书文件或磁盘上的 Guard 身份验证文件检查到期日期。

如果存储在磁盘上的 Guard Webhook 客户端证书过期，则需要手动维护。发生这种情况时，即使群集和工作负荷保持正常，API 服务器授权请求也会失败。如果防护 Webhook 证书过期，可能会看到以下内容：

kubectl 命令失败并出现 TLS 错误，例如 tls：错误的证书。

例：

Error from server (InternalError): an error on the server ("Internal Server Error: \"/api/v1/nodes?limit=500\": Post \"https://192.168.X.X:443/subjectaccessreviews?timeout=30s\": remote error: tls: bad certificate") has prevented the request from succeeding (get nodes)

针对群集的 Azure CLI 操作失败
显示 TLS 握手或证书过期错误的 API 服务器或防护日志，例如 x509：证书已过期。例：

http: TLS handshake error from 192.168.0.0:65062: tls: failed to verify certificate: x509: certificate has expired or is not yet valid:

若要解决此问题，应刷新 Azure RBAC 防护 Webhook 证书。需要以下访问权限才能执行修复：

先决条件

读取对受影响群集中 kube-system 命名空间中的机密的访问权限。
对于非群集 API 群集，SSH 访问群集的系统/主节点。
对于群集 API 群集，需要能够访问创建工作负荷群集的管理群集。

满足访问先决条件后，可以通过执行以下步骤来刷新防护 Webhook 证书：

运行以下命令以刷新 guard Webhook 证书：

kubectl rollout restart deployment/guard -n azure-arc

对于未在 apiserver 规范上运行协调器的泛型群集，应执行步骤 1a，然后重启 kube-apiserver Pod。
对于使用群集 API 创建的群集，应执行步骤 1-3。完成步骤 1-3 后，需要触发 KubeadmControlPlane 对象的重新协调，以将新的 Webhook 配置应用到工作负荷群集。步骤 4（编辑 CR）可能会触发 KubeadmControlPlane 对象的重新协调。

后续步骤

了解已启用 Arc 的 Kubernetes 上 Azure RBAC 架构。
使用群集连接安全地连接到已启用 Arc 的 Kubernetes 群集。
按照已启用 Azure Arc 的 Kubernetes security book 中的指南，以其他方式保护您的群集。

Last updated on 2026-03-10

Compartir a través de

在启用了 Azure Arc 的 Kubernetes 群集上使用 Azure RBAC

先决条件

在群集上启用 Azure RBAC

未在 apiserver 规范上运行协调器的泛型群集

使用群集 API 创建的群集

创建角色分配以便用户访问群集

内置角色

自定义角色

使用用户凭据来配置 kubectl

使用集群连接

使用共享 kubeconfig 文件

发送请求到群集

将条件访问与Microsoft Entra ID配合使用

使用 Microsoft Entra ID 配置实时群集访问

维护 Azure RBAC 证书

后续步骤

Recursos adicionales