Usted opera un conjunto de escalado de VM y múltiples Function Apps que deben acceder a Azure Key Vault y Azure Storage con una identidad común y reutilizable en todos los recursos y regiones. La identidad debe sobrevivir a cualquier recurso individual. Las cargas de trabajo también necesitan obtener tokens OAuth para llamar a una API de socio que confía en Entra ID, sin almacenar secretos. ¿Qué debe hacer? Cada respuesta correcta presenta parte de la solución.

La creación de una identidad administrada asignada por el usuario (User-Assigned Managed Identity, UAMI) es la solución correcta porque permite una identidad común y reutilizable en múltiples recursos y regiones, y su ciclo de vida es independiente de los recursos individuales, cumpliendo con el requisito de supervivencia. Asignar los roles necesarios (Key Vault Secrets User y Storage Blob Data Contributor) le otorga los permisos de acceso a Key Vault y Storage. La solicitud de tokens desde el código utilizando el punto de conexión de identidad administrada (IMDS o el punto de conexión de token de App Service) es el método seguro y sin secretos para obtener tokens OAuth para la API del socio, ya que las identidades administradas pueden autenticarse directamente con Entra ID. Las identidades asignadas por el sistema no son reutilizables entre recursos y tienen un ciclo de vida acoplado al recurso. Un registro de aplicación con un secreto de cliente requeriría almacenar y gestionar secretos, lo cual se quiere evitar. La API de Azure AD Graph está obsoleta, y las identidades administradas son compatibles con Microsoft Graph y otros servicios que confían en Entra ID.