Compartir a través de

Autenticación de Azure en Spring Cloud

  • Artículo

Este artículo se aplica a:✅ versión 4.19.0 ✅ versión 5.19.0

En este artículo se describen todos los métodos de autenticación de Azure de Spring Cloud.

DefaultAzureCredential

El DefaultAzureCredential es adecuado para la mayoría de los escenarios en los que la aplicación está pensada para ejecutarse en la nube de Azure. Esto se debe a que el DefaultAzureCredential combina las credenciales que se usan habitualmente para autenticarse cuando se implementan con credenciales usadas para autenticarse en un entorno de desarrollo.

Nota

DefaultAzureCredential está pensado para simplificar la introducción al SDK mediante el control de escenarios comunes con comportamientos predeterminados razonables. Si quiere más control o el escenario no se sirve con la configuración predeterminada, debe usar otros tipos de credenciales.

El DefaultAzureCredential intentará autenticarse mediante los siguientes mecanismos en orden:

Diagrama que muestra el mecanismo de autenticación de

  • Entorno: el DefaultAzureCredential leerá la información de la cuenta especificada a través de variables de entorno y la usará para autenticarse.
  • Identidad administrada: si la aplicación se implementa en un host de Azure con identidad administrada habilitada, el DefaultAzureCredential se autenticará con esa cuenta.
  • IntelliJ: si se ha autenticado a través del kit de herramientas de Azure para IntelliJ, el DefaultAzureCredential se autenticará con esa cuenta.
  • Visual Studio Code: si se ha autenticado a través del complemento de cuenta de Azure de Visual Studio Code, el DefaultAzureCredential se autenticará con esa cuenta.
  • CLI de Azure: si ha autenticado una cuenta a través del comando az login de la CLI de Azure, el DefaultAzureCredential se autenticará con esa cuenta.

Propina

Asegúrese de que a la entidad de seguridad se le ha concedido permiso suficiente para acceder al recurso de Azure. Para obtener más información, consulte Autorizar el acceso con el identificador de Entra de Microsoft.

Nota

Dado que Spring Cloud Azure AutoConfigure 4.1.0, una ThreadPoolTaskExecutor bean denominada springCloudAzureCredentialTaskExecutor se registrará automáticamente de forma predeterminada y administrará todos los subprocesos creados por Azure Identity. El nombre de cada subproceso administrado por este grupo de subprocesos tiene el prefijo az-identity-. Este ThreadPoolTaskExecutor bean es independiente del Executor bean proporcionado por Spring Boot.

Identidades administradas

Un desafío común es la administración de secretos y credenciales que se usan para proteger la comunicación entre distintos componentes que componen una solución. Las identidades administradas eliminan la necesidad de administrar las credenciales. Las identidades administradas proporcionan una identidad para que las aplicaciones las usen al conectarse a los recursos que admiten la autenticación de Microsoft Entra. Las aplicaciones pueden usar la identidad administrada para obtener tokens de Microsoft Entra. Por ejemplo, una aplicación puede usar una identidad administrada para acceder a recursos como Azure Key Vault, donde puede almacenar credenciales de forma segura o para acceder a las cuentas de almacenamiento.

Se recomienda usar la identidad administrada en lugar de usar la cadena de conexión o la clave en la aplicación porque es más seguro y ahorrará los problemas de administración de secretos y credenciales. En este caso, DefaultAzureCredential podría servir mejor al escenario de desarrollo localmente mediante la información de la cuenta almacenada localmente y, a continuación, implementar la aplicación en la nube de Azure y usar la identidad administrada.

Tipos de identidad administrada

Hay dos tipos de identidades administradas:

  • asignados por el sistema: algunos servicios de Azure permiten habilitar una identidad administrada directamente en una instancia de servicio. Al habilitar una identidad administrada asignada por el sistema, se crea una identidad en Microsoft Entra que está vinculada al ciclo de vida de esa instancia de servicio. Por lo tanto, cuando se elimina el recurso, Azure elimina automáticamente la identidad automáticamente. Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Microsoft Entra ID.
  • asignadas por el usuario: también puede crear una identidad administrada como un recurso de Azure independiente. Puede crear una identidad administrada asignada por el usuario y asignarla a una o varias instancias de un servicio de Azure. Con las identidades administradas asignadas por el usuario, la identidad se administra por separado de los recursos que lo usan.

Nota

Al usar una identidad administrada asignada por el usuario, puede especificar el identificador de cliente a través de spring.cloud.azure.credential.client-id o spring.cloud.azure.<azure-service>.credential.client-id. No necesita la configuración de credenciales si usa una identidad administrada asignada por el sistema.

Propina

Asegúrese de que a la entidad de seguridad se le ha concedido permiso suficiente para acceder al recurso de Azure. Para obtener más información, consulte Autorizar el acceso con el identificador de Entra de Microsoft.

Para más información sobre la identidad administrada, consulte ¿Qué son las identidades administradas para los recursos de Azure?.

Otros tipos de credenciales

Si desea tener más control o el escenario no lo sirve el DefaultAzureCredential o la configuración predeterminada, debe usar otros tipos de credenciales.

Autenticación y autorización con el identificador de Entra de Microsoft

Con microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad, que puede ser un usuario o una entidad de servicio de aplicación. Cuando una entidad de seguridad (un usuario o una aplicación) intenta acceder a un recurso de Azure, por ejemplo, un recurso de Event Hubs, la solicitud debe estar autorizada. Con microsoft Entra ID, el acceso a un recurso es un proceso de dos pasos:

  1. En primer lugar, se autentica la identidad de la entidad de seguridad y se devuelve un token de OAuth 2.0.
  2. A continuación, el token se pasa como parte de una solicitud al servicio de Azure para autorizar el acceso al recurso especificado.

Autenticación con el identificador de Entra de Microsoft

Para conectar aplicaciones a recursos que admiten la autenticación de Microsoft Entra, puede establecer las siguientes configuraciones con el prefijo spring.cloud.azure.credential o spring.cloud.azure.<azure-service>.credential

En la tabla siguiente se enumeran las propiedades de autenticación:

Propiedad Descripción
client-id Identificador de cliente que se va a usar al realizar la autenticación de entidad de servicio con Azure.
client-secret Secreto de cliente que se va a usar al realizar la autenticación de entidad de servicio con Azure.
client-certificate-path Ruta de acceso de un archivo de certificado PEM que se usará al realizar la autenticación de la entidad de servicio con Azure.
client-certificate-password Contraseña del archivo de certificado.
nombre de usuario Nombre de usuario que se va a usar al realizar la autenticación de nombre de usuario y contraseña con Azure.
contraseña Contraseña que se va a usar al realizar la autenticación de nombre de usuario y contraseña con Azure.
managed-identity-enabled Si se va a habilitar la identidad administrada.

Propina

Para obtener la lista de todas las propiedades de configuración de Azure de Spring Cloud, consulte propiedades de configuración de Azure de Spring Cloud.

La aplicación buscará en varios lugares para encontrar una credencial disponible y usará DefaultAzureCredential si no hay ninguna propiedad de credencial configurada. Si desea usar credenciales específicas, consulte los ejemplos siguientes para obtener instrucciones.

En el ejemplo siguiente se muestra cómo autenticarse mediante una identidad administrada asignada por el sistema:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true

En el ejemplo siguiente se muestra cómo autenticarse mediante una identidad administrada asignada por el usuario:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
    client-id: ${AZURE_CLIENT_ID}

En el ejemplo siguiente se muestra cómo autenticarse mediante una entidad de servicio con un secreto de cliente:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-secret: ${AZURE_CLIENT_SECRET}
  profile:
    tenant-id: <tenant>

Nota

Los valores permitidos para tenant-id son: common, organizations, consumerso el identificador de inquilino. Para obtener más información sobre estos valores, consulte la sección Uso del punto de conexión incorrecto (cuentas personales y de organización) de Error AADSTS50020: la cuenta de usuario del proveedor de identidades no existe en el inquilino. Para obtener información sobre cómo convertir la aplicación de un solo inquilino, consulte Convertir aplicación de un solo inquilino en multiinquilino en microsoft Entra ID.

En el ejemplo siguiente se muestra cómo autenticarse mediante una entidad de servicio con un certificado PFX de cliente:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
    client-certificate-password: ${AZURE_CLIENT_CERTIFICATE_PASSWORD}
  profile:
    tenant-id: <tenant>

Nota

Los valores permitidos para tenant-id son: common, organizations, consumerso el identificador de inquilino. Para obtener más información sobre estos valores, consulte la sección Uso del punto de conexión incorrecto (cuentas personales y de organización) de Error AADSTS50020: la cuenta de usuario del proveedor de identidades no existe en el inquilino. Para obtener información sobre cómo convertir la aplicación de un solo inquilino, consulte Convertir aplicación de un solo inquilino en multiinquilino en microsoft Entra ID.

En el ejemplo siguiente se muestra cómo autenticarse mediante una entidad de servicio con el certificado PEM de cliente:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
  profile:
    tenant-id: <tenant>

Nota

Los valores permitidos para tenant-id son: common, organizations, consumerso el identificador de inquilino. Para obtener más información sobre estos valores, consulte la sección Uso del punto de conexión incorrecto (cuentas personales y de organización) de Error AADSTS50020: la cuenta de usuario del proveedor de identidades no existe en el inquilino. Para obtener información sobre cómo convertir la aplicación de un solo inquilino, consulte Convertir aplicación de un solo inquilino en multiinquilino en microsoft Entra ID.

En el ejemplo siguiente se muestra cómo autenticarse mediante una credencial de usuario:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    username: ${AZURE_USER_USERNAME}
    password: ${AZURE_USER_PASSWORD}

En el ejemplo siguiente se muestra cómo autenticarse con Key Vault mediante una entidad de servicio diferente. En este ejemplo se configura la aplicación con dos credenciales: una identidad administrada asignada por el sistema y una entidad de servicio. El cliente secreto de Key Vault usará la entidad de servicio, pero cualquier otro componente usará la identidad administrada en su lugar.

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
  keyvault.secret:
    credential:
      client-id: ${AZURE_CLIENT_ID}
      client-secret: ${AZURE_CLIENT_SECRET}
    profile:
      tenant-id: <tenant>

Nota

Los valores permitidos para tenant-id son: common, organizations, consumerso el identificador de inquilino. Para obtener más información sobre estos valores, consulte la sección Uso del punto de conexión incorrecto (cuentas personales y de organización) de Error AADSTS50020: la cuenta de usuario del proveedor de identidades no existe en el inquilino. Para obtener información sobre cómo convertir la aplicación de un solo inquilino, consulte Convertir aplicación de un solo inquilino en multiinquilino en microsoft Entra ID.

Autorización del acceso con el identificador de Entra de Microsoft

El paso de autorización requiere que se asignen uno o varios roles de Azure a la entidad de seguridad. Los roles asignados a una entidad de seguridad determinan los permisos que tendrá la entidad de seguridad.

Propina

Para obtener la lista de todos los roles integrados de Azure, consulte roles integrados de Azure.

En la tabla siguiente se enumeran los roles integrados de Azure para autorizar el acceso a los servicios de Azure admitidos en Spring Cloud Azure:

Rol Descripción
propietario de datos de App Configuration Permite el acceso total a los datos de App Configuration.
lector de datos de App Configuration Permite el acceso de lectura a los datos de App Configuration.
propietario de datos de Azure Event Hubs Permite el acceso total a los recursos de Azure Event Hubs.
receptor de datos de Azure Event Hubs Permite recibir acceso a los recursos de Azure Event Hubs.
remitente de datos de Azure Event Hubs Permite el acceso de envío a los recursos de Azure Event Hubs.
propietario de datos de Azure Service Bus Permite el acceso total a los recursos de Azure Service Bus.
receptor de datos de Azure Service Bus Permite recibir acceso a los recursos de Azure Service Bus.
remitente de datos de Azure Service Bus Permite el acceso de envío a los recursos de Azure Service Bus.
propietario de datos de blobs de almacenamiento de Proporciona acceso total a los contenedores y datos de blobs de Azure Storage, incluida la asignación de control de acceso POSIX.
lector de datos de Blob storage de Leer y enumerar contenedores y blobs de Azure Storage.
lector de datos de cola de Storage Leer y enumerar colas y mensajes de cola de Azure Storage.
colaborador de Redis Cache Administrar cachés de Redis.

Nota

Al usar Spring Cloud Azure Resource Manager para obtener las cadenas de conexión de Event Hubs, Service Bus y Storage Queue, o las propiedades de Cache for Redis, asigne el rol integrado de Azure Contributor. Azure Cache for Redis es especial y también puede asignar el rol de Redis Cache Contributor para obtener las propiedades de Redis.

Nota

Una directiva de acceso de Key Vault determina si una entidad de seguridad determinada, es decir, un usuario, una aplicación o un grupo de usuarios, puede realizar diferentes operaciones en secretos, claves y certificados de Key Vault. Puede asignar directivas de acceso mediante Azure Portal, la CLI de Azure o Azure PowerShell. Para obtener más información, consulte Asignación de una directiva de acceso de Key Vault.

Importante

Azure Cosmos DB expone dos definiciones de roles integradas: Cosmos DB Built-in Data Reader y Cosmos DB Built-in Data Contributor. Sin embargo, la compatibilidad de Azure Portal con la administración de roles aún no está disponible. Para obtener más información sobre el modelo de permisos, las definiciones de roles y la asignación de roles, consulte Configuración del control de acceso basado en roles con el identificador de Entra de Microsoft para la cuenta de Azure Cosmos DB.

Tokens de SAS

También puede configurar servicios para la autenticación con firma de acceso compartido (SAS). spring.cloud.azure.<azure-service>.sas-token es la propiedad que se va a configurar. Por ejemplo, use spring.cloud.azure.storage.blob.sas-token para autenticarse en Storage Blob service.

Cadenas de conexión

Algunos servicios de Azure admiten la cadena de conexión para proporcionar información de conexión y credenciales. Para conectarse a esos servicios de Azure mediante una cadena de conexión, solo tiene que configurar spring.cloud.azure.<azure-service>.connection-string. Por ejemplo, configure spring.cloud.azure.eventhubs.connection-string para conectarse al servicio Event Hubs.