Compartir a través de

Integración de Microsoft Entra ID con Azure Kubernetes Service (AKS) mediante la CLI de Azure (heredado)

  • Artículo

Advertencia

La característica descrita en este documento, Integración de Microsoft Entra (heredado), quedó en desuso el 1 de junio de 2023. En este momento, no se podrán crear nuevos clústeres con Integración de Microsoft Entra (heredado).

AKS tiene una nueva experiencia mejorada de Microsoft Entra ID administrado por AKS que no requiere que administre las aplicaciones cliente o de servidor. Si desea migrar, siga las instrucciones aquí.

Es posible configurar Azure Kubernetes Service (AKS) para que utilice Microsoft Entra ID para la autenticación de usuarios. En esta configuración, puede iniciar sesión en un clúster de AKS mediante un token de autenticación de Microsoft Entra. Los operadores del clúster también pueden configurar el control de acceso basado en roles de Kubernetes (RBAC de Kubernetes) en función de la identidad de los usuarios o su pertenencia a un grupo del directorio.

En este artículo se muestra cómo crear los componentes necesarios de Microsoft Entra y, luego, implementar un clúster habilitado para Microsoft Entra ID y crear un rol básico de Kubernetes en el clúster de AKS.

Limitaciones

  • Microsoft Entra ID solo puede habilitarse en el clúster habilitado para Kubernetes.
  • El servicio de integración heredado de Microsoft Entra solo se puede habilitar durante la creación del clúster.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.0.61 de la CLI de Azure u otra versión posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Vaya a https://shell.azure.com para abrir Cloud Shell en el explorador.

Para mantener la coherencia y ayudar a ejecutar los comandos en este artículo, cree una variable para el nombre que quiera del clúster de AKS. En el ejemplo siguiente se usa el nombre myakscluster:

aksname="myakscluster"

Información general sobre la autenticación de Microsoft Entra

La autenticación de Microsoft Entra se proporciona a los clústeres de AKS con OpenID Connect. OpenID Connect es una capa de identidad creada basándose en el protocolo OAuth 2.0. Puede encontrar más información sobre OpenID Connect en la documentación de OpenID Connect.

Dentro del clúster de Kubernetes, se usa la autenticación de token de webhook para verificar los tokens de autenticación. La autenticación de token de webhook se configura y administra como parte del clúster de AKS. Puede encontrar más información sobre la autenticación de token de Webhook en la documentación de autenticación de webhook.

Nota:

Al configurar Microsoft Entra ID para la autenticación de AKS, se configuran dos aplicaciones de Microsoft Entra. Un administrador del inquilino de Azure debe realizar esta operación.

Crear un componente de servidor de Microsoft Entra

Para integrar con AKS, cree y use una aplicación de Microsoft Entra que sirva de punto de conexión para las solicitudes de identidad. La primera aplicación de Microsoft Entra que necesita obtiene la pertenencia a grupos de Microsoft Entra para un usuario.

Cree el componente de aplicación de servidor mediante el comando az ad app create y, a continuación, actualice las notificaciones de pertenencia a grupo mediante el comando az ad app update. En el ejemplo siguiente se usa la variable aksname definida en la sección Antes de comenzar y se crea una variable.

# Create the Azure AD application
serverApplicationId=$(az ad app create \
    --display-name "${aksname}Server" \
    --identifier-uris "https://${aksname}Server" \
    --query appId -o tsv)

# Update the application group membership claims
az ad app update --id $serverApplicationId --set groupMembershipClaims=All

Ahora, cree una entidad de servicio para la aplicación de servidor mediante el comando az ad sp create. Esta entidad de servicio se usa para autenticarse en la plataforma Azure. A continuación, obtenga el secreto de la entidad de servicio con el comando az ad sp credential reset y asígnelo a la variable llamada serverApplicationSecret para su uso en uno de los pasos siguientes:

# Create a service principal for the Azure AD application
az ad sp create --id $serverApplicationId

# Get the service principal secret
serverApplicationSecret=$(az ad sp credential reset \
    --name $serverApplicationId \
    --credential-description "AKSPassword" \
    --query password -o tsv)

La entidad de servicio de Microsoft Entra necesita permisos para realizar las siguientes acciones:

  • Leer datos de directorio
  • Iniciar sesión y leer el perfil de usuario

Asigne estos permisos con el comando az ad app permission add:

az ad app permission add \
    --id $serverApplicationId \
    --api 00000003-0000-0000-c000-000000000000 \
    --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope 06da0dbc-49e2-44d2-8312-53f166ab848a=Scope 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role

Por último, conceda los permisos asignados en el paso anterior para la aplicación de servidor con el comando az ad app permission grant. Se producirá un error en este paso si la cuenta actual no es un administrador del inquilino. También tendrá que agregar permisos para que la aplicación de Microsoft Entra solicite información que, de lo contrario, podría requerir consentimiento administrativo mediante el comando az ad app permission admin-consent:

az ad app permission grant --id $serverApplicationId --api 00000003-0000-0000-c000-000000000000
az ad app permission admin-consent --id  $serverApplicationId

Crear un componente cliente de Microsoft Entra

La segunda aplicación de Microsoft Entra se usa cuando un usuario inicia sesión en el clúster de AKS con la CLI de Kubernetes (kubectl). Esta aplicación cliente toma la solicitud de autenticación del usuario y comprueba sus credenciales y permisos. Cree la aplicación de Microsoft Entra para el componente de cliente mediante el comando az ad app create:

clientApplicationId=$(az ad app create \
    --display-name "${aksname}Client" \
    --native-app \
    --reply-urls "https://${aksname}Client" \
    --query appId -o tsv)

Cree una entidad de servicio para la aplicación cliente mediante el comando az ad sp create:

az ad sp create --id $clientApplicationId

Obtenga el id. de oAuth2 para la aplicación de servidor con el fin de permitir el flujo de autenticación entre los dos componentes de las aplicaciones mediante el comando az ad app show. Este id. de oAuth2 se usa en el paso siguiente.

oAuthPermissionId=$(az ad app show --id $serverApplicationId --query "oauth2Permissions[0].id" -o tsv)

Agregue los permisos para los componentes de la aplicación cliente y la aplicación de servidor con el fin de usar el flujo de comunicación de oAuth2 mediante el comando az ad app permission add. A continuación, conceda permisos para que la aplicación cliente se comunique con la aplicación de servidor mediante el comando az ad app permission grant:

az ad app permission add --id $clientApplicationId --api $serverApplicationId --api-permissions ${oAuthPermissionId}=Scope
az ad app permission grant --id $clientApplicationId --api $serverApplicationId

Implementación del clúster

Con las dos aplicaciones de Microsoft Entra creadas, cree ahora el propio clúster de AKS. En primer lugar, cree un grupo de recursos con el comando az group create. En el ejemplo siguiente se crea un grupo de recursos en la región EastUS:

Cree un grupo de recursos para el clúster:

az group create --name myResourceGroup --location EastUS

Obtenga el identificador de inquilino de la suscripción de Azure mediante el comando az account show. Después, cree el clúster de AKS con el comando az aks create. El comando para crear el clúster de AKS proporciona los identificadores de servidor y aplicación cliente, el secreto de entidad de servicio de la aplicación de servidor y el identificador de inquilino:

tenantId=$(az account show --query tenantId -o tsv)

az aks create \
    --resource-group myResourceGroup \
    --name $aksname \
    --node-count 1 \
    --generate-ssh-keys \
    --aad-server-app-id $serverApplicationId \
    --aad-server-app-secret $serverApplicationSecret \
    --aad-client-app-id $clientApplicationId \
    --aad-tenant-id $tenantId

Por último, obtenga las credenciales de administrador del clúster mediante el comando az aks get-credentials. En uno de los siguientes pasos, obtendrá las credenciales del clúster del usuario normal para ver el flujo de autenticación de Microsoft Entra en acción.

az aks get-credentials --resource-group myResourceGroup --name $aksname --admin

Creación de un enlace RBAC de Kubernetes

Para poder usar una cuenta de Microsoft Entra con el clúster AKS, debe crear un enlace de rol o un enlace de rol del clúster. Roles define los permisos para conceder, y enlaces los aplica a los usuarios deseados. Estas asignaciones se pueden aplicar a un espacio de nombres especificado o a todo el clúster. Para obtener más información, consulte Uso de la autorización de RBAC de Kubernetes.

Obtenga el nombre principal de usuario (UPN) para el usuario con sesión iniciada actualmente mediante el comando az ad signed-in-user show. Esta cuenta de usuario está habilitada para la integración de Microsoft Entra en el paso siguiente.

az ad signed-in-user show --query userPrincipalName -o tsv

Importante

Si el usuario al que concede el enlace de RBAC de Kubernetes se encuentra en el mismo inquilino de Microsoft Entra, asigne permisos según userPrincipalName. Si el usuario se encuentra en un inquilino distinto de Microsoft Entra, en su lugar, consulte y use la propiedad objectId.

Cree un manifiesto de YAML llamado basic-azure-ad-binding.yaml y pegue el siguiente contenido. En la última línea, reemplace userPrincipalName_or_objectId por la salida del id. de objeto o de UPN del comando anterior:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: contoso-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: userPrincipalName_or_objectId

Cree ClusterRoleBinding mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:

kubectl apply -f basic-azure-ad-binding.yaml

Acceder al clúster con Microsoft Entra ID

Ahora vamos a probar la integración de la autenticación de Microsoft Entra para el clúster de AKS. Establezca el contexto de configuración kubectl para usar las credenciales de usuario normal. Este contexto devuelve todas las solicitudes de autenticación a través de Microsoft Entra ID.

az aks get-credentials --resource-group myResourceGroup --name $aksname --overwrite-existing

Ahora use el comando kubectl get pods para ver los pods en los espacios de nombres:

kubectl get pods --all-namespaces

Recibirá un símbolo del sistema de inicio de sesión para autenticarse con las credenciales de Microsoft Entra mediante un explorador web. Una vez se haya autenticado correctamente, el comando kubectl muestra los pods del clúster de AKS, tal como se muestra en la salida del ejemplo siguiente:

kubectl get pods --all-namespaces

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

NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kube-system   coredns-754f947b4-2v75r                 1/1     Running   0          23h
kube-system   coredns-754f947b4-tghwh                 1/1     Running   0          23h
kube-system   coredns-autoscaler-6fcdb7d64-4wkvp      1/1     Running   0          23h
kube-system   heapster-5fb7488d97-t5wzk               2/2     Running   0          23h
kube-system   kube-proxy-2nd5m                        1/1     Running   0          23h
kube-system   kube-svc-redirect-swp9r                 2/2     Running   0          23h
kube-system   kubernetes-dashboard-847bb4ddc6-trt7m   1/1     Running   0          23h
kube-system   metrics-server-7b97f9cd9-btxzz          1/1     Running   0          23h
kube-system   tunnelfront-6ff887cffb-xkfmq            1/1     Running   0          23h

El token de autenticación recibido para kubectl se almacena en caché. Solo se le solicita de nuevo iniciar sesión cuando el token ha expirado o el archivo de configuración de Kubernetes se vuelve a crear.

Si ve un mensaje de error de autorización una vez se haya registrado correctamente en un explorador web, tal como se muestra en la salida del ejemplo siguiente, compruebe las siguientes incidencias posibles:

error: You must be logged in to the server (Unauthorized)
  • Se ha definido el identificador o UPN del objeto adecuado, en función de si la cuenta de usuario está en el mismo inquilino de Microsoft Entra o no.
  • El usuario no es miembro de más de 200 grupos.
  • El secreto definido en el registro de aplicación del servidor coincide con el valor configurado mediante --aad-server-app-secret
  • Asegúrese de que solo hay una versión de kubectl instalada en la máquina a la vez. Las versiones en conflicto pueden causar problemas durante la autorización. Para instalar la versión más reciente, use az aks install-cli.

Preguntas más frecuentes sobre la migración de Integración de Microsoft Entra a Microsoft Entra ID administrado por AKS

1. ¿Cuál es el plan para la migración?

La Integración de Microsoft Entra (heredado) quedará en desuso el 1 de junio de 2023. Después de esta fecha, no podrá crear nuevos clústeres con Microsoft Entra ID (heredado). Migraremos todos los clústeres de AKS de Integración de Microsoft Entra (heredado) a Microsoft Entra ID administrado por AKS automáticamente a partir del 1 de agosto de 2023. Se envían correos electrónicos de notificación a los administradores de suscripciones afectados de forma semanal para recordarles la migración.

2. ¿Qué ocurrirá si no realizo ninguna acción?

Los clústeres de AKS de Integración de Microsoft Entra (heredado) seguirán funcionando después del 1 de junio de 2023. Migraremos automáticamente los clústeres a Microsoft Entra ID administrado por AKS a partir del 1 de agosto de 2023. Puede experimentar tiempo de inactividad del servidor de API durante la migración.

El contenido de kubeconfig cambiará después de la migración. Deberá combinar las nuevas credenciales en el archivo kubeconfig mediante az aks get-credentials --resource-group <AKS resource group name> --name <AKS cluster name>.

Se recomienda actualizar el clúster de AKS a Microsoft Entra ID administrado por AKS manualmente antes del 1 de agosto. De este modo, podrá administrar el tiempo de inactividad durante las horas no laborables cuando sea más conveniente.

3. ¿Por qué todavía recibo el correo electrónico de notificación después de la migración manual?

El correo electrónico tarda varios días en enviarse. Si el clúster no se migró antes de iniciar el proceso de envío de correo electrónico, es posible que todavía reciba una notificación.

4. ¿Cómo puedo comprobar si mi clúster se migra a Microsoft Entra ID administrado por AKS?

Confirme que el clúster de AKS se migra a Microsoft Entra ID administrado por AKS mediante el comando az aks show.

az aks show -g <RGName> -n <ClusterName>  --query "aadProfile"

Si el clúster usa Microsoft Entra ID administrado por AKS, la salida muestra managed es true. Por ejemplo:

    {
      "adminGroupObjectIDs": [
        "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      ],
      "adminUsers": null,
      "clientAppId": null,
      "enableAzureRbac": null,
      "managed": true,
      "serverAppId": null,
      "serverAppSecret": null,
      "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }

Pasos siguientes

Para obtener el script completo que contiene los comandos que se muestran en este artículo, consulte el [script de integración de Microsoft Entra en el repositorio de ejemplos de AKS][complete-script].

Para usar los usuarios y grupos de Microsoft Entra con el fin de controlar el acceso a los recursos de clúster, consulte Control del acceso a recursos de clúster mediante el control de acceso basado en rol de Kubernetes y las identidades de Microsoft Entra en AKS.

Para obtener más información sobre cómo proteger los clústeres de Kubernetes, consulte Opciones de acceso e identificación para AKS.

Para ver procedimientos recomendados sobre el control de recursos e identidades, consulte Procedimientos recomendados para la autenticación y autorización en AKS.