Compartir a través de

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

  • Artículo

Los tipos de objeto ClusterRoleBinding y RoleBinding de Kubernetes ayudan a definir la autorización en Kubernetes de forma nativa. Con esta característica, puede usar Microsoft Entra ID y las asignaciones de roles en Azure para controlar las comprobaciones de autorización en el clúster. 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.

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 la extensión de la CLI de Azure connectedk8s:

    az extension add --name connectedk8s

    Si la extensión connectedk8s ya está instalada, puede actualizarla a su versión más reciente con el siguiente comando:

    az extension update --name connectedk8s

  • Conecte un clúster existente de Kubernetes habilitado para Azure Arc:

Nota:

El RBAC de Azure no está disponible para las ofertas de Red Hat OpenShift o Kubernetes administrado en las que el acceso de usuario al servidor de API esté restringido (por ejemplo: Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)).

El RBAC de Azure no admite actualmente clústeres de Kubernetes que funcionen con arquitectura ARM64. Use el RBAC de Kubernetes para administrar el control de acceso para clústeres de Kubernetes basados en ARM64.

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 Stack HCI 23H2, la habilitación de Azure RBAC solo se admite actualmente durante la creación del clúster de Kubernetes. Para crear un clúster de AKS habilitado por Azure Arc con Azure RBAC habilitado, siga la guía de Uso de Azure RBAC para la autorización de Kubernetes. Tenga en cuenta que Azure RBAC no es compatible con Azure Stack HCI, versión 22H2.

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

  1. Para obtener la identidad MSI del clúster, ejecute el comando siguiente:

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

  2. Obtenga el identificador (identity.principalId) de la salida y ejecute el comando siguiente para asignar el rol CheckAccess Reader 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>

  3. Ejecute el siguiente comando para habilitar el control de acceso basado en rol (RBAC) de Azure en el clúster de Kubernetes habilitado para Azure Arc:

    az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac

    Nota:

    Antes de ejecutar el comando anterior, asegúrese de que el archivo kubeconfig de la máquina apunta al clúster en el que va a habilitar la característica RBAC de Azure.

    Use --skip-azure-rbac-list con el comando anterior para obtener una lista separada por comas de los nombres de usuario, correos electrónicos y conexiones de OpenID en proceso de comprobación de autorización mediante los objetos ClusterRoleBinding y RoleBindingnativos de Kubernetes, en lugar de RBAC de Azure.

Clúster genérico donde no se ejecuta ningún conciliador en la apiserver especificación

  1. Conéctese mediante SSH a cada nodo principal del clúster y realice los pasos siguientes:

    Si kube-apiserver es unpod estático:

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

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

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

    3. Agregue la siguiente especificación después de volumes:

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

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

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

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

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

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

    2. Agregue la siguiente especificación después de volumes:

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

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

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

  2. Agregue los siguientes argumentos de 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

    Si el clúster de Kubernetes es de la versión 1.19.0 o posterior, también debe establecer el argumento apiserver siguiente:

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

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

Clúster creado mediante la API de clústeres

  1. Copie el secreto de restricción que contiene los archivos de configuración de webhooks de autenticación y autorización del clúster de cargas de trabajo en el equipo:

    kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml

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

  3. Aplique el siguiente manifiesto:

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

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

    1. Agregue el siguiente fragmento de código después de 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"

    2. Agregue el siguiente fragmento de código después de 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

    3. Agregue el siguiente fragmento de código después de 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

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

Role Descripción
Visor de Azure Arc Kubernetes Permite el acceso de solo lectura para ver la mayoría de los objetos en un espacio de nombres. Este rol no permite ver secretos, ya que read el permiso en secretos habilitaría el acceso a ServiceAccount las credenciales en el espacio de nombres. A su vez, estas credenciales permitirían el acceso a la API a través del valor de ServiceAccount (una forma de elevació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 la visualización o modificación de roles o enlaces de roles. No obstante, este rol permite acceder a secretos y ejecutar pods como cualquier valor ServiceAccount en el espacio de nombres, por lo que se puede usar para obtener los niveles de acceso de la API de cualquier valor ServiceAccount en el espacio de nombres.
Administrador de Azure Arc Kubernetes Permite el acceso de administrador. Está diseñado para su concesión dentro de un espacio de nombres a través de RoleBinding. Si se 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. Este rol no permite el acceso de escritura a la cuota de recursos o al espacio de nombres en sí.
Administrador de clústeres de Azure Arc Kubernetes Permite el acceso de superusuario para ejecutar cualquier acción en cualquier recurso. Si se usa en ClusterRoleBinding, proporciona control total sobre todos los recursos del clúster y en todos los espacios de nombres. Si se usa en RoleBinding, proporciona control total sobre todos los recursos del espacio de nombres del enlace de roles, incluido el propio espacio de nombres.

Puede crear asignaciones de roles cuyo ámbito sea un clúster de Kubernetes habilitado para Azure Arc en Azure Portal, en el panel Control de acceso (IAM) del recurso de clúster. También puede usar los siguientes comandos de la CLI de Azure:

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

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

El siguiente es otro ejemplo de creación de una asignación de roles en el ámbito de un espacio de nombres específico dentro del clúster:

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

Nota:

Puede crear asignaciones de roles 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 cuyo ámbito sea espacios de nombres.

Roles personalizados

Puede elegir su propia definición de roles para usarla en las asignaciones de roles.

Examine el siguiente ejemplo una definición de roles que solo permite a un usuario leer las implementaciones. Para obtener más información, consulte la lista completa de acciones de datos que puede usar para crear una definición de roles.

Copie el siguiente objeto JSON en un archivo denominado custom-role.json. Reemplace el marcador de posición <subscription-id> por el identificador de la suscripción real. El rol personalizado usa una de las acciones de datos y le permite ver todas las implementaciones del ámbito (clúster o espacio de nombres) en el que se creó 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>"
    ]
}

  1. Ejecute el siguiente comando desde la carpeta donde se guardó el archivo custom-role.json para crear la definición de roles:

    az role definition create --role-definition @custom-role.json

  2. Cree una asignación de roles con esta definición de roles 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 Conexión de clúster (az connectedk8s proxy) del clúster de Kubernetes habilitado para Azure Arc.
  • El administrador del clúster comparte el archivo kubeconfig con todos los demás usuarios.

Uso de conexión del clúster

Ejecute el siguiente comando para iniciar el proceso de proxy:

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

Una vez que se está ejecutando el proceso de proxy, puede abrir otra pestaña en la consola para empezar a enviar solicitudes al clúster.

Uso de un archivo kubeconfig compartido

El uso de kubeconfig compartido requiere pasos ligeramente diferentes en función de la versión de Kubernetes.

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

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

  3. Agregue el valor config-mode debajo de 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

    Nota:

    El plugin Exec es una estrategia de autenticación de Kubernetes que permitekubectlejecutar un comando externo para recibir las credenciales de usuario y enviarlas a apiserver. A partir de la versión 1.26 de Kubernetes, el complemento de autorización de Azure predeterminado ya no se incluye en client-go y kubectl. Con versiones posteriores, 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.

  4. Instale Azure Kubelogin:

  5. Kubelogin se puede usar para autenticarse con clústeres habilitados para Azure Arc solicitando un token de prueba de posesión (PoP). Convertir kubeconfig mediante para usar el modo de inicio de sesión adecuado. 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

  1. Ejecutar cualquier comando kubectl. Por ejemplo:

    • kubectl get nodes
    • kubectl get pods

  2. Una vez que se le solicite 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.

  3. Escriba el código impreso en la consola. Copie y pegue el código del terminal en la solicitud de autenticación del dispositivo.

  4. Escriba el nombre de usuario (testuser@mytenant.onmicrosoft.com) y la contraseña asociada.

  5. Si ve un mensaje de error similar al siguiente, significa que no está autorizado para acceder al recurso solicitado:

    Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.

    Un administrador debe crear una nueva asignación de roles para autorizar a este usuario el acceso al 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 elAcceso condicional para controlar el acceso al clúster.

Nota:

El acceso condicional de Microsoft Entra es una funcionalidad P2 de Microsoft Entra ID.

Para crear una directiva de acceso condicional de ejemplo para usarla con el clúster:

  1. En la parte superior de Azure Portal, busque y seleccione Microsoft Entra ID.

  2. En el menú de Microsoft Entra ID en el lado izquierdo, seleccione Aplicaciones empresariales.

  3. En el menú de aplicaciones empresariales del lado izquierdo, seleccione Acceso condicional.

  4. En el menú de acceso condicional del lado izquierdo, seleccione Directivas>Nueva directiva.

    Captura de pantalla que muestra cómo agregar una directiva de acceso condicional en Azure Portal.

  5. Escriba un nombre para la directiva, como arc-k8s-policy.

  6. Selecciona Usuarios y grupos En Incluir, elija Seleccionar usuarios y grupos. A continuación, elija los usuarios y grupos a los que quiere aplicar la directiva. En este ejemplo, elija el mismo grupo de Microsoft Entra que tiene acceso administrativo al clúster.

    Captura de pantalla que muestra la selección de usuarios o grupos para aplicar la directiva de acceso condicional.

  7. Seleccione Aplicaciones en la nube o acciones. En Incluir, elija Seleccionar aplicaciones. A continuación, busque y seleccione la aplicación de servidor que creó anteriormente.

    Captura de pantalla que muestra cómo seleccionar una aplicación de servidor en Azure Portal.

  8. En Controles de acceso, seleccione Conceder. Por ejemplo, seleccione Conceder acceso>Requerir que el dispositivo esté marcado como compatible.

    Captura de pantalla que muestra cómo permitir solo dispositivos compatibles en Azure Portal.

  9. En Habilitar directiva, seleccione Activar>Crear.

    Captura de pantalla que muestra cómo habilitar una directiva de acceso condicional en Azure Portal.

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

kubectl get nodes

Siga las instrucciones para iniciar sesión de nuevo. Un mensaje de error indica que inició sesión correctamente, pero el administrador requiere que el dispositivo que solicita acceso esté administrado mediante por Microsoft Entra ID para acceder al recurso. Siga estos pasos:

  1. En el Azure Portal, vaya a Microsoft Entra ID.

  2. Seleccione Aplicaciones empresariales. A continuación, en Actividad, seleccione Inicios de sesión.

  3. Una entrada en la parte superior muestra Error en Estado y Correcto en Acceso condicional. Seleccione la entrada y, a continuación, seleccione Acceso condicional en Detalles. Observe que se muestra su directiva de acceso condicional.

    Captura de pantalla que muestra una entrada de inicio de sesión con errores en Azure Portal.

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

Otra opción para el control de acceso al clúster es usar Privileged Identity Management (PIM) para las solicitudes Just-in-Time.

Nota:

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

Para configurar solicitudes de acceso Just-In-Time para el clúster, siga estos pasos:

  1. En la parte superior de Azure Portal, busque y seleccione Microsoft Entra ID.

  2. Anote el id. de inquilino. Para el resto de estas instrucciones, haremos referencia a ese id. como <tenant-id>.

    Captura de pantalla que muestra los detalles de Microsoft Entra ID en Azure Portal.

  3. En el menú de Microsoft Entra ID en el lado izquierdo, en Administrar, seleccione Grupos>Nuevo grupo.

  4. Asegúrese de que Seguridad está seleccionado para Tipo de grupo. Escriba el nombre de un grupo, como myJITGroup. En Roles de Microsoft Entra se pueden asignar a este grupo (versión preliminar),seleccione Sí. Por último, seleccione Crear.

    Captura de pantalla que muestra los detalles del nuevo grupo en Azure Portal.

  5. Se le redirigirá a la página Grupos. Seleccione el grupo recién creado y anote el id. de objeto. Para el resto de estas instrucciones, nos referiremos a este id. como <object-id>.

    Captura de pantalla que muestra el identificador de objeto del nuevo grupo en Azure Portal.

  6. De nuevo en Azure Portal, en el menú de Actividad de la izquierda, seleccione Privileged Access (Preview) (Acceso con privilegios [versión preliminar]). A continuación, seleccione Enable Privileged Access (Habilitar acceso con privilegios).

    Captura de pantalla que muestra las selecciones para habilitar el acceso con privilegios en Azure Portal.

  7. Seleccione Agregar asignaciones para empezar a conceder acceso.

    Captura de pantalla que muestra cómo agregar asignaciones activas en Azure Portal.

  8. Seleccione un rol de Miembro y elija los usuarios y grupos a los que desea conceder el acceso al clúster. Un administrador de grupo puede modificar estas asignaciones en cualquier momento. Elija Siguiente cuando esté listo para continuar.

    Captura de pantalla que muestra cómo agregar asignaciones en Azure Portal.

  9. Elija un tipo de asignación Activa, la duración deseada y especifique una justificación. Cuando esté listo para continuar, seleccione Asignar. Para más información sobre los tipos de asignación, consulte Asignación de la elegibilidad para un grupo de acceso con privilegios (versión preliminar) en Privileged Identity Management.

    Captura de pantalla que muestra las propiedades de asignación en Azure Portal.

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

Tenga en cuenta el requisito de autenticación y siga los pasos para autenticarse. Si la autenticación se realizó correctamente, debería ver una salida similar a esta:

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