Autenticación de Azure en Spring Cloud

  • Se aplica a: ✅ Version 4.20.0, ✅ Version 5.25.0, ✅ Version 6.4.0, ✅ Version 7.3.0

En este artículo se explican los métodos de autenticación de Spring Cloud Azure y le ayuda a elegir el tipo de credencial adecuado para proteger el acceso a los recursos de Azure.

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

Mediante el uso de Microsoft Entra ID, puede usar Azure control de acceso basado en rol (Azure RBAC) 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, como un recurso de Event Hubs, la solicitud debe estar autorizada. Mediante Microsoft Entra ID, el acceso a un recurso es un proceso de dos pasos:

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

Tipos de credenciales

Spring Cloud Azure permite configurar diferentes tipos de credenciales para la autenticación, como DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, , AzureCliCredentialy mucho más.

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, ya que combina las siguientes credenciales:

  • Credenciales que se suelen usar para autenticarse cuando se implementan.
  • Credenciales usadas para autenticarse en un entorno de desarrollo.

Nota

DefaultAzureCredentialsimplifica la introducción a la SDK de Azure mediante el control de escenarios comunes con comportamientos predeterminados razonables. Si quiere más control o la configuración predeterminada no admite su escenario, use otros tipos de credenciales.

DefaultAzureCredential intenta autenticarse a través de los siguientes mecanismos en orden:

Captura de pantalla del flujo de autenticación DefaultAzureCredential y el orden de las credenciales.

  • Entorno: DefaultAzureCredential intenta leer la información de la cuenta especificada a través de variables de entorno y usarla para autenticarse.
  • Identidad administrada: si la aplicación se implementa en un host de Azure con identidad administrada habilitada, DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • Identidad de carga de trabajo: si la aplicación se implementa en una máquina virtual (VM), DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • Caché de tokens compartidos: si se autentica a través de Visual Studio, DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • IntelliJ: si se ha autenticado a través de Azure Toolkit for IntelliJ, DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • CLI de Azure: si ha autenticado una cuenta mediante el comando CLI de Azureaz login, DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • Azure PowerShell: si se autentica a través de Azure PowerShell, DefaultAzureCredential intenta autenticarse mediante esa cuenta.
  • Azure CLI para desarrolladores: si se ha autenticado a través de la CLI para desarrolladores de Azure, DefaultAzureCredential intenta autenticarse mediante esa cuenta.

Propina

Asegúrese de que la entidad de seguridad tiene 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, debe registrar un ThreadPoolTaskExecutor bean denominado springCloudAzureCredentialTaskExecutor para 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.

Use la identidad administrada en lugar de usar cadena de conexión o clave en la aplicación porque es más seguro y ahorra los problemas de administración de secretos y credenciales. En este caso, sirve mejor el escenario de desarrollo localmente mediante el uso de la información de la cuenta almacenada localmente y, a continuación, DefaultAzureCredential la implementación de la aplicación en Azure Cloud y el uso de 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á enlazada al ciclo de vida de esa instancia de servicio. Por lo tanto, al eliminar el recurso, Azure elimina automáticamente la identidad por usted. 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. Con las identidades administradas asignadas por el usuario, se administra la identidad por separado de los recursos que lo usan.

Nota

Al usar una identidad administrada asignada por el usuario, especifique el identificador de cliente mediante 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

Para acceder al recurso Azure, asegúrese de que la entidad de seguridad tiene permiso suficiente. 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 de lo que proporciona DefaultAzureCredentialo la configuración predeterminada no admite su escenario, use otros tipos de credenciales.

Autenticación con el identificador de Entra de Microsoft

Para conectar aplicaciones a recursos que admiten Microsoft Entra autenticación, establezca 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.
token-credential-bean-name El nombre de bean de tipo TokenCredential que se va a usar al realizar la autenticación con Azure.

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 busca en varios lugares para encontrar una credencial disponible. Cada SDK de Azure generador de clientes adopta primero un bean personalizado de tipo TokenCredential si especifica la propiedad token-credential-bean-namey vuelve a usar DefaultAzureCredential si no configura las propiedades de credenciales.

Autenticación mediante un bean tokenCredential personalizado

En el ejemplo siguiente se muestra cómo definir un bean personalizado TokenCredential para realizar la autenticación:

@Bean
TokenCredential myTokenCredential() {
    // Your concrete TokenCredential instance
}

spring.cloud.azure:
  credential:
    token-credential-bean-name: myTokenCredential

Autenticación mediante una identidad administrada asignada por el sistema

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

Autenticación mediante una identidad administrada asignada por el usuario

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}

Autenticación mediante una entidad de servicio con secreto de cliente

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.

Autenticación mediante una entidad de servicio con certificado de cliente

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 un 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.

Autenticación mediante una credencial de usuario

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}

Autenticación de un servicio mediante una credencial diferente de otras

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 usa la entidad de servicio, pero cualquier otro componente usa 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 asignar uno o varios roles de Azure a la entidad de seguridad. Los roles que asigne a una entidad de seguridad determinan los permisos que tiene 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

Cuando se usa Spring Cloud Azure Resource Manager para obtener las cadenas de conexión de Event Hubs, Service Bus y Cola de Storage, o las propiedades de Cache for Redis, asigne el rol Contributorintegrado Azure . 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 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 Key Vault secretos, claves y certificados. Puede asignar directivas de acceso mediante el portal de Azure, el 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.

Autenticación mediante tokens de SAS

También puede configurar servicios para la autenticación mediante firma de acceso compartido (SAS). Use la spring.cloud.azure.<azure-service>.sas-token propiedad para configurar esta autenticación. Por ejemplo, use spring.cloud.azure.storage.blob.sas-token para autenticarse en storage Blob service.

Autenticación mediante cadenas de conexión

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

  • Last updated on