Migración de la identidad administrada del pod a la identidad de carga de trabajo

Este artículo se centra en la migración desde identidades administradas por pods a Microsoft Entra Workload ID del clúster de Azure Kubernetes Service (AKS). También proporciona instrucciones en función de la versión de la biblioteca cliente de Azure Identity usada por la aplicación basada en contenedores.

Si no está familiarizado con Microsoft Entra Workload ID, consulte el siguiente artículo de información general.

Antes de empezar

La versión 2.47.0 de la CLI de Azure, o cualquier versión posterior. Ejecute az --version para buscar la versión y ejecute az upgrade para actualizar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Escenarios de migración

En esta sección se explican las opciones de migración disponibles en función de la versión del SDK de Identidad de Azure instalada.

En cualquier escenario, debe tener configurada la confianza federada antes de actualizar la aplicación para que use la identidad de carga de trabajo. Estos son los pasos mínimos necesarios:

• Cree una credencial de identidad administrada.
• Asocie la identidad administrada a la cuenta de servicio de Kubernetes ya utilizada para la identidad administrada por pod o cree una nueva cuenta de servicio de Kubernetes y, a continuación, asóciela a la identidad administrada.
• Establezca una relación de confianza federada entre la identidad administrada y Microsoft Entra ID.

Migración desde la versión más reciente

Si la aplicación ya usa la versión más reciente del SDK de Azure Identity, realice los pasos siguientes para completar la configuración de autenticación:

• Implemente la identidad de carga de trabajo en paralelo con la identidad administrada por pods. Puede reiniciar la implementación de la aplicación para empezar a usar la identidad de carga de trabajo, donde inserta automáticamente las anotaciones de OIDC en la aplicación.
• Después de comprobar que la aplicación puede autenticarse correctamente, puede quitar las anotaciones de identidad administrada por pods de la aplicación y, a continuación, quitar el complemento de identidad administrada por pods.

Migración desde una versión anterior

Si la aplicación no usa la versión más reciente del SDK de Identidad de Azure, tiene dos opciones:

• Puede usar un Sidecar de migración que proporcionamos dentro de sus aplicaciones Linux, que redirige las transacciones de IMDS que la aplicación realiza a OpenID Connect (OIDC). El sidecar de migración no está pensado como una solución a largo plazo, sino como una manera de empezar a trabajar rápidamente con la identidad de carga de trabajo. En ella, lleve a cabo los siguiente pasos.

  • Implemente la carga de trabajo con sidecar de migración para proxy las transacciones de IMDS de la aplicación.
  • Compruebe que las transacciones de autenticación se completen correctamente.
  • Programe el trabajo para que las aplicaciones actualicen el SDK a una versión compatible.
  • Una vez que el SDK se actualice a la versión compatible, podrá quitar el sidecar de proxy y volver a implementar la aplicación.

  Nota

  El sidecar de migración no es compatible con el uso en producción. Esta característica está pensada para proporcionarle tiempo para migrar el SDK de la aplicación a una versión compatible y no está pensada o diseñada para ser una solución a largo plazo. El sidecar de migración solo está disponible para contenedores de Linux, debido a que solo proporciona identidades administradas por pods con grupos de nodos de Linux.

• Reescriba la aplicación para admitir la versión más reciente de la biblioteca cliente de Azure Identity. Después, realice los pasos siguientes:

  • Reinicie la implementación de la aplicación para empezar a autenticarse mediante la identidad de carga de trabajo.
  • Una vez que compruebe que las transacciones de autenticación se completan correctamente, puede quitar las anotaciones de identidad administrada por pods de la aplicación y, a continuación, quitar el complemento de identidad administrada por pods.

Creación de una entidad administrada

Si no tiene una identidad administrada creada y asignada al pod, realice los pasos siguientes para crear y conceder los permisos necesarios al almacenamiento, Key Vault o cualquier recurso que la aplicación necesite para autenticarse en Azure.

1. Use el comando az account set de la CLI de Azure para que una suscripción específica se establezca como la suscripción activa actual. Después, use el comando az identity create para crear una identidad administrada.

   az account set --subscription "subscriptionID"
   

   az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
   

   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"
   

2. Conceda a la identidad administrada los permisos necesarios para acceder a los recursos de Azure que requiere. Para obtener información sobre cómo hacerlo, consulte Asignación de un acceso de identidad administrada a un recurso.

3. Para obtener la dirección URL del emisor de OIDC y guardarla en una variable de entorno, ejecute el siguiente comando. Reemplace los valores predeterminados para el nombre del clúster y el nombre del grupo de recursos.

   export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
   

   La variable debe contener una dirección URL del emisor similar al ejemplo siguiente:

   https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
   

   De manera predeterminada, el emisor tiene establecido usar la dirección URL base https://{region}.oic.prod-aks.azure.com/{uuid}, donde el valor de {region} coincide con la ubicación en la que se implementa el clúster de AKS. El valor {uuid} representa la clave OIDC.

Creación de una cuenta de servicio de Kubernetes

Si no tiene una cuenta de servicio de Kubernetes dedicada creada para esta aplicación, realice los pasos siguientes para crear y, a continuación, anotarla con el identificador de cliente de la identidad administrada creada en el paso anterior. Use el comando az aks get-credentials y reemplace los valores del nombre del clúster y el nombre del grupo de recursos.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Copie y pegue la siguiente entrada de varias líneas en la CLI de Azure.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

El ejemplo de salida siguiente es similar a la creación correcta del grupo de recursos:

Serviceaccount/workload-identity-sa created

Establecimiento de confianza de credencial de identidad federada

A continuación, use el comando az identity federated-credential create para crear la credencial de identidad federada entre la identidad administrada, el emisor de la cuenta de servicio y el asunto. Reemplace los valores resourceGroupName, userAssignedIdentityName, federatedIdentityName, serviceAccountNamespace y serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Nota

La credencial de identidad federada tarda unos segundos en propagarse después de agregarse inicialmente. Si una solicitud de token se realiza inmediatamente después de agregar la credencial de identidad federada, podría provocar un error durante un par de minutos, ya que la memoria caché se rellena en el directorio con datos antiguos. Para evitar este problema, puede agregar un ligero retraso después de agregar la credencial de identidad federada.

Implementación de la carga de trabajo con sidecar de migración

Nota:

El sidecar de migración no es compatible con el uso en producción. Esta característica está pensada para proporcionarle tiempo para migrar el SDK de la aplicación a una versión compatible y no está pensada o diseñada para ser una solución a largo plazo. El Sidecar de migración solo es para contenedores de Linux, ya que las identidades administradas por pod solo están disponibles en grupos de nodos de Linux.

Si la aplicación usa identidad administrada y todavía se basa en IMDS para obtener un token de acceso, puede usar el sidecar de migración de identidad de carga de trabajo para empezar a migrar a la identidad de carga de trabajo. Este sidecar es una solución de migración y, en las aplicaciones a largo plazo, debe modificar su código para usar los SDK de identidad de Azure más recientes que admiten la aserción de cliente.

Para actualizar o implementar la carga de trabajo, agregue estas anotaciones de pod solo si desea usar el sidecar de migración. Inserte los siguientes valores de anotación para usar sidecar en la especificación del pod:

• azure.workload.identity/inject-proxy-sidecar: el valor es true o false
• azure.workload.identity/proxy-sidecar-port: el valor es el puerto deseado para el sidecar de proxy. El valor predeterminado es 8000.

Cuando se crea un pod con las anotaciones anteriores, el webhook mutando Azure Workload Identity inserta automáticamente el sidecar init-container y proxy en la especificación del pod.

El webhook que ya se está ejecutando agrega los siguientes fragmentos de código YAML a la implementación del pod. A continuación se muestra un ejemplo de la especificación de pod mutada:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Esta configuración se aplica a cualquier configuración en la que se crea un pod. Después de actualizar o implementar la aplicación, puede comprobar que el pod está en estado de ejecución mediante el comando kubectl describe pod. Reemplace el valor podName por el nombre de la imagen del pod implementado.

kubectl describe pods podName

Para comprobar que el pod pasa transacciones IMDS, use el comando kubectl logs. Reemplace el valor podName por el nombre de imagen del pod implementado:

kubectl logs podName

La siguiente salida de registro es similar a la comunicación correcta a través del sidecar de proxy. Compruebe que los registros muestran que un token se ha obtenido correctamente y que la operación GET es correcta.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Retirada de la identidad administrada por pods

Después de completar las pruebas y la aplicación puede obtener correctamente un token mediante el sidecar de proxy, puede quitar la asignación de identidad administrada por pods de Microsoft Entra ID para el pod del clúster y, a continuación, quitar la identidad.

1. Ejecute el comando az aks pod-identity delete para quitar la identidad del pod. Esto solo se debe hacer después de que todos los pods del espacio de nombres mediante la asignación de identidad administrada por pods se hayan migrado para usar sidecar.

   az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
   

Pasos siguientes

En este artículo se ha mostrado cómo configurar el pod para autenticarse mediante una identidad de carga de trabajo como opción de migración. Para más información sobre Microsoft Entra Workload ID, consulte la siguiente información general.