Uso de Azure RBAC en clústeres de Kubernetes habilitados para Azure Arc (versión preliminar)

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

Importante

Las características en versión preliminar de Kubernetes habilitado para Azure Arc están disponibles en autoservicio y de manera opcional. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de Kubernetes habilitadas para Azure Arc reciben cobertura parcial del soporte al cliente en la medida de lo posible.

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:

No puede configurar esta característica para Red Hat OpenShift ni para ofertas de Kubernetes administradas de proveedores de nube como Elastic Kubernetes Service o Google Kubernetes Engine, donde el usuario no tiene acceso al servidor de API del clúster. 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.

Configurar aplicaciones de Microsoft Entra

Creación de una aplicación de servidor

  1. Cree una nueva aplicación de Microsoft Entra y obtenga su valor de appId. Este valor se usa en pasos posteriores como serverApplicationId.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. Para conceder permisos de la API "Iniciar sesión y leer el perfil del usuario" a la aplicación de servidor, copie este JSON y guárdelo en un archivo denominado oauth2-permissions.json:

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. Actualice las notificaciones de pertenencia a grupos de aplicaciones. Ejecute los comandos en el mismo directorio que el archivo oauth2-permissions.json. RBAC para Kubernetes habilitado para Azure Arc requiere que signInAudience se establezca como AzureADMyOrg:

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. Cree una entidad de servicio y obtenga el valor de su campo password. Este valor es necesario más adelante como serverApplicationSecret al habilitar esta característica en el clúster. Este secreto es válido durante 1 año de forma predeterminada y deberá rotarse una vez transcurrido ese tiempo. Para establecer una duración personalizada de la expiración, use az ad sp credential reset:

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. Conceda los permisos de API "Iniciar sesión y leer perfil de usuario" a la aplicación mediante az ad app permission:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Nota:

    Un administrador de aplicaciones de Azure tiene que ejecutar este paso.

    Para usar esta característica en producción, se recomienda crear una aplicación de servidor diferente para cada clúster.

Creación de una aplicación cliente

  1. Cree una nueva aplicación de Microsoft Entra y obtenga su valor de appId. Este valor se usa en pasos posteriores como clientApplicationId.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. Cree una entidad de servicio para esta aplicación cliente:

    az ad sp create --id "${CLIENT_APP_ID}"

  3. Obtenga el valor de oAuthPermissionId para la aplicación de servidor:

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. Conceda los permisos necesarios para la aplicación cliente. RBAC para Kubernetes habilitado para Azure Arc requiere que signInAudience se establezca como AzureADMyOrg:

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

Creación de una asignación de roles para la aplicación de servidor

La aplicación de servidor necesita los permisos Microsoft.Authorization/*/read para poder confirmar que el usuario que realiza la solicitud está autorizado en los objetos de Kubernetes que se incluyen en la solicitud.

  1. Cree un archivo denominado accessCheck.json con el siguiente contenido:

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    Reemplace <subscription-id> por el id. de suscripción real.

  2. Ejecute el siguiente comando para crear el nuevo rol personalizado:

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. Cree una asignación de roles en la aplicación de servidor como assignee mediante el rol que ha creado:

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

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

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 --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

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:

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

    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:

    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.

  1. Instale Azure Kubelogin:

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

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.

    Screenshot showing how to add a conditional access policy in the 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.

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  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.

    Screenshot showing how to select a server application in the Azure portal.

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

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. En Habilitar directiva, seleccione Activar>Crear.

    Screenshot showing how to enable a conditional access policy in the 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.

    Screenshot showing a failed sign-in entry in the 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>.

    Screenshot showing Microsoft Entra ID details in the 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.

    Screenshot showing details for the new group in the 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>.

    Screenshot showing the object ID for the new group in the 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).

    Screenshot showing selections for enabling privileged access in the Azure portal.

  7. Seleccione Agregar asignaciones para empezar a conceder acceso.

    Screenshot showing how to add active assignments in the 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.

    Screenshot showing how to add assignments in the 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.

    Screenshot showing assignment properties in the 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

Actualización del secreto de la aplicación de servidor

Si el secreto de la entidad de servicio de la aplicación de servidor ha expirado, tiene que rotarlo.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Actualice el secreto en el clúster. Incluya los parámetros opcionales que configuró cuando se ejecutó originalmente el comando.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Pasos siguientes