AZ-104

Deep Dive

D1 · Identidad y Acceso

Identidades Administradas (Managed Identities)

Elimina credenciales del código. Una app o VM obtiene una identidad gestionada por Azure y puede autenticarse contra otros servicios sin contraseñas ni secrets hardcodeados.

Contenido

El problema que resuelve
System-assigned vs User-assigned
Cómo configurar y usar
Casos de uso con Key Vault y Storage
Managed Identity vs Service Principal
Workload Identity Federation — sin secretos en CI/CD
Workload Identity en AKS

El problema que resuelve

❌ Sin Managed Identity

# App necesita leer un secreto de Key Vault
# ¿Cómo se autentica?

CLIENT_ID = "abc-123"         # hardcodeado
CLIENT_SECRET = "s3cr3t!"    # ← PELIGRO

credential = ClientSecretCredential(
    tenant_id, CLIENT_ID, CLIENT_SECRET
)
client = SecretClient(vault_url, credential)
secret = client.get_secret("db-password")

→ Secret hardcodeado en código o config
→ Rotación manual = downtime o secretos viejos
→ Si el repo se filtra → secret comprometido
→ Auditoría: imposible saber qué app usó el secret

✓ Con Managed Identity

# App usa Managed Identity — cero credenciales

credential = DefaultAzureCredential()
# Azure inyecta el token automáticamente ↑

client = SecretClient(vault_url, credential)
secret = client.get_secret("db-password")

→ Cero secrets en código, config o repos
→ Azure rota los tokens automáticamente
→ Acceso controlado con RBAC
→ Auditoría: cada acceso queda registrado por identidad

System-assigned vs User-assigned

Dimensión	System-assigned	User-assigned
Ciclo de vida	Ligado al recurso — se crea/elimina con él	Independiente — persiste aunque se elimine el recurso
Compartible	No — solo ese recurso puede usarla	Sí — múltiples recursos pueden compartirla
Creación	Automática al habilitar en el recurso	Recurso independiente en Azure (tipo: Managed Identity)
Caso típico	Una VM que accede a Key Vault solo para ella	Fleet de VMs o apps que comparten el mismo acceso
Gestión de roles	Asignar roles al Object ID de la identidad del recurso	Asignar roles a la User-assigned MI una vez, asignarla a muchos recursos
Recomendado cuando	Recurso único con acceso específico	Múltiples recursos necesitan los mismos permisos

Cómo configurar y usar

Habilitar System-assigned en una VM

Portal

VM → Identity → System assigned → Status: On → Save

CLI

az vm identity assign --name myVM --resource-group myRG

PowerShell

Update-AzVM -VM $vm -IdentityType SystemAssigned

Bicep/ARM

identity: { type: "SystemAssigned" } en el recurso

Flujo completo: VM → Key Vault

1.Habilitar System-assigned MI en la VM → Azure crea un Service Principal en Entra ID

2.Anotar el Object ID del MI (visible en VM → Identity)

3.En Key Vault → Access policies (o RBAC) → asignar rol "Key Vault Secrets User" al Object ID

4.En el código de la VM → usar DefaultAzureCredential() — detecta automáticamente el MI

5.Azure inyecta un token JWT válido via IMDS (Instance Metadata Service: 169.254.169.254)

6.La app usa el token para autenticarse contra Key Vault — sin secrets en código

Casos de uso — Key Vault y Storage

App Service → Key Vault

1.App Service: Settings → Identity → System assigned ON
2.Key Vault → Access control (IAM) → Add role assignment
3.Rol: Key Vault Secrets User → asignar al App Service
4.En app.settings: usar @Microsoft.KeyVault(SecretUri=...) reference
5.App Service resuelve automáticamente el secret en runtime

Key Vault References en App Settings evita incluso tener el valor en el portal.

VM / Function → Storage Blob

1.Habilitar MI en la VM o Function App
2.Storage Account → Access control (IAM) → Add role
3.Rol: Storage Blob Data Reader o Contributor según necesidad
4.Asignar al Object ID de la MI
5.En código: BlobServiceClient(url, DefaultAzureCredential())

Storage Blob Data Contributor permite leer/escribir datos pero no gestionar la cuenta.

Recursos compatibles con Managed Identity

Azure VMs

App Service

Azure Functions

Container Instances

AKS (pods)

Logic Apps

API Management

Data Factory

Event Grid

Service Bus

Azure Arc

Spring Apps

Managed Identity vs Service Principal manual

Aspecto	Service Principal (manual)	Managed Identity
Credenciales	Client Secret o Certificado — gestión manual	Ninguna — Azure gestiona el token
Rotación	Manual (recordar expiración)	Automática
Uso en código	ClientSecretCredential(tenant, client_id, secret)	DefaultAzureCredential() — sin parámetros
Aplicación	Apps externas, CI/CD pipelines, scripts externos	Recursos de Azure (VMs, Apps, Functions)
Riesgo de leak	Alto — secret puede filtrarse en logs/repos	Ninguno — no hay secret que filtrar
Cuándo usar SP	GitHub Actions, Terraform, apps fuera de Azure	Si el recurso vive en Azure → siempre preferir MI

Workload Identity Federation — CI/CD sin secretos

Workload Identity Federation permite que workloads externos (GitHub Actions, GitLab CI, Kubernetes, Terraform Cloud) obtengan tokens de Entra ID sin necesidad de almacenar Client Secrets. Usa el estándar OIDC.

Cómo funciona — GitHub Actions ejemplo

1Crear App Registration en Entra ID (o User-assigned MI)

2En la App: Certificates & Secrets → Federated credentials → Add credential

3Configurar: Issuer = https://token.actions.githubusercontent.com, Subject = repo:org/repo:ref:refs/heads/main

4Asignar los roles necesarios a la App Registration en Azure (ej: Contributor en la Subscription)

5En el workflow de GitHub, usar azure/login action con client-id, tenant-id (sin secret)

6GitHub emite un token OIDC → Azure verifica contra el federated credential configurado → emite access token

Ventajas vs Client Secret

✓ Cero secretos almacenados en GitHub, GitLab, Terraform Cloud

✓ No hay rotación de secretos que gestionar

✓ Si el repositorio se hace público, no hay secret que robar

✓ Cada pipeline/branch puede tener su propia identidad granular

✓ El token tiene alcance temporal — expira tras cada job

Proveedores soportados

GitHub Actions

GitLab CI/CD

Kubernetes (any)

Terraform Cloud

Google Cloud

AWS

CircleCI

Custom OIDC

Workload Identity en AKS — identidad por pod

En AKS, el enfoque moderno es Workload Identity (antes llamado AAD Pod Identity). Permite que pods individuales tengan su propia identidad en Entra ID, sin compartir credenciales con otros pods en el mismo nodo.

Arquitectura

Node-level MI (método antiguo): La VM del nodo de AKS tiene una Managed Identity. TODOS los pods en ese nodo comparten la misma identidad. Si un pod es comprometido, tiene acceso a los mismos recursos que todos los otros pods.

Workload Identity (método recomendado):

• Cada pod usa un Kubernetes Service Account anotado

• El Service Account se federa con una User-assigned MI o App Registration en Entra ID

• Solo ese pod obtiene el token para esa identidad específica

• Principio de mínimo privilegio a nivel de pod

Configuración básica

1Habilitar OIDC issuer en el cluster: az aks update --enable-oidc-issuer

2Habilitar Workload Identity: az aks update --enable-workload-identity

3Crear User-assigned MI y anotar con el namespace/service-account de Kubernetes

4Crear federated credential en la MI apuntando al OIDC issuer del cluster + subject del service account

5Asignar rol Azure (ej: Key Vault Secrets User) a la MI

6En el pod spec, referenciar el service account anotado → el pod recibe token automáticamente vía projected volume

Pod Identity v1/v2 (deprecated) vs Workload Identity

El addon AAD Pod Identity (v1 y v2) está deprecated. Microsoft recomienda migrar a Workload Identity que usa el estándar OIDC. La principal diferencia: Workload Identity no requiere CRDs ni daemonsets adicionales — usa el mecanismo nativo de OIDC federation.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

¿Cuál es la ventaja principal de usar una Managed Identity para que una VM acceda a Azure Key Vault?