Uso de Azure RBAC en clústeres de Kubernetes habilitados para Azure Arc

2025-04-30

Puede usar el identificador de Entra de Microsoft y el control de acceso basado en rol de Azure (RBAC de Azure) para controlar las comprobaciones de autorización en el clúster de Kubernetes habilitado para Azure Arc. Las asignaciones de roles de Azure permiten controlar de forma granular qué usuarios pueden leer, escribir y eliminar objetos de Kubernetes, como la implementación, el pod y el servicio. Los tipos de objetos ClusterRoleBinding y RoleBinding de Kubernetes ayudan a definir la autorización en Kubernetes de forma nativa.

Para encontrar información general conceptual sobre esta característica, consulte Azure RBAC en Kubernetes habilitado para Azure Arc.

Requisitos previos

Instale o actualice la CLI de Azure a la versión más reciente.
Instale la versión más reciente de laconnectedk8s extensión de la CLI de Azure:
```
az extension add --name connectedk8s
```
Si la extensión connectedk8s ya está instalada, puede actualizarla a la versión más reciente mediante el comando siguiente:
```
az extension update --name connectedk8s
```
Conecte un clúster existente de Kubernetes habilitado para Azure Arc:
- Si aún no ha conectado un clúster, use nuestro inicio rápido.
- Actualice los agentes a la versión más reciente.

Nota

Azure RBAC no es compatible con las ofertas de Red Hat OpenShift o Kubernetes administradas en las que el acceso de usuario al servidor de API está restringido (como Amazon Elastic Kubernetes Service (EKS) o Google Kubernetes Engine (GKE)).

Azure RBAC no admite actualmente clústeres de Kubernetes que funcionan en la arquitectura arm64. Para estos clústeres, use RBAC de Kubernetes para administrar el control de acceso.

En el caso de los clústeres de Azure Kubernetes Service (AKS), esta característica está disponible de forma nativa y no requiere que el clúster de AKS esté conectado a Azure Arc.

En el caso de los clústeres de Azure Kubernetes Service (AKS) habilitados por Azure Arc en Azure Local, versión 23H2, Azure RBAC solo se admite actualmente si se habilita cuando se crean los clústeres. Para crear un clúster de AKS habilitado por Azure Arc con Azure RBAC habilitado, consulte Uso de RBAC de Azure para la autorización de Kubernetes. Azure RBAC no es compatible con Azure Local, versión 22H2.

Habilitación de RBAC de Azure en el clúster

Para obtener la identidad MSI del clúster, ejecute el comando siguiente:
```
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
```
Obtenga el ID (identity.principalId) de la salida y ejecute el siguiente comando para asignar el rol Lector de Comprobación de Acceso de Identidad Administrada del Clúster Conectado al MSI del clúster:
```
az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
```
Habilite el control de acceso basado en rol (RBAC) de Azure en el clúster de Kubernetes habilitado para Azure Arc mediante la ejecución del comando siguiente:
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
Nota

Antes de ejecutar el enable-features comando, asegúrese de que el kubeconfig archivo de la máquina apunta al clúster en el que desea habilitar Azure RBAC.

Use --skip-azure-rbac-list con este comando para obtener una lista separada por comas de nombres de usuario, correos electrónicos y conexiones OpenID en las que se realizan comprobaciones de autorización mediante el uso de objetos nativos ClusterRoleBinding y RoleBinding nativos de Kubernetes en lugar de RBAC de Azure.

A continuación, siga los pasos de la sección adecuada, en función de si usa un clúster genérico en el que no se ejecuta ningún reconciliador en la apiserver especificación o un clúster creado mediante cluster API.

Clúster genérico en el que no se ejecuta ningún reconciliador en la especificación de `apiserver`

Conéctese mediante SSH a cada nodo maestro del clúster y, a continuación, complete los pasos siguientes:

Si su kube-apiserver es un pod estático:

El secreto azure-arc-guard-manifests del espacio de nombres kube-system contiene dos archivos: guard-authn-webhook.yaml y guard-authz-webhook.yaml. Copie estos archivos en el directorio /etc/guard del nodo.

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

Abra el manifiesto de apiserver en modo de edición:

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

Agregue la especificación siguiente en volumes:

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

Agregue la especificación siguiente en volumeMounts:

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

si su kube-apiserver no es un pod estático:

Abra el manifiesto de apiserver en modo de edición:

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

Agregue la especificación siguiente en volumes:

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

Agregue la siguiente especificación después de volumeMounts:

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

Agregue los argumentos apiserver siguientes:

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

Establezca el siguiente apiserver argumento:

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

Guarde y cierre el editor para actualizar el pod de apiserver.

Clúster creado mediante la API de clústeres

Copie el secreto de protección que contiene los archivos de configuración de webhook de autenticación y autorización del clúster de carga de trabajo en la máquina:
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
Cambie el valor del campo namespace del archivo azure-arc-guard-manifests.yaml por el espacio de nombres en el clúster de administración en el que está aplicando los recursos personalizados para la creación de clústeres de cargas de trabajo.

Aplique el siguiente manifiesto:

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

Ejecute kubectl edit kcp <clustername>-control-plane para editar el objeto KubeadmControlPlane:

Agregue la especificación siguiente en 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"

Agregue la especificación siguiente en 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

Agregue la especificación siguiente en 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

Guarde y cierre para actualizar el objeto KubeadmControlPlane. Espere a que estos cambios aparezcan en el clúster de cargas de trabajo.

Creación de asignaciones de roles para que los usuarios accedan al clúster

Los propietarios del recurso de Kubernetes habilitado para Azure Arc pueden usar roles integrados o roles personalizados para conceder a otros usuarios acceso al clúster de Kubernetes.

Roles integrados

Los siguientes roles integrados proporcionan acceso para realizar tareas comunes en clústeres de Kubernetes. Estos roles se pueden conceder a usuarios, grupos o entidades de servicio de Microsoft Entra ID.

Rol	Descripción
Visor de Kubernetes de Azure Arc	Permite el acceso de solo lectura para ver la mayoría de los objetos de un espacio de nombres. Este rol no permite ver secretos, ya que `read` el permiso en secretos habilitaría el acceso a las credenciales `ServiceAccount` en el espacio de nombres. Estas credenciales, a su vez, permitirían el acceso a la API a través de ese valor de `ServiceAccount` (una forma de escalación de privilegios).
Escritor de Azure Arc Kubernetes	Permite el acceso de lectura y escritura para ver la mayoría de los objetos en un espacio de nombres. Este rol no permite ver ni modificar roles ni enlaces de roles. Sin embargo, este rol permite acceder a secretos y ejecutar pods como cualquier valor de `ServiceAccount` en el espacio de nombres, por lo que se puede usar para obtener los niveles de acceso de API de cualquier valor de `ServiceAccount` en el espacio de nombres.
Administrador de Kubernetes de Azure Arc	Permite el acceso de administrador. Este rol se concede a menudo dentro de un espacio de nombres a través de del objeto `RoleBinding` y . Si lo usa en `RoleBinding`, permite el acceso de lectura y escritura a la mayoría de los recursos de un espacio de nombres, incluida la capacidad de crear roles y enlaces de roles dentro del espacio de nombres. Sin embargo, este rol no permite el acceso de escritura a la cuota de recursos ni al propio espacio de nombres.
Administrador de clústeres de Kubernetes de Azure Arc	Permite ejecutar cualquier acción en cualquier recurso dentro del ámbito concedido. Cuando se usa en `ClusterRoleBinding`, permite el control total sobre todos los recursos del clúster y en todos los espacios de nombres. Cuando se utiliza en `RoleBinding`, permite un control total sobre todos los recursos dentro del espacio de nombres asociado al enlace de roles, incluso sobre el propio espacio de nombres.

Puede crear asignaciones de roles integradas en el ámbito del clúster mediante Azure Portal o la CLI de Azure. Sin embargo, solo se puede usar la CLI de Azure para crear asignaciones de roles en el ámbito de los espacios de nombres.

Para crear asignaciones de roles con ámbito en el clúster de Kubernetes habilitado para Azure Arc en Azure Portal, vaya al clúster y, a continuación, seleccione Control de acceso (IAM) en el menú del servicio.

Para crear asignaciones de roles mediante la CLI de Azure, use el siguiente comando:

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

AZURE-AD-ENTITY-ID puede ser un nombre de usuario (por ejemplo, testuser@mytenant.onmicrosoft.com) o el appId valor de una entidad de servicio.

Para crear una asignación de roles con ámbito a un espacio de nombres específico dentro del clúster, modifique el ámbito:

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

Roles personalizados

Puede optar por crear su propia definición de rol para usarla en las asignaciones de roles. Para obtener más información, consulte la lista completa de acciones de datos que puede usar para construir una definición de roles.

En el ejemplo siguiente se muestra una definición de rol personalizada que permite a un usuario leer implementaciones, pero no proporciona ningún otro acceso. El rol personalizado usa una de las acciones de datos y le permite ver todas las implementaciones en el ámbito (clúster o espacio de nombres) donde se crea la asignación de roles.

{
    "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>"
    ]
}

Para usar esta definición de rol, copie el siguiente objeto JSON en un archivo denominado custom-role.json. Reemplace el marcador de posición <subscription-id> por el identificador de suscripción real. A continuación, complete estos pasos:

Cree la definición de rol ejecutando el comando siguiente desde la carpeta donde guardó custom-role.json:
```
az role definition create --role-definition @custom-role.json
```

Cree una asignación de roles para asignar esta definición de rol personalizada:

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

Configuración de kubectl con credenciales de usuario

Hay dos maneras de obtener el archivo kubeconfig que necesita para acceder al clúster:

Use la característica de conexión de clúster (az connectedk8s proxy) del clúster de Kubernetes habilitado para Azure Arc.
El administrador del clúster puede compartir el archivo kubeconfig con cada usuario.

Uso de la conexión de clúster

Ejecute el siguiente comando para iniciar el proceso de proxy:

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

Después de ejecutar el proceso de proxy, puede abrir otra pestaña en la consola para empezar a enviar las solicitudes al clúster.

Uso de un archivo kubeconfig compartido

Ejecute el siguiente comando para establecer las credenciales del usuario. Especifique serverApplicationId como 6256c85f-0aad-4d50-b960-e6e9b21efe35 y clientApplicationId como 3f4439ff-e698-4d6d-84fe-09c9d574f06b:

kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
--auth-provider=azure \
--auth-provider-arg=environment=AzurePublicCloud \
--auth-provider-arg=client-id=<clientApplicationId> \
--auth-provider-arg=tenant-id=<tenantId> \
--auth-provider-arg=apiserver-id=<serverApplicationId>

Abra el archivo kubeconfig que creó anteriormente. En contexts, compruebe que el contexto asociado al clúster apunta a las credenciales de usuario que creó en el paso anterior. Para establecer el contexto actual en estas credenciales de usuario, ejecute el siguiente comando:
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

Agregue la configuración del modo de configuración en user>config:

name: testuser@mytenant.onmicrosoft.com
user:
    auth-provider:
    config:
        apiserver-id: $SERVER_APP_ID
        client-id: $CLIENT_APP_ID
        environment: AzurePublicCloud
        tenant-id: $TENANT_ID
        config-mode: "1"
    name: azure

El complemento Exec es una estrategia de autenticación de Kubernetes que permite kubectl ejecutar un comando externo para recibir credenciales de usuario para enviar a apiserver. A partir de la versión 1.26 de Kubernetes, para usar el complemento exec para recibir credenciales de usuario, debe usar azure kubelogin, un client-go complemento de credenciales (exec) que implemente la autenticación de Azure. Para instalar Azure kubelogin:
- Para Windows o Mac, siga las instrucciones de instalación de Kubelogin de Azure.
- Para Linux o Ubuntu, descargue la versión más reciente de kubelogin y ejecute los siguientes comandos:
```
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 se puede usar para autenticarse con clústeres habilitados para Azure Arc solicitando un token de prueba de posesión (PoP). Convierta el kubeconfig con kubelogin para utilizar el modo adecuado de inicio de sesión. Por ejemplo, para el inicio de sesión de código de dispositivo con un usuario de Microsoft Entra, los comandos serían los siguientes:
```
export KUBECONFIG=/path/to/kubeconfig

kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
```

Envío de solicitudes al clúster

Ejecutar cualquier comando kubectl. Por ejemplo:
- kubectl get nodes
- kubectl get pods
Después de solicitar la autenticación basada en explorador, copie la dirección URL de inicio de sesión del dispositivo (https://microsoft.com/devicelogin) y ábrala en el explorador web.
Escriba el código impreso en la consola. Copie y pegue el código del terminal en la solicitud de autenticación del dispositivo.
Escriba el nombre de usuario (testuser@mytenant.onmicrosoft.com) y la contraseña asociada.
Si ve un mensaje de error que indica que los usuarios no tienen acceso al recurso en Azure, significa que no está autorizado para acceder al recurso solicitado. En este caso, un administrador del inquilino de Azure debe crear una nueva asignación de roles que autorice a este usuario a tener acceso en el recurso.

Uso del acceso condicional con Microsoft Entra ID

Al integrar Microsoft Entra ID con el clúster de Kubernetes habilitado para Azure Arc, también puede usar el acceso condicional para controlar el acceso al clúster.

Nota

El acceso condicional de Microsoft Entra es una funcionalidad P2 de Microsoft Entra ID. Para obtener más información sobre las SKU de Microsoft Entra ID, consulte la guía de precios.

Para crear una directiva de acceso condicional de ejemplo que se usará con el clúster:

En la parte superior de Azure Portal, busque y seleccione Microsoft Entra ID.
En el menú del servicio, en Administrar, seleccione Aplicaciones empresariales.
En el menú servicio, en Seguridad, seleccione Acceso condicional.
En el menú servicio, seleccione Directivas. A continuación, seleccione Crear nueva directiva.
Escriba un nombre para la directiva, como arc-k8s-policy.
En Asignaciones, seleccione el valor actual en Usuarios o identidades de carga de trabajo. A continuación, en ¿A qué se aplica esta directiva?, compruebe que los usuarios y grupos están seleccionados.
En Incluir, elija Seleccionar usuarios y grupos. A continuación, elija los usuarios y grupos en los que desea aplicar la directiva. En este ejemplo, elija el mismo grupo de Microsoft Entra que tiene acceso administrativo al clúster.
Seleccione el valor actual en Aplicaciones o acciones en la nube. A continuación, en Seleccionar a qué se aplica esta directiva, compruebe que las aplicaciones en la nube están seleccionadas.
En Incluir, elija Seleccionar recursos. A continuación, busque y seleccione la aplicación de servidor que creó anteriormente.
En Controles de acceso, seleccione el valor actual en Otorgar. A continuación, seleccione Conceder acceso.
Active la casilla Requerir que el dispositivo esté marcado como compatible y, a continuación, seleccione Seleccionar.
En Habilitar directiva, seleccione Activado.
Para aplicar la directiva de acceso condicional, seleccione Crear.

Vuelva a acceder al clúster. Por ejemplo, ejecute el comando kubectl get nodes para ver los nodos del clúster:

kubectl get nodes

Para confirmar que la directiva se aplica correctamente, siga las instrucciones para iniciar sesión de nuevo. Un mensaje de error indica que ha iniciado sesión correctamente, pero el administrador requiere que el dispositivo que solicita acceso se administre mediante el Microsoft Entra ID para acceder al recurso. Siga estos pasos para ver más detalles:

En Azure Portal, vaya a Microsoft Entra ID.
En el menú del servicio, en Administrar, seleccione Aplicaciones empresariales.
En el menú servicio, en Actividad, seleccione Registros de inicio de sesión.
Seleccione la entrada de la parte superior que muestra Error para Estado y Éxito para Acceso Condicional. A continuación, en Detalles, seleccione Acceso condicional. Verá la directiva de acceso condicional que creó, lo que requiere que el dispositivo sea compatible.

Configuración del acceso al clúster Just-In-Time con el Microsoft Entra ID

Otra opción para el control de acceso de clúster es Privileged Identity Management (PIM), que permite un mayor nivel de acceso para los usuarios para las solicitudes Just-In-Time.

Nota

Microsoft Entra PIM es una funcionalidad de Microsoft Entra ID P2. Para obtener más información sobre las SKU de Microsoft Entra ID, consulte la guía de precios.

Para configurar las solicitudes de acceso Just-In-Time para un grupo de usuarios, complete los pasos siguientes:

En la parte superior de Azure Portal, busque y seleccione Microsoft Entra ID.
En el menú servicio, en Administrar, seleccione Grupos. A continuación, seleccione Nuevo grupo.
En Tipo de grupo, compruebe que seguridad está seleccionada. Escriba un nombre de grupo, como myJITGroup. Realice selecciones adicionales y, a continuación, seleccione Crear.
Vuelve a la página Grupos . Busque y seleccione el grupo recién creado.
En el menú del servicio, en Actividad, seleccione Privileged Identity Management. A continuación, seleccione Habilitar PIM para este grupo.
Seleccione Agregar asignaciones para comenzar a conceder acceso.
En Seleccionar rol, elija Miembro. A continuación, seleccione los usuarios y grupos a los que desea conceder acceso al clúster. Un administrador de grupo puede modificar estas asignaciones en cualquier momento. Cuando esté listo para continuar, seleccione Siguiente.
Elija un tipo de asignación activo, elija la duración deseada y proporcione una justificación. Cuando esté listo para continuar, seleccione Asignar.

Para obtener más información sobre estos pasos y opciones, consulte Asignación de elegibilidad para un grupo en Privileged Identity Management.

Una vez que se han realizado las asignaciones, acceda al clúster para comprobar que el acceso Just-in-Time funciona. Por ejemplo, use el comando kubectl get nodes para ver los nodos del clúster:

kubectl get nodes

Anote el requisito de autenticación y siga los pasos para autenticarse. Si la autenticación se realiza correctamente, debería ver una salida similar a la siguiente:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin 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

Pasos siguientes

Obtenga información sobre la Arquitectura de Azure RBAC en Kubernetes habilitado para Arc.
Conéctese de forma segura a un clúster de Kubernetes habilitado para Arc mediante cluster connect.
Ayude a proteger el clúster de otras maneras siguiendo las instrucciones del libro de seguridad de Kubernetes habilitado para Azure Arc.

Compartir vía

Uso de Azure RBAC en clústeres de Kubernetes habilitados para Azure Arc

Requisitos previos

Habilitación de RBAC de Azure en el clúster

Clúster genérico en el que no se ejecuta ningún reconciliador en la especificación de apiserver

Clúster creado mediante la API de clústeres

Creación de asignaciones de roles para que los usuarios accedan al clúster

Roles integrados

Roles personalizados

Configuración de kubectl con credenciales de usuario

Uso de la conexión de clúster

Uso de un archivo kubeconfig compartido

Envío de solicitudes al clúster

Uso del acceso condicional con Microsoft Entra ID

Configuración del acceso al clúster Just-In-Time con el Microsoft Entra ID

Pasos siguientes

Comentarios

Recursos adicionales

Clúster genérico en el que no se ejecuta ningún reconciliador en la especificación de `apiserver`