Todos mis pipelines no pueden hacer push a Azure Container Registry

Hola @Ivan P ,

Gracias por comunicarte con Microsoft Q&A.

Aquí tienes lo que puedes revisar e intentar para resolver el error de “no autorizado”:

1. Verifica la configuración de Workload Identity Federation

• En Azure AD, abre el registro de aplicación que respalda tu conexión de servicio en DevOps.
• En “Certificados y secretos”, asegúrate de que no haya ningún secreto de cliente expirado si alguna vez usaste uno.
• En “Credenciales federadas”, confirma que tengas una entrada de federación válida apuntando a tu organización de Azure DevOps, con el emisor correcto (https://login.microsoftonline.com/{tenant}/v2.0) y el formato de sujeto correcto (por ejemplo, repo:{project}/pipeline:environment).
• Si algo no parece correcto, elimina y vuelve a crear el registro de federación y vuelve a autorizar la conexión en Azure DevOps.

2. Asegúrate de que la identidad tenga el rol correcto en ACR

• Ve a tu Container Registry en el portal de Azure → Control de acceso (IAM) → Agregar asignación de rol.
• Otorga a la aplicación (el SP de tu conexión de servicio) el rol AcrPush (esto también cubre pull).
• Si solo asignaste Reader antes, el push fallará.

3. Confirma los permisos a nivel de suscripción o grupo de recursos (para listar registros)

• Si ni siquiera puedes listar los registros al crear una nueva conexión de servicio, el SP necesita al menos el rol Reader en la suscripción o grupo de recursos donde se encuentra el ACR.
• Verifica en el portal → Suscripciones → Control de acceso (IAM) o directamente en el grupo de recursos.

4. Vuelve a crear (o edita) la conexión de servicio en Azure DevOps

• En tu proyecto de DevOps, ve a Configuración del proyecto → Conexiones de servicio → Nueva conexión de servicio → Azure Container Registry.
• Selecciona Workload Identity (o Service Principal) y apúntalo a la aplicación y tenant que verificaste anteriormente.
• Guarda y haz clic en Verify para asegurarte de que puede listar el registro.

5. Prueba localmente (opcional)

• Ejecuta los comandos equivalentes de az login en tu máquina para confirmar credenciales: Para SP:

   az login --service-principal -u <client-id> -p <client-secret> --tenant <tenant-id>

Para identidades administradas/federadas, puedes usar:

  az login --identity

• Una vez que tu conexión de servicio pueda autenticarse correctamente y listar el ACR, tu paso Docker@2 de build-and-push debería funcionar nuevamente:

- task: Docker@2
  inputs:
    command: buildAndPush
    repository: $(ACR_NAME)/yourproject
    dockerfile: Dockerfile
    containerRegistry: '<your-service-connection-name>'
    tags: |
      $(Build.BuildId)

¡Espero que esto te ayude!

Hola Pravallika,

Revisamos la opción de recrear nuestra conexión dado que aún está vigente, sin embargo no nos lista los registros de contenedores, la cuenta que esta creando la cuenta de servicio es la cuenta administrativa del portal azure y tiene todos los permisos

Agradeceré nos puedas ayudar para volver a crear nuestra conexión, ya que el portal presenta errores también

Atento a tu respuesta,

Carlos.

Aunque tu cuenta del portal de Azure sea administrador global, que DevOps no pueda listar los registros de contenedores durante la creación de la conexión de servicio suele indicar que Azure DevOps no puede obtener un token de acceso válido a través de Workload Identity Federation (WIF). Esto a menudo no está relacionado con la pipeline en sí.

Aquí están los pasos que puedes revisar:

1. Confirmar que las credenciales federadas de Azure AD siguen siendo válidas

Incluso los administradores globales no pueden eludir una federación rota. Revisa lo siguiente:

• Ve a Azure AD → App Registrations → [Tu aplicación de DevOps] → Certificates & Secrets → Federated Credentials.
• Asegúrate de que:
  • La audiencia sea correcta (api://AzureADTokenExchange para DevOps).
  • El identificador del sujeto coincida con tu organización de DevOps.
  • La URL del emisor apunte a https://vstoken.azure.net.
• Verifica si hay credenciales revocadas o expiradas. A veces las credenciales WIF pueden invalidarse silenciosamente después de cambios en las políticas de Azure AD.

2. Verificar la asignación de roles en ACR

Incluso si tu usuario es administrador, la identidad federada debe tener permisos por sí misma, no tu usuario:

• Ve a ACR → Control de acceso (IAM) → Asignaciones de roles.
• Confirma que la identidad federada tenga asignado AcrPush (o superior, como AcrPull+Push).
• Si la asignación existe, intenta eliminarla y volverla a agregar, ya que a veces los retrasos en la propagación de roles hacen que DevOps vea “no hay registros”.

3. Revisar el alcance del agente de la pipeline

Si tus pipelines usan agentes autoalojados, asegúrate de que tengan acceso de red a los endpoints de Azure AD. WIF requiere:

• Conexiones HTTPS salientes a login.microsoftonline.com y vstoken.azure.net.
• Si el agente no puede alcanzar estos endpoints, la obtención del token fallará silenciosamente.

4. Probar la obtención del token desde el agente de DevOps

En la máquina del agente:

curl -H "Metadata: true" "http://<IP>/metadata/identity/oauth2/token?resource=https://management.azure.com/&api-version=2018-02-01"

• Si esto falla, DevOps no puede obtener un token para el registro. Esto explica por qué la opción de “listar registros de contenedores” falla durante la creación de la conexión de servicio.

@Ivan P , Doy seguimiento para saber si la información proporcionada anteriormente fue útil. Si tiene alguna otra consulta, háganoslo saber.