El examen AZ-400 pregunta repetidamente cómo un pipeline prueba su identidad ante los recursos de Azure. La respuesta antigua era simple: guardar un client secret en GitHub Secrets o en una variable del pipeline y recuperarlo en tiempo de ejecución. El problema es que cualquier secreto almacenado en un sistema externo puede quedar expuesto. Esta entrada cubre tres enfoques que eliminan ese riesgo: Managed Identity, Workload Identity Federation (OIDC) y Azure Key Vault.
Carnet de empleado vs tarjeta de máquina — Service Principal y Managed Identity
Cada nuevo empleado recibe un carnet con fecha de caducidad; cuando vence, solicita la renovación. Las impresoras de la oficina, en cambio, nunca necesitan renovación: la infraestructura del edificio gestiona sus credenciales automáticamente. Service Principal es el carnet del empleado. Managed Identity es la tarjeta de máquina emitida y gestionada por la propia plataforma.
Un Service Principal es una identidad no interactiva registrada en Microsoft Entra ID. Funciona en cualquier entorno: una VM de Azure, un servidor on-premises, un runner de GitHub Actions o una herramienta CI/CD externa. Su desventaja es la gestión de credenciales: los client secrets caducan en dos años como máximo, y olvidar renovarlos provoca fallos silenciosos a medianoche.
Managed Identity es un Service Principal creado, gestionado y rotado por la plataforma de Azure. No se necesitan credenciales en el código ni en la configuración del pipeline. Dos tipos para el examen:
está vinculada a un único recurso de Azure. Su ciclo de vida está unificado con el del recurso: nace y muere con él.
es un recurso independiente asignable a múltiples VMs, instancias de App Service y pods de AKS a la vez. Cuando una VM se reemplaza durante un escalado, la misma identidad y sus permisos se trasladan automáticamente. Clave del examen: → user-assigned.
| Escenario | Selección | |-----------|----------| | Entorno no Azure que accede a recursos de Azure | Service Principal | | Recurso único alojado en Azure | System-assigned Managed Identity | | Múltiples recursos que comparten la misma identidad | User-assigned Managed Identity |
!Service Principal vs Managed Identity
Una caja fuerte sin llave — Workload Identity Federation y OIDC
Imagina una cámara acorazada que no abre con llave física, sino con verificación biométrica en tiempo real y aprobación en vivo del equipo de seguridad. La llave no existe: solo queda la verificación de identidad. Esa es la idea de Workload Identity Federation: en lugar de un client secret, el pipeline usa un OIDC token de corta duración, emitido y verificado en tiempo real.
Cuando se ejecuta GitHub Actions o Azure Pipelines, la plataforma emite automáticamente un OIDC token firmado — un JWT con el nombre del repositorio, la rama, la organización y el contexto del workflow. El pipeline lo envía al Servicio de Token Seguro (STS) de Azure. Azure comprueba que las afirmaciones de emisor y sujeto coincidan con la preconfigurada y, si coinciden, emite un Access Token. Ningún client secret existe en ningún punto de este intercambio.
Configuración para GitHub Actions: Crear un App registration en Microsoft Entra ID. Añadir una Federated Identity Credential — Issuer: , Subject: . Asignar el rol Azure RBAC al Service Principal. Guardar en GitHub Secrets solo el Client ID, Tenant ID y Subscription ID — sin valores de secretos. Pasar esos tres valores a la acción .
En Azure Pipelines, el Workload Identity Federation se configura automáticamente al crear la Service Connection.
Fallo más frecuente en OIDC: discrepancia del Subject claim — ejecutar desde una rama de feature cuando el Subject especifica .
Azure Pipelines facilita aún más la configuración: al elegir el método Workload Identity Federation al crear una Service Connection, Azure DevOps registra automáticamente la Federated Identity Credential, sin necesidad de pasos manuales en Microsoft Entra ID.
Tres compartimentos en una cámara acorazada — Secret, Key y Certificate
Una cámara de seguridad guarda billetes, documentos sellados y sellos en secciones distintas, porque cada elemento tiene requisitos de acceso diferentes. Azure Key Vault hace lo mismo, y saber qué compartimento usar es una pregunta directa en el examen.
almacena cadenas arbitrarias: cadenas de conexión a bases de datos, API keys, contraseñas, tokens OAuth. Es el tipo que más usan los pipelines. Si el escenario menciona almacenar una , una o una , Secret es la respuesta.
gestiona material de clave asimétrica RSA o EC para cifrado, descifrado, firma y verificación. Las claves protegidas por HSM nunca salen del vault; las operaciones se ejecutan dentro de él. Úsalo cuando el requisito sea cifrado o firma.
gestiona certificados X.509 TLS/SSL con renovación y rotación automáticas. Úsalo para TLS, mTLS o certificados de firma.
Modelos de control de acceso
es el sistema de permisos propio de Key Vault: especifica operaciones individuales (Get, List, Set, Delete) por identidad, de forma independiente a Azure RBAC.
es el modelo predeterminado para nuevos Key Vaults desde 2023. Se integra con Microsoft Entra ID y usa la misma interfaz IAM del resto de Azure. Roles clave: (lectura mínima para pipelines), (lectura + escritura), (gestión completa).
Para referenciar Secrets de Key Vault en plantillas ARM, el vault debe tener activado. Los nuevos vaults lo tienen desactivado por defecto — olvidarlo provoca fallo inmediato en el despliegue.
El registro maestro del almacén — integración de secretos en pipelines
Un almacén logístico lleva un único registro maestro de inventario: cualquier responsable lo consulta y, cuando algo cambia, se actualiza en un solo lugar. Los secretos de los pipelines funcionan igual. Cuando cada pipeline mantiene su propia copia, las actualizaciones se pierden y las versiones divergen. Un Variable Group vinculado a Key Vault es ese registro maestro.
Cuando un Variable Group de Azure Pipelines se vincula a Key Vault, el YAML contiene solo el nombre del grupo, sin valores de secretos. En tiempo de ejecución, los secrets se recuperan dinámicamente. Varios pipelines del mismo proyecto comparten un Variable Group; cuando un secret rota en Key Vault, todos los pipelines lo recogen en la siguiente ejecución sin cambios de configuración. Los valores de secretos se enmascaran automáticamente en los logs del pipeline.
En GitHub Actions, aísla los secretos por entorno de despliegue: producción, staging, etc. Los Environment Secrets solo son accesibles cuando ese entorno está activo, y las reglas de protección — revisores requeridos, temporizadores de espera, restricciones de IP — crean una compuerta para producción.
Una de Azure Pipelines es la unidad que autentica al pipeline ante sistemas externos: una suscripción de Azure, un repositorio de GitHub, un registro de Docker, un clúster de Kubernetes. Jerarquía de permisos: Reader → User → Creator → Administrator. User es suficiente para ejecutar; Administrator es necesario para editar, eliminar o compartir la conexión con otros proyectos.
Resumen para el Examen
'Autenticarse en Azure sin client secret' -- Workload Identity Federation (OIDC) 'Múltiples recursos de Azure que comparten la misma identidad' -- User-assigned Managed Identity 'Un recurso de Azure accede a Key Vault sin almacenar credenciales' -- System-assigned Managed Identity 'GitHub Actions despliega en Azure, secretless' -- Workload Identity Federation 'Causa más frecuente de fallo de autenticación OIDC' -- Discrepancia de Subject claim con la rama real 'Almacenar cadena de conexión, API key o contraseña en Key Vault' -- Secret 'Almacenar material de clave criptográfica en Key Vault' -- Key 'Almacenar certificado TLS/mTLS en Key Vault' -- Certificate 'El despliegue ARM falla al leer un Secret de Key Vault' -- Enable for template deployment desactivado 'Compartir Secrets de Key Vault entre múltiples pipelines' -- Variable Group vinculado a Key Vault 'Modelo de permisos estándar de Azure para Key Vault' -- Azure RBAC 'Permiso mínimo para que una ejecución de pipeline use una Service Connection' -- User