Uso de identidades administradas por pods de Microsoft Entra en Azure Kubernetes Service (versión preliminar)

Artículo
10/26/2023

Las identidades administradas por pods de Microsoft Entra usan primitivas de Kubernetes para asociar identidades administradas para recursos de Azure e identidades en Microsoft Entra ID con pods. Los administradores crean identidades y enlaces como primitivas de Kubernetes que permiten a los pods acceder a los recursos de Azure que dependen de Microsoft Entra ID como proveedor de identidades.

Importante

Se recomienda que revise Microsoft Entra Workload ID. Este método de autenticación reemplaza la identidad administrada por pod (versión preliminar), que se integra con las funcionalidades nativas de Kubernetes para federarse con cualquier proveedor de identidades externo en beneficio de la aplicación.

La identidad administrada por pods de Microsoft Entra de código abierto (versión preliminar) en Azure Kubernetes Service quedó en desuso el 24/10/2022 y el proyecto se archivó en septiembre de 2023. Para obtener más información, consulte el aviso de desuso. El complemento administrado por AKS comienza a quedar en desuso en septiembre de 2024.

Para deshabilitar el complemento administrado de AKS, use el siguiente comando: az feature unregister --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview".

Antes de empezar

Debe tener instalada la versión 2.20.0 de la CLI de Azure, o cualquier versión posterior.

Limitaciones

Se permite un máximo de 200 identidades administradas por pods para un clúster.
Se permite un máximo de 200 excepciones de identidades administradas por pods para un clúster.
Las identidades administradas del pod solo están disponibles en grupos de nodos de Linux.
Esta característica solo se admite para clústeres respaldados por Virtual Machine Scale Sets.

Instalación de la versión preliminar de la extensión de la CLI de Azure en versión preliminar de AKS

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. 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 AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Ejecute el siguiente comando para instalar la extensión de versión preliminar de AKS:

az extension add --name aks-preview

Ejecute el siguiente comando para actualizar a la versión más reciente de la extensión publicada:

az extension update --name aks-preview

Registro de la marca de característica "EnablePodIdentityPreview"

Registre la marca de la característica EnablePodIdentityPreview con el comando EnablePodIdentityPreview, como se muestra en el siguiente ejemplo:

az feature register --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview"

Tarda unos minutos en que el estado muestre Registrado. Para comprobar el estado de registro se usa el comandoaz feature show:

az feature show --namespace "Microsoft.ContainerService" --name "EnablePodIdentityPreview"

Cuando aparezca el estado Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register:

az provider register --namespace Microsoft.ContainerService

Opciones del modo de funcionamiento

La identidad administrada de pod de Microsoft Entra admite dos modos de operación:

Modo estándar: en este modo, se implementan los dos componentes siguientes en el clúster de AKS:
- Controlador de identidades administradas (MIC): un MIC es un controlador de Kubernetes que busca cambios en los pods, en AzureIdentity y en AzureIdentityBinding mediante el servidor de API de Kubernetes. Cuando se detectan cambios importantes, el MIC agrega o elimina AzureAssignedIdentity según sea necesario. Específicamente, cuando se programa un pod, el Controlador de identidades administradas asigna la identidad administrada en Azure al conjunto de escalado de máquinas virtuales subyacente utilizado por el grupo de nodos durante la fase de creación. Cuando se eliminan todos los pods que usan la identidad, se quita la identidad del conjunto de escalado de máquinas virtuales del grupo de nodos, a menos que otros pods usen la misma identidad administrada. El MIC realiza acciones similares cuando se crea o elimina AzureIdentity o AzureIdentityBinding.
- Identidad administrada del nodo (NMI): la NMI es un pod que se ejecuta como DaemonSet en cada nodo del clúster de AKS. La NMI intercepta las solicitudes de token de seguridad a Azure Instance Metadata Service en cada nodo, las redirige a sí mismo y valida si el pod tiene acceso a la identidad para la que se solicita un token. Luego, captura el token del inquilino de Microsoft Entra en nombre de la aplicación.
Modo administrado: este modo solo ofrece la NMI. Cuando se instala a través del complemento de clúster de AKS, Azure administra la creación de primitivas de Kubernetes (AzureIdentity y AzureIdentityBinding) y la asignación de identidad en respuesta a los comandos de la CLI por parte del usuario. De lo contrario, si se instala a través del gráfico de Helm, el usuario debe asignar y administrar manualmente la identidad. Para obtener más información, consulte Identidad de pod en modo administrado.

Cuando se instala la identidad administrada por pods de Microsoft Entra mediante un gráfico de Helm o un manifiesto de YAML, tal y como se muestra en la Guía de instalación, se puede elegir entre los modos standard y managed. Si, en cambio, decide instalar la identidad administrada por pods de Microsoft Entra mediante el complemento de clúster de AKS, tal y como se muestra en este artículo, la configuración usará el modo managed.

Creación de un clúster de AKS con Azure Container Networking Interface (CNI)

Nota

Esta es la configuración recomendada predeterminada.

Cree un clúster de AKS con Azure CNI y una identidad administrada del pod habilitada. Los siguientes comandos usan az group create para crear un grupo de recursos denominado myResourceGroup y el comando az aks create para crear un clúster de AKS denominado myAKSCluster en el grupo de recursos myResourceGroup.

az group create --name myResourceGroup --location eastus
az aks create -g myResourceGroup -n myAKSCluster --enable-pod-identity --network-plugin azure

Use az aks get-credentials para iniciar sesión en el clúster de AKS. Este comando también descarga y configura el certificado de cliente kubectl en el equipo de desarrollo.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Nota

Al habilitar la identidad administrada del pod en el clúster de AKS, se agrega una excepción AzurePodIdentityException denominada aks-addon-exception al espacio de nombres kube-system. Una excepción AzurePodIdentityException permite que los pods con determinadas etiquetas accedan al punto de conexión de Azure Instance Metadata Service (IMDS) sin que el servidor de NMI los intercepte. aks-addon-exception permite que los complementos propios de AKS, como la identidad administrada por pods de Microsoft Entra, funcionen sin tener que configurar manualmente una excepción AzurePodIdentityException. También puede agregar, quitar y actualizar una excepción AzurePodIdentityException con az aks pod-identity exception add, az aks pod-identity exception delete, az aks pod-identity exception update o kubectl.

Actualización de un clúster de AKS existente con Azure CNI

Actualice un clúster de AKS existente con Azure CNI para incluir la identidad administrada del pod.

az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity

Uso del complemento de red de Kubenet con identidades administradas por pods de Microsoft Entra

Importante

La ejecución de la identidad administrada por pods de Microsoft Entra en un clúster con Kubenet no es una configuración recomendada debido a los problemas de seguridad. La configuración predeterminada de Kubenet no puede impedir la suplantación de identidad de ARP, que un pod podría usar para actuar como otro pod y obtener acceso a una identidad que no está previsto que tenga. Siga los pasos de mitigación y configure las directivas antes de habilitar la identidad administrada por pods de Microsoft Entra en un clúster con Kubenet.

Mitigación

Para mitigar la vulnerabilidad en el nivel de clúster, puede usar la directiva integrada de Azure "Los contenedores de clúster de Kubernetes solo deben usar funcionalidades permitidas" para limitar el ataque CAP_NET_RAW.

Adición de NET_RAW a "Funcionalidades de eliminación necesarias"

Si no usa Azure Policy, puede usar el controlador de admisión OpenPolicyAgent junto con el webhook de validación de Gatekeeper. Si ya tiene instalado Gatekeeper en el clúster, agregue un elemento ConstraintTemplate del tipo K8sPSPCapabilities:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/capabilities/template.yaml

Agregue una plantilla para limitar la generación de pods con la funcionalidad NET_RAW:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: prevent-net-raw
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - "kube-system"
  parameters:
    requiredDropCapabilities: ["NET_RAW"]

Creación de un clúster de AKS con el complemento de red Kubenet

Cree un clúster de AKS con complemento de red Kubenet y una identidad administrada del pod habilitada.

az aks create -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet

Actualización de un clúster de AKS existente con el complemento de red Kubenet

Actualice un clúster de AKS existente con el complemento de red Kubnet para incluir la identidad administrada por pods.

az aks update -g $MY_RESOURCE_GROUP -n $MY_CLUSTER --enable-pod-identity --enable-pod-identity-with-kubenet

Creación de una identidad

Importante

Debe tener los permisos pertinentes (por ejemplo, Propietario) en la suscripción para crear la identidad.

Cree una identidad que usará el pod de demostración con az identity create y establezca las variables IDENTITY_CLIENT_ID e IDENTITY_RESOURCE_ID.

az group create --name myIdentityResourceGroup --location eastus
export IDENTITY_RESOURCE_GROUP="myIdentityResourceGroup"
export IDENTITY_NAME="application-identity"
az identity create --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME}
export IDENTITY_CLIENT_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)"
export IDENTITY_RESOURCE_ID="$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)"

Asignación de permisos a la identidad administrada

Se deben otorgar a la identidad administrada que se asignará al pod, permisos que se alineen con las acciones que va a realizar.

Para ejecutar la demostración, la identidad administrada IDENTITY_CLIENT_ID debe tener permisos de colaborador de máquina virtual en el grupo de recursos que contiene el conjunto de escalado de máquinas virtuales del clúster de AKS.

# Obtain the name of the resource group containing the Virtual Machine Scale set of your AKS cluster, commonly called the node resource group
NODE_GROUP=$(az aks show -g myResourceGroup -n myAKSCluster --query nodeResourceGroup -o tsv)

# Obtain the id of the node resource group 
NODES_RESOURCE_ID=$(az group show -n $NODE_GROUP -o tsv --query "id")

# Create a role assignment granting your managed identity permissions on the node resource group
az role assignment create --role "Virtual Machine Contributor" --assignee "$IDENTITY_CLIENT_ID" --scope $NODES_RESOURCE_ID

Creación de una identidad de pod

Cree una identidad administrada por pods para el clúster mediante az aks pod-identity add.

export POD_IDENTITY_NAME="my-pod-identity"
export POD_IDENTITY_NAMESPACE="my-app"
az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME} --identity-resource-id ${IDENTITY_RESOURCE_ID}

Nota

El valor de "POD_IDENTITY_NAME" debe ser un nombre de subdominio DNS válido, tal como se define en RFC 1123.

Nota

Al asignar la identidad administrada por pods mediante pod-identity add, la CLI de Azure intenta conceder el rol de operador de identidad administrada para la identidad administrada por pods (IDENTITY_RESOURCE_ID) a la identidad del clúster.

Azure creará un recurso AzureIdentity en el clúster que represente la identidad en Azure y un recurso AzureIdentityBinding que conecte AzureIdentity a un selector. Puede ver estos recursos con

kubectl get azureidentity -n $POD_IDENTITY_NAMESPACE
kubectl get azureidentitybinding -n $POD_IDENTITY_NAMESPACE

Ejecución de una aplicación de ejemplo

Para que un pod use la identidad administrada por pods de Microsoft Entra, el pod necesitará una etiqueta aadpodidbinding con un valor que coincida con un selector de AzureIdentityBinding. El selector coincidirá con el nombre de la identidad administrada por pods de manera predeterminada, pero también se puede establecer mediante la opción --binding-selector al llamar a az aks pod-identity add.

Para ejecutar una aplicación de ejemplo mediante la identidad administrada por pods de Microsoft Entra, cree un archivo de demo.yaml con el siguiente contenido. Reemplace POD_IDENTITY_NAME, IDENTITY_CLIENT_ID e IDENTITY_RESOURCE_GROUP por los valores de los pasos anteriores. Reemplace SUBSCRIPTION_ID por su identificador de suscripción.

Nota

En los pasos anteriores, creó las variables POD_IDENTITY_NAME, IDENTITY_CLIENT_ID e IDENTITY_RESOURCE_GROUP. Puede usar un comando como echo para mostrar el valor establecido para las variables; por ejemplo, echo $POD_IDENTITY_NAME.

apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    aadpodidbinding: $POD_IDENTITY_NAME
spec:
  containers:
  - name: demo
    image: mcr.microsoft.com/oss/azure/aad-pod-identity/demo:v1.6.3
    args:
      - --subscriptionid=$SUBSCRIPTION_ID
      - --clientid=$IDENTITY_CLIENT_ID
      - --resourcegroup=$IDENTITY_RESOURCE_GROUP
    env:
      - name: MY_POD_NAME
        valueFrom:
          fieldRef:
            fieldPath: metadata.name
      - name: MY_POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MY_POD_IP
        valueFrom:
          fieldRef:
            fieldPath: status.podIP
  nodeSelector:
    kubernetes.io/os: linux

Observe que la definición del pod tiene una etiqueta aadpodidbinding con un valor que coincide con el nombre de la identidad administrada por pods que ha ejecutado az aks pod-identity add en el paso anterior.

Implemente demo.yaml en el mismo espacio de nombres que la identidad administrada por pods mediante kubectl apply:

kubectl apply -f demo.yaml --namespace $POD_IDENTITY_NAMESPACE

Compruebe que la aplicación de ejemplo se ejecuta correctamente con kubectl logs.

kubectl logs demo --follow --namespace $POD_IDENTITY_NAMESPACE

Compruebe que los registros muestran que un token se ha obtenido correctamente y que la operación GET es correcta.

...
successfully doARMOperations vm count 0
successfully acquired a token using the MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token)
successfully acquired a token, userAssignedID MSI, msiEndpoint(http://169.254.169.254/metadata/identity/oauth2/token) clientID(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
successfully made GET on instance metadata
...

Ejecución de una aplicación con varias identidades

Para permitir que una aplicación use varias identidades, establezca --binding-selector en el mismo selector al crear identidades de pod.

az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME_1} --identity-resource-id ${IDENTITY_RESOURCE_ID_1} --binding-selector myMultiIdentitySelector
az aks pod-identity add --resource-group myResourceGroup --cluster-name myAKSCluster --namespace ${POD_IDENTITY_NAMESPACE}  --name ${POD_IDENTITY_NAME_2} --identity-resource-id ${IDENTITY_RESOURCE_ID_2} --binding-selector myMultiIdentitySelector

Luego, establezca el campo aadpodidbinding del archivo YAML del pod en el selector de enlace que especificó.

apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    aadpodidbinding: myMultiIdentitySelector
...

Deshabilitación de la identidad administrada por pods en un clúster existente

Para deshabilitar la identidad administrada por pods en un clúster existente, quite las identidades administradas por pods del clúster. Después, deshabilite la característica en el clúster.

az aks pod-identity delete --name ${POD_IDENTITY_NAME} --namespace ${POD_IDENTITY_NAMESPACE} --resource-group myResourceGroup --cluster-name myAKSCluster

az aks update --resource-group myResourceGroup --name myAKSCluster --disable-pod-identity

Limpieza

Para quitar una identidad administrada por pods de Microsoft Entra del clúster, quite la aplicación de ejemplo y la identidad administrada por pods de dicho clúster. A continuación, quite la identidad y la asignación de roles de la identidad del clúster.

kubectl delete pod demo --namespace $POD_IDENTITY_NAMESPACE

az aks pod-identity delete --name ${POD_IDENTITY_NAME} --namespace ${POD_IDENTITY_NAMESPACE} --resource-group myResourceGroup --cluster-name myAKSCluster

az identity delete -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME}

az role assignment delete --role "Managed Identity Operator" --assignee "$IDENTITY_CLIENT_ID" --scope "$IDENTITY_RESOURCE_ID"

Pasos siguientes

Para más información sobre las identidades administradas, consulte Identidades administradas para recursos de Azure.

Uso de identidades administradas por pods de Microsoft Entra en Azure Kubernetes Service (versión preliminar)

Antes de empezar

Limitaciones

Instalación de la versión preliminar de la extensión de la CLI de Azure en versión preliminar de AKS

Registro de la marca de característica "EnablePodIdentityPreview"

Opciones del modo de funcionamiento

Creación de un clúster de AKS con Azure Container Networking Interface (CNI)

Actualización de un clúster de AKS existente con Azure CNI

Uso del complemento de red de Kubenet con identidades administradas por pods de Microsoft Entra

Mitigación

Creación de un clúster de AKS con el complemento de red Kubenet

Actualización de un clúster de AKS existente con el complemento de red Kubenet

Creación de una identidad

Asignación de permisos a la identidad administrada

Creación de una identidad de pod

Ejecución de una aplicación de ejemplo

Ejecución de una aplicación con varias identidades

Deshabilitación de la identidad administrada por pods en un clúster existente

Limpieza

Pasos siguientes

Recursos adicionales