Uso de la autorización de Microsoft Entra ID para la API de Kubernetes en Azure Kubernetes Service (AKS)

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

En este artículo se muestra cómo autorizar llamadas a la API de Kubernetes en Azure Kubernetes Service (AKS) mediante identidades de Microsoft Entra ID. La autorización de Microsoft Entra ID para la API de Kubernetes usa las asignaciones de roles de Azure RBAC para conceder acceso a los recursos de Kubernetes. Para los recursos integrados de Kubernetes, asigne uno de los roles integrados de AKS (como Azure Kubernetes Service RBAC Reader) en el ámbito del clúster o del espacio de nombres. En el caso de los recursos personalizados (CRD), asigne un rol personalizado con condiciones de Azure ABAC que especifiquen a qué grupos o tipos de CRD puede acceder el receptor. Las dos asignaciones de roles están compuestas por: una concede acceso a los recursos estándar de Kubernetes y la otra concede acceso condicional a recursos personalizados concretos.

Para la mayoría de las cargas de trabajo de producción, AKS Automático es la configuración predeterminada recomendada y lista para producción de AKS. Los clústeres automáticos de AKS están preconfigurados con Azure RBAC para la autorización de Kubernetes, por lo que puede centrarse en asignar las asignaciones de roles de Microsoft Entra adecuadas a usuarios, grupos y entidades de servicio.

Para obtener información general conceptual sobre las opciones de autorización de API de Kubernetes disponibles en AKS, consulte Conceptos de autorización de clústeres.

Prerequisites

• Necesita la versión 2.24.0 o posterior de la CLI de Azure instalada y configurada. Ejecute az --version para encontrar la versión. Si necesita instalar o actualizar, consulte Install CLI de Azure.
• Necesita kubectl, con una versión mínima de 1.18.3.
• Necesita tener habilitada la integración administrada de Microsoft Entra en el clúster para poder agregar la autorización de Microsoft Entra ID para la API de Kubernetes. Si necesita habilitar la integración administrada de Microsoft Entra, consulte Uso de Microsoft Entra ID en AKS.
• Las nuevas asignaciones de roles pueden tardar hasta cinco minutos en propagarse y actualizarse mediante el servidor de autorización.
• La autorización de Microsoft Entra ID para la API de Kubernetes requiere que el tenant de Microsoft Entra configurado para la autenticación sea el mismo que el tenant de la suscripción que aloja su clúster de AKS.

Comportamiento del modo de clúster de AKS

Creación de un clúster de AKS con integración de Microsoft Entra administrada y autorización de Microsoft Entra ID

AKS Automatic (recomendado para cargas de trabajo de producción)

Para las nuevas cargas de trabajo de producción, use AKS Automatic. Azure RBAC para la autorización de Kubernetes está preconfigurado en clústeres automáticos de AKS.

1. Cree un clúster automático de AKS siguiendo Creación de un clúster automático de Azure Kubernetes Service (AKS).

2. Opcional: compruebe que Azure RBAC para la autorización de Kubernetes está habilitada en el clúster mediante el az aks show comando .

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   az aks show \
     --resource-group $RESOURCE_GROUP \
     --name $CLUSTER_NAME \
     --query "aadProfile.enableAzureRbac" \
     --output tsv
   

AKS Standard

1. Cree un grupo de recursos de Azure con el comando az group create.

   export RESOURCE_GROUP=<resource-group-name>
   export LOCATION=<azure-region>
   
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. Cree un clúster AKS Standard con integración administrada de Microsoft Entra y autorización de Microsoft Entra ID mediante el comando az aks create.

   export CLUSTER_NAME=<cluster-name>
   
   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --enable-aad \
       --enable-azure-rbac \
       --generate-ssh-keys
   

   El resultado debería ser similar al ejemplo siguiente:

   "AADProfile": {
       "adminGroupObjectIds": null,
       "clientAppId": null,
       "enableAzureRbac": true,
       "managed": true,
       "serverAppId": null,
       "serverAppSecret": null,
       "tenantId": "****-****-****-****-****"
   }
   

Habilitación de la autorización de Microsoft Entra ID en un clúster de AKS existente

Para los clústeres estándar de AKS existentes, habilite la autorización de Microsoft Entra ID para la API de Kubernetes mediante el comando az aks update con la marca --enable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Enable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

Los clústeres automáticos de AKS ya tienen Azure RBAC para la autorización de Kubernetes preconfigurada. No es necesario ejecutar --enable-azure-rbac para AKS Automatic.

Roles integrados de AKS

AKS proporciona los siguientes roles integrados:

Creación de asignaciones de roles para el acceso al clúster

Creación de definiciones de roles personalizados

Para los recursos integrados de Kubernetes, las definiciones de roles personalizadas hacen referencia a la acción de grupo de API correspondiente en Microsoft.ContainerService/managedClusters/. En el ejemplo siguiente se permite que un usuario solo lea las implementaciones y nada más. Para obtener la lista completa de posibles acciones, consulte Operaciones de Microsoft.ContainerService.

Para los recursos personalizados, el rol personalizado debe conceder la acción de datos aplicable del recurso personalizado, como Microsoft.ContainerService/managedClusters/customresources/read. Un rol personalizado por sí solo no filtra el acceso por grupo o tipo de definición de recursos personalizados (CRD). Para aplicar ese filtrado, agregue una condición de Azure ABAC a la asignación de roles. Para obtener el procedimiento completo, consulte Restricción del acceso a recursos personalizados mediante condiciones de ABAC.

1. Para crear sus propias definiciones de roles personalizados, copie el siguiente archivo, reemplace por su propio identificador de suscripción y guárdelo <YOUR-SUBSCRIPTION-ID> como deploy-view.json.

   {
       "Name": "AKS Deployment Reader",
       "Description": "Lets you view all deployments in cluster/namespace.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/apps/deployments/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Cree la definición de roles mediante el comando az role definition create y establezca el --role-definition al archivo deploy-view.json que creó en el paso anterior.

   az role definition create --role-definition @deploy-view.json 
   

3. Asigne la definición de roles a un usuario u otra identidad mediante el az role assignment create comando .

       # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS Deployment Reader role
   az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
   

Restricción del acceso a recursos personalizados mediante condiciones de ABAC (versión preliminar)

Las condiciones de ABAC permiten filtrar las asignaciones de roles de Microsoft Entra ID a grupos y tipos específicos de recursos personalizados (CRD), de forma centralizada desde Microsoft Entra ID, sin escribir manifiestos de Kubernetes RBAC Role y RoleBinding para cada clúster. Para obtener información sobre Azure ABAC, consulte ¿Qué son Azure condiciones de asignación de roles?

Cuándo usar condiciones de ABAC

Use esta característica cuando desee:

• Restringe qué grupos o tipos de CRD puede enumerar o obtener un asignado.
• Aplique de forma centralizada límites de acceso a recursos personalizados desde Microsoft Entra ID sin necesidad de gestionar RBAC de Kubernetes Role ni objetos RoleBinding en cada clúster.
• Distinguir entre los CRD publicados por diferentes operadores (por ejemplo, permitir secrets-store.csi.x-k8s.io al bloquear security.istio.io).

Atributos de condición disponibles

Los siguientes atributos de solicitud están disponibles al crear condiciones para la API de Kubernetes en un clúster de AKS:

Agregar una condición de ABAC a una asignación de roles

En el ejemplo siguiente se crea un rol personalizado AKS CRD Reader que otorga acceso de lectura a los recursos personalizados. A continuación, asigna el rol con una condición que solo permite acceder a secretproviderclasses en el grupo secrets-store.csi.x-k8s.io (el CRD que usa el proveedor de Azure Key Vault para Secrets Store CSI Driver).

1. Guarde la siguiente definición de rol en un archivo denominado crd-reader.json, reemplazando <YOUR-SUBSCRIPTION-ID> por su propio identificador de suscripción.

   {
       "Name": "AKS CRD Reader",
       "Description": "Lets you read custom resources in the cluster.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/customresources/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR-SUBSCRIPTION-ID>"
       ]
   }
   

2. Cree la definición de roles mediante el az role definition create comando .

   az role definition create --role-definition @crd-reader.json
   

3. Guarde la siguiente condición en un archivo denominado abac-condition.txt. La condición permite que las lecturas que no sean de recursos personalizados pasen sin cambios y restringen las lecturas de recursos personalizados a un grupo y un tipo específicos.

   (
    (
     !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
    )
    OR
    (
     @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
     AND
     @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
    )
   )
   

4. Cree la asignación de roles con la condición utilizando el comando az role assignment create.

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the AKS resource ID
   AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
   
   # Create a role assignment for the AKS CRD Reader role with an ABAC condition
   az role assignment create \
       --role "AKS CRD Reader" \
       --assignee <AAD-ENTITY-ID> \
       --scope $AKS_ID \
       --condition "$(cat abac-condition.txt)" \
       --condition-version "2.0" \
       --description "Allow reads on SecretProviderClass resources only"
   

También puede agregar una condición a través de Azure Portal. En la página Agregar asignación de roles , seleccione la pestaña Condiciones y, a continuación, seleccione Agregar condición y use el editor visual para compilar la expresión.

Comprobación de la condición

Después de que la asignación de roles se propague (hasta cinco minutos), inicie sesión como asignado y confirme que el asignado puede leer el CRD permitido, pero no los demás CRD.

1. Obtenga las credenciales del clúster mediante el az aks get-credentials comando .

   # Set environment variables
   export RESOURCE_GROUP=<resource-group-name>
   export CLUSTER_NAME=<cluster-name>
   
   # Get the cluster credentials
   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

2. Lista secretproviderclasses del grupo secrets-store.csi.x-k8s.io, que la condición permite. El comando debe realizarse correctamente y devolver los recursos existentes o una lista vacía (o un error no encontrado si el CRD no está instalado en el clúster).

   kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
   

3. Lista authorizationpolicies del grupo Istio security.istio.io, que la condición bloquea. El comando debería fallar con un error Forbidden del webhook de autorización de Microsoft Entra ID (suponiendo que el CRD de Istio esté instalado en el clúster; de lo contrario, kubectl devuelve un error de tipo «no encontrado» antes de que el servidor API llegue al webhook de autorización).

   kubectl get authorizationpolicies.security.istio.io --all-namespaces
   

Limpieza de recursos

Deshabilitar la autorización de Microsoft Entra ID

Elimina la autorización de Microsoft Entra ID mediante el comando az aks update con el indicador --disable-azure-rbac.

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>
export CLUSTER_NAME=<cluster-name>

# Disable Microsoft Entra ID authorization for the Kubernetes API
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

Eliminación de asignaciones de roles

Eliminación de definiciones de roles

Elimine una definición de rol personalizada mediante el az role definition delete comando .

az role definition delete --name "AKS Deployment Reader"

Eliminación del grupo de recursos y el clúster de AKS

# Set environment variables
export RESOURCE_GROUP=<resource-group-name>

# Delete the resource group and all resources in it
az group delete --name $RESOURCE_GROUP --yes --no-wait

Contenido relacionado

Para más información sobre AKS, consulte los artículos siguientes:

• ¿Qué es AKS Automatic?
• Creación de un clúster automático de AKS
• Conceptos de autorización de clústeres para AKS
• Opciones de acceso e identidad para AKS
• ¿Qué es Azure RBAC?
• ¿Qué son las condiciones de Azure ABAC?
• Operaciones de Microsoft.ContainerService