Todo proyecto de Azure tiene tarde o temprano la misma conversación. ¿Dónde guardamos la connection string? Alguien propone una variable de entorno, y alguien señala que las variables de entorno terminan en pipelines de deployment, en archivos de Docker compose, en el estado de Terraform, y ocasionalmente en algún commit accidental. Se propone un secret manager, y el secret manager necesita sus propias credenciales para acceder a los secrets. El problema recurre.

Managed Identity no resuelve el problema del secret manager agregando otra capa sino que elimina la credencial por completo para workloads que corren dentro de Azure, de modo que la aplicación no se autentica con una credencial almacenada sino como ella misma, usando una identidad que Azure gestiona de forma automática.

Qué hace realmente Managed Identity

Cuando habilitás una Managed Identity en un recurso de Azure, Azure crea una identidad en Microsoft Entra ID ligada al ciclo de vida de ese recurso. El recurso puede entonces solicitar tokens de corta duración al endpoint del Azure Instance Metadata Service en 169.254.169.254, que solo es accesible desde dentro de la infraestructura de Azure, y esos tokens son los que el recurso usa para autenticarse contra otros servicios de Azure. No hay nada que almacenar, nada que rotar manualmente, y nada que pueda filtrarse en un repositorio porque la credencial nunca existe como un string estático en ningún lugar del código o la configuración.

La documentación oficial de Microsoft lo dice con precisión: las identidades administradas le dan al código que corre en un recurso de Azure acceso a otros recursos sin que los developers necesiten manejar o poner credenciales directamente en el código. El énfasis en "código que corre en un recurso de Azure" importa porque Managed Identity solo funciona desde dentro de Azure. Una máquina local de desarrollo no puede alcanzar el endpoint del Instance Metadata Service, lo que significa que el flujo de desarrollo local sigue necesitando un mecanismo alternativo de autenticación, típicamente az login o un service principal configurado solo para desarrollo.

System-assigned vs user-assigned

Hay dos tipos de Managed Identity, y la recomendación actual de Microsoft, actualizada en su documentación oficial de mejores prácticas, es que las identidades user-assigned son más eficientes en la mayoría de los escenarios.

Una identidad system-assigned se crea directamente en un recurso y su ciclo de vida está ligado a ese recurso, así que cuando el recurso se elimina, la identidad también se elimina. Eso suena conveniente pero crea un problema de gestión a escala: cada recurso obtiene su propia identidad, cada identidad necesita sus propias asignaciones de rol, y si tenés veinte App Services que necesitan acceso de lectura al mismo storage account, terminás gestionando veinte identidades separadas con veinte asignaciones de rol que tienen que mantenerse sincronizadas.

Una identidad user-assigned se crea como un recurso independiente en Azure y puede asignarse a múltiples recursos simultáneamente, con su ciclo de vida independiente de cualquier recurso en particular. Si eliminás el App Service, la identidad persiste. Podés predefinir qué puede acceder una identidad user-assigned, obtener aprobación de quien gestiona el control de acceso, y luego asignarla a nuevos recursos a medida que se crean sin necesitar un nuevo ciclo de aprobación cada vez.

La recomendación de naming de Microsoft hace la diferencia operativa clara: nombrar las identidades según su conjunto de permisos en lugar de según el consumidor. Una identidad llamada id-blobreader-prod-eastus sobrevive a cualquier workload específico y su propósito sigue siendo legible en los logs de auditoría, mientras que una identidad llamada id-appsvc-01 no comunica qué puede hacer y sus permisos tienden a derivar con el tiempo a medida que el equipo cambia.

El error de seguridad que comete la mayoría

Activar Managed Identity y eliminar la credencial hardcodeada es el primer paso correcto, pero detenerse ahí es donde la mayoría de los equipos deja una brecha significativa.

Las identidades administradas no hacen a un workload seguro sino que lo hacen libre de credenciales, y esa distinción importa porque la identidad sigue teniendo los permisos que le asignaste, y esos permisos están disponibles para cualquier cosa que corra en el recurso al que está asignada. La propia documentación de Microsoft lo dice explícitamente: si un usuario tiene acceso para instalar o ejecutar código en un recurso con una identidad administrada, ese usuario tiene acceso a todo lo que la identidad puede alcanzar, incluso si no tiene acceso directo a esos recursos de destino.

Esto significa que darle a una Managed Identity permisos amplios como Contributor en un storage account y luego asignarla a un recurso de cómputo compartido donde múltiples equipos ejecutan código efectivamente eleva el acceso de todos los equipos a ese storage account. El problema de credenciales desapareció pero el problema de permisos permanece y ahora es implícito en lugar de visible en un secret manager.

La corrección práctica es aplicar asignaciones de rol de mínimo privilegio: en lugar de Contributor, asignar Storage Blob Data Reader si el workload solo lee blobs, y en lugar de Key Vault Administrator, asignar Key Vault Secrets User si el workload solo lee secrets. Azure RBAC tiene roles integrados específicos para la mayoría de los escenarios comunes, y usarlos reduce el radio de explosión si un workload se ve comprometido.

Usando DefaultAzureCredential

La implementación práctica para la mayoría de los equipos es DefaultAzureCredential, parte del SDK de Azure Identity y disponible para Python, JavaScript, Java y .NET. Prueba una secuencia de métodos de autenticación en orden y usa el primero que tiene éxito, lo que significa que el mismo código funciona tanto en desarrollo local como en Azure sin ramificación específica por entorno.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
 
credential = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://mystorageaccount.blob.core.windows.net",
    credential=credential
)

En un entorno local, DefaultAzureCredential típicamente usa las credenciales de az login, y en un recurso de Azure con Managed Identity habilitada usa el token de identidad administrada del Instance Metadata Service. La misma línea de código maneja ambos casos.

El orden de resolución de credenciales importa cuando se depuran problemas de autenticación. DefaultAzureCredential prueba EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredential, SharedTokenCacheCredential, VisualStudioCodeCredential, AzureCliCredential, AzurePowerShellCredential y AzureDeveloperCliCredential en ese orden. Si ves comportamiento inesperado de autenticación en desarrollo local, generalmente es porque una credencial anterior en la cadena se está usando de forma inesperada, típicamente una variable de entorno en el shell que está sobreescribiendo la credencial de az login.

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
 
const credential = new DefaultAzureCredential();
const client = new SecretClient(
  "https://mykeyvault.vault.azure.net",
  credential
);
 
const secret = await client.getSecret("my-database-connection-string");

Dónde Managed Identity no funciona

Dos escenarios donde un service principal con client secret o certificado sigue siendo la opción correcta: workloads que corren fuera de Azure y no pueden alcanzar el Instance Metadata Service, y escenarios federados donde el workload necesita autenticarse en Azure desde un entorno que no es Azure como GitHub Actions u otro proveedor cloud. Para GitHub Actions específicamente, Microsoft soporta federación basada en OIDC que elimina el problema de los secrets almacenados sin requerir que el workload corra en Azure.

El giro de 2026 hacia identity-first

La dirección de Azure en 2026 es cada vez más identity-first por defecto, con las identidades administradas system-assigned ahora como default para workloads de Kubernetes en AKS, reemplazando las API keys en ese contexto. El patrón se está convirtiendo en una expectativa base en lugar de una configuración avanzada, y para proyectos nuevos que empiezan en Azure, configurar Managed Identity desde el principio es significativamente más sencillo que incorporarla en una codebase existente que pasa credenciales como strings.

Para la documentación completa de Microsoft sobre Managed Identity y cómo configurarla para servicios específicos de Azure:

👉 Identidades administradas para recursos de Azure - Información general

Referencias

Información basada en la documentación oficial de Microsoft y fuentes verificadas a septiembre de 2026. Los servicios y recomendaciones de Azure pueden cambiar. Verificá la guía actual en Microsoft Learn antes de implementar en entornos de producción.