Uso de identidades administradas por pods de Microsoft Entra en Azure Kubernetes Service (versión preliminar)
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 de identidad de pod de AKS se revisará y se admitirá a través de septiembre de 2025 para permitir que los clientes pasen al Id. de carga de trabajo de Microsoft Entra
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 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 \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-pod-identity \
--network-plugin azure \
--generate-ssh-keys
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 --resource-group $MY_RESOURCE_GROUP --name $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 \
--resource-group $MY_RESOURCE_GROUP \
--name $MY_CLUSTER \
--enable-pod-identity \
--enable-pod-identity-with-kubenet \
--generate-ssh-keys
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 --resource-group $MY_RESOURCE_GROUP --name $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 --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME} --query clientId -o tsv)"
export IDENTITY_RESOURCE_ID="$(az identity show --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${IDENTITY_NAME} --query id -o tsv)"
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 --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
# Obtain the id of the node resource group
NODES_RESOURCE_ID=$(az group show --name $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 --resource-group ${IDENTITY_RESOURCE_GROUP} --name ${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.
Azure Kubernetes Service