Secretos zero-config: Key Vault + Managed Identity
appsettings.json es un secreto en Git, y por tanto un secreto comprometido. La respuesta idiomática en Azure: Key Vault para almacenar los secretos, Managed Identity para acceder a ellos sin la más mínima contraseña. Al final, su configuración ya no contiene ninguna cadena sensible.
El muro de autenticación… que desaparece
DefaultAzureCredential encadena varias fuentes de autenticación y selecciona la primera que responde — de ahí la portabilidad entre el equipo local de desarrollo y la nube.
Key Vault como proveedor de configuración
SecretClient manualmente, conecte Key Vault directamente al sistema de configuración de ASP.NET Core. Todos los secretos se convierten en entradas de configuración ordinarias, fusionadas con appsettings.json y las variables de entorno.
: , por lo que se usa -- en el nombre del secreto, traducido automáticamente al separador de sección. Db--ConnectionString se convierte en Db:ConnectionString , exactamente como en el resto de su configuración tipada.
RBAC en lugar de las access policies
$PRINCIPAL_ID es el objectId de la identidad administrada, recuperable tras su activación en el recurso. El principio de mínimo privilegio se aplica: un servicio que solo lee secretos nunca debe poseer el rol Key Vault Secrets Officer .
Dev local vs nube, sin cambiar una línea
DefaultAzureCredential : en producción obtiene el token de la identidad administrada; en su equipo local, cambia a la identidad de la Azure CLI ( az login ) o de Visual Studio. El mismo código funciona en todas partes, siempre que su cuenta también disponga del rol Key Vault Secrets User . La documentación de Key Vault + identidad administrada detalla el orden exacto de la cadena de autenticación y su ajuste fino.
El mejor secreto es aquel que nunca hay que manipular. Con Managed Identity, la rotación la gestiona Azure, y su repositorio Git vuelve a ser lo que siempre debió haber sido: público sin riesgo .