Autenticación de Azure en Spring Cloud

Este artículo se aplica a: ✔️ Versión 4.14.0 ✔️ versión 5.8.0

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

DefaultAzureCredential

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 combina DefaultAzureCredential las credenciales que se suelen usar para autenticarse cuando se implementan con credenciales usadas para autenticarse en un entorno de desarrollo.

Nota:

DefaultAzureCredential está diseñado 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.

DefaultAzureCredential intentará autenticarse mediante los siguientes mecanismos en orden:

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

Sugerencia

Asegúrese de que a la entidad de seguridad se le ha concedido permiso suficiente para acceder al recurso de Azure. Para más información, vea Autorización del acceso mediante Microsoft Entra ID.

Nota:

Dado que Spring Cloud Azure AutoConfigure 4.1.0, un ThreadPoolTaskExecutor bean denominado 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 az-identity-prefijo . 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 que usan las aplicaciones 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 cadena de conexión o clave en la aplicación porque es más seguro y ahorrará los problemas de administración de secretos y credenciales. En este caso, podría servir mejor el escenario de desarrollo localmente mediante la información de la cuenta almacenada localmente y, a continuación, DefaultAzureCredential implementar la aplicación en la nube de Azure y usar la identidad administrada.

Tipos de identidad administrada

Hay dos tipos de identidades administradas:

• Asignado por el sistema: algunos servicios de Azure permiten habilitar una identidad administrada directamente en una instancia de servicio. Cuando se habilita 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 tanto, cuando se elimina el recurso, Azure elimina automáticamente la identidad. Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Microsoft Entra ID.
• Asignado 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. En el caso de las identidades administradas asignadas por el usuario, la identidad se administra independientemente de los recursos que la utilicen.

Nota:

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

Sugerencia

Asegúrese de que a la entidad de seguridad se le ha concedido permiso suficiente para acceder al recurso de Azure. Para más información, vea Autorización del acceso mediante Microsoft Entra ID.

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 atiende o DefaultAzureCredential la configuración predeterminada, debe usar otros tipos de credenciales.

Autenticación y autorización con Microsoft Entra ID

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 Microsoft Entra ID

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.
username	Nombre de usuario que se va a usar al realizar la autenticación de nombre de usuario y contraseña con Azure.
password	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.

Sugerencia

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 la conversión de la aplicación de un solo inquilino, consulte Conversión de una aplicación de inquilino único en varios inquilinos 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 la conversión de la aplicación de un solo inquilino, consulte Conversión de una aplicación de inquilino único en varios inquilinos 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 la conversión de la aplicación de un solo inquilino, consulte Conversión de una aplicación de inquilino único en varios inquilinos 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 la conversión de la aplicación de un solo inquilino, consulte Conversión de una aplicación de inquilino único en varios inquilinos en microsoft Entra ID.

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

El paso de autorización exige que se asignen uno o varios roles de Azure a la entidad de seguridad. Los roles que se asignan a una entidad de seguridad determinan los permisos que tiene esa entidad de seguridad.

Sugerencia

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:

Role	Descripción
Propietario de los datos de App Configuration	Permite el acceso completo a los datos de App Configuration.
Lector de los datos de App Configuration	Permite el acceso de lectura a los datos de App Configuration.
Propietario de los datos de Azure Event Hubs	Permite el acceso total a los recursos de Azure Event Hubs.
Receptor de datos de Azure Event Hubs	Concede acceso de recepción a los recursos de Azure Event Hubs.
Emisor de datos de Azure Event Hubs	Concede acceso de emisión a los recursos de Azure Event Hubs.
Propietario de los 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.
Emisor 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	Proporciona acceso total a los contenedores de blobs y los datos de Azure Storage, incluida la asignación de control de acceso POSIX.
Lector de datos de blobs de almacenamiento	Lee y enumera blobs y contenedores de Azure Storage.
Lector de datos de la cola de Storage	Lee y enumera los mensajes de la cola y las colas de Azure Storage.
Colaborador de la memoria caché de Redis	Administrar cachés de Redis.

Nota:

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

Nota:

Una directiva de acceso de Key Vault determina si una entidad de seguridad concreta, es decir, un usuario, una aplicación o un grupo de usuarios, puede realizar distintas operaciones en los secretos, las claves y los certificados de Key Vault. Las directivas de acceso se pueden asignar mediante Azure Portal, la CLI de Azure o Azure PowerShell. Para 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 Conectar cadena para proporcionar información de conexión y credenciales. Para conectarse a esos servicios de Azure mediante 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.