Managed Identity: aplicaciones que se autentican sin guardar contraseñas

Abres el repositorio de una aplicación que lleva años en producción y, en algún appsettings.Production.json, aparece la cadena de conexión a la base de datos con usuario y contraseña. A veces está cifrada, y el equipo lo cuenta como una victoria. Pero cifrar una contraseña solo cambia de sitio el problema: ahora alguien tiene que guardar la llave del cifrado, rotarla y acordarse de que existe.

La pregunta útil no es cómo esconder mejor el secreto. Es por qué la aplicación necesita uno.

Managed Identity existe para que no lo necesite.

La idea en una frase#

El recurso es la identidad; Azure guarda el secreto, y ni siquiera tú puedes verlo.

Cuando habilitas una managed identity en una App Service, una Function o una máquina virtual, Microsoft Entra ID crea una identidad atada a ese recurso. Existe una credencial por debajo, pero la gestiona Azure: no la conoces, no la copias a ningún archivo y no la rotas. Tu código deja de decir "soy app_pedidos y esta es mi contraseña" y pasa a decir "soy este recurso, pregúntale a Entra ID".

Cómo funciona#

Supongamos una aplicación de pedidos desplegada en App Service que necesita leer una API key de Key Vault y escribir en una base de datos SQL. Recorre el flujo paso a paso:

1. Pide un token
2. Token firmado
3. Presenta el token
4. El destino decide

Paso 1 de 4 · Pide un token

←→

La aplicación pide un token a un endpoint local que solo existe dentro de su propio recurso. No envía ninguna contraseña: el simple hecho de estar corriendo en ese recurso es la prueba de quién es.

Ese último paso es el que más se olvida. Habilitar la identidad es un clic; lo que hace que la aplicación funcione (o que no pueda hacer más de lo debido) es la asignación de roles en cada destino.

Lo que cambia en el código#

La diferencia se ve mejor en la cadena de conexión que en cualquier explicación (aquí va un parámetro por línea para leerla mejor; en la configuración real es una sola cadena):

Server=tcp:pedidos.database.windows.net,1433;
Database=pedidos;
User ID=app_pedidos;
Password=N0-L0-Sub4s!;
Encrypt=true;

Server=tcp:pedidos.database.windows.net,1433;
Database=pedidos;
Authentication=Active Directory Managed Identity;
User ID=<client-id-de-la-identidad>;
Encrypt=true;

var clientId = builder.Configuration["IdentityClientId"];
var credential = new ManagedIdentityCredential(
    ManagedIdentityId.FromUserAssignedClientId(clientId));
 
var secrets = new SecretClient(
    new Uri("https://kv-pedidos.vault.azure.net/"), credential);
 
KeyVaultSecret apiKey = await secrets.GetSecretAsync("pasarela-pagos-api-key");

En la versión nueva, User ID ya no es un usuario de base de datos: es el client ID de la identidad, que no es secreto. Puedes subirlo al repositorio sin pedir perdón a nadie.

Del lado de la base de datos, la identidad se da de alta como cualquier otro usuario de Entra, con los roles justos:

CREATE USER [id-pedidos] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [id-pedidos];
ALTER ROLE db_datawriter ADD MEMBER [id-pedidos];

Una identidad por recurso o una para todos#

Hay dos tipos, y la diferencia no es técnica sino de ciclo de vida:

La ventaja de user-assigned se entiende mejor contando asignaciones de rol:

⤢ AmpliarMismos permisos, cuatro veces menos asignaciones que mantener.

Cuatro aplicaciones que necesitan los mismos dos recursos son ocho asignaciones con system-assigned y dos con una identidad compartida. Y lo importante no es el número del primer día, sino el del día en que hay que retirar un permiso y alguien tiene que encontrar las ocho.

• 8 → 2asignaciones de rol para 4 máquinas y 2 recursos al compartir una identidadMicrosoft Learn
• ~24 hpuede tardar un cambio de grupos o roles en llegar al token de una managed identityMicrosoft Learn

¿Y Key Vault entonces sobra?#

No, y es la confusión más común. Managed Identity elimina los secretos que se pueden eliminar; Key Vault guarda los que no. La contraseña de tu propia base de datos sobra si la base de datos acepta tokens de Entra. La API key de un proveedor de pagos externo, no: ese proveedor no sabe nada de tu tenant.

⤢ AmpliarLa identidad abre el cofre; el cofre guarda solo lo que no se puede eliminar.

Lo que me gusta de este esquema es que cierra el círculo: la aplicación entra a Key Vault con su propia identidad, así que no hace falta un secreto para abrir el cofre de secretos. El único valor sensible que queda en todo el sistema es el que pertenece a un tercero, y vive en un sitio donde cada lectura queda registrada.

La letra pequeña#

Tres cosas que no aparecen en el tutorial de cinco minutos:

• Los cambios de permisos no son inmediatos. Los tokens de las managed identities se cachean en la infraestructura de Azure durante unas 24 horas y no se pueden forzar a renovarse. Si añades o quitas la identidad de un grupo con permisos, el cambio puede tardar horas en notarse. Para cambios rápidos, asigna los roles directamente a una identidad user-assigned en lugar de jugar con grupos.
• Borrar la identidad no borra sus roles. Las asignaciones de rol se quedan huérfanas y aparecen en el portal como Identity not found. Hay que limpiarlas a mano.
• El paquete de SQL cambió. Desde Microsoft.Data.SqlClient 7.0, los modos de autenticación de Entra necesitan también Microsoft.Data.SqlClient.Extensions.Azure. Si actualizas el driver y la conexión deja de funcionar, empieza por ahí.

Cuándo Managed Identity no es la respuesta#

Managed Identity tiene una condición que no se negocia: el código tiene que correr en Azure. Si dudas sobre qué identidad usar, responde estas preguntas:

Por dónde empezar#

Una managed identity no te exime de gestionar el acceso; te libera de gestionar contraseñas. Esa diferencia es todo el beneficio.

Si mañana quieres quitar el primer secreto de una aplicación, empieza por tres cosas:

1. Busca en tus repositorios y en la configuración de tus App Services cadenas con Password=, AccountKey= o SharedAccessKey=. Cada una es una candidata.
2. Crea una identidad user-assigned, dale el rol mínimo en el destino y cambia la cadena de conexión.
3. Cuando la aplicación funcione sin él, revoca el secreto antiguo. Si sigue vigente en algún sitio, el problema sigue ahí.

Fuentes#

1. Managed identities for Azure resources, Microsoft Learn.
2. Best practice recommendations for managed identities, Microsoft Learn.
3. Microsoft Entra authentication with Microsoft.Data.SqlClient, Microsoft Learn.
4. Credential chains in the Azure Identity library for .NET, Microsoft Learn.