Authentification Spring Cloud Azure

Cet article explique les méthodes d’authentification spring Cloud Azure et vous aide à choisir le type d’informations d’identification approprié pour sécuriser l’accès aux ressources Azure.

Authentification et autorisation avec l’ID Microsoft Entra

En utilisant Microsoft Entra ID, vous pouvez utiliser Azure contrôle d’accès en fonction du rôle (Azure RBAC) pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur ou un principal de service d’application. Lorsqu’un principal de sécurité (un utilisateur ou une application) tente d’accéder à une ressource Azure, telle qu’une ressource Event Hubs, la demande doit être autorisée. En utilisant Microsoft Entra ID, l’accès à une ressource est un processus en deux étapes :

1. Tout d’abord, authentifiez l’identité du principal de sécurité et retournez un jeton OAuth 2.0.
2. Ensuite, transmettez le jeton dans le cadre d’une demande au service Azure pour autoriser l’accès à la ressource spécifiée.

Types d’informations d’identification

Spring Cloud Azure vous permet de configurer différents types d’informations d’identification pour l’authentification, notamment DefaultAzureCredential, , WorkloadIdentityCredentialManagedIdentityCredential, ClientSecretCredential, , AzureCliCredentialet bien plus encore.

DefaultAzureCredential

DefaultAzureCredential convient à la plupart des scénarios où l’application est destinée à s’exécuter dans le cloud Azure, car elle combine les informations d’identification suivantes :

• Informations d’identification couramment utilisées pour s’authentifier lors du déploiement.
• Informations d’identification utilisées pour s’authentifier dans un environnement de développement.

Remarque

DefaultAzureCredentialsimplifie la prise en main du Kit de développement logiciel (SDK) Azure en gérant des scénarios courants avec des comportements par défaut raisonnables. Si vous souhaitez un contrôle supplémentaire ou les paramètres par défaut ne prennent pas en charge votre scénario, utilisez d’autres types d’informations d’identification.

DefaultAzureCredential tente de s’authentifier via les mécanismes suivants dans l’ordre :

• Environnement : DefaultAzureCredential tente de lire les informations de compte spécifiées par le biais de variables d’environnement et de l’utiliser pour s’authentifier.
• Identité managée : si l’application est déployée sur un hôte Azure avec l’identité managée activée, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.
• Identité de la charge de travail : si l’application est déployée sur une machine virtuelle, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.
• Cache de jeton partagé : si vous vous êtes authentifié via Visual Studio, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.
• IntelliJ : si vous vous êtes authentifié via Azure Toolkit pour IntelliJ, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.
• Azure CLI : si vous avez authentifié un compte via la commande Azure CLIaz login, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.
• Azure PowerShell : si vous vous êtes authentifié via Azure PowerShell, DefaultAzureCredential tente de l’authentifier à l’aide de ce compte.
• Azure CLI développeur : si vous vous êtes authentifié via l’interface CLI Azure développeur, DefaultAzureCredential tente de s’authentifier à l’aide de ce compte.

Pourboire

Vérifiez que le principal de sécurité dispose d’une autorisation suffisante pour accéder à la ressource Azure. Pour plus d’informations, consultez Autoriser l’accès avec microsoft Entra ID.

Remarque

Étant donné que Spring Cloud Azure AutoConfigure 4.1.0 vous devez inscrire un ThreadPoolTaskExecutor bean nommé springCloudAzureCredentialTaskExecutor pour gérer tous les threads créés par Azure Identity. Le nom de chaque thread géré par ce pool de threads est préfixé par az-identity-. Cette ThreadPoolTaskExecutor haricot est indépendante de la Executor bean fournie par Spring Boot.

Identités managées

Un défi courant est la gestion des secrets et des informations d’identification utilisés pour sécuriser la communication entre différents composants constituant une solution. Les identités managées éliminent la nécessité de gérer les informations d’identification. Les identités managées fournissent une identité pour les applications à utiliser lors de la connexion aux ressources qui prennent en charge l’authentification Microsoft Entra. Les applications peuvent utiliser l’identité managée pour obtenir des jetons Microsoft Entra. Par exemple, une application peut utiliser une identité managée pour accéder aux ressources comme Azure Key Vault où vous pouvez stocker les informations d’identification de manière sécurisée ou pour accéder aux comptes de stockage.

Utilisez une identité managée au lieu d'utiliser chaîne de connexion ou clé dans votre application, car elle est plus sécurisée et enregistre le problème de gestion des secrets et des informations d'identification. Dans ce cas, DefaultAzureCredential mieux sert le scénario de développement local à l’aide d’informations de compte stockées localement, puis de déployer l’application sur Azure Cloud et à l’aide de l’identité managée.

Types d’identité managée

Il existe deux types d’identités managées :

• affectée par le système : certains services Azure vous permettent d’activer une identité managée directement sur une instance de service. Lorsque vous activez une identité managée affectée par le système, vous créez une identité dans Microsoft Entra liée au cycle de vie de cette instance de service. Par conséquent, lorsque vous supprimez la ressource, Azure supprime automatiquement l’identité pour vous. Par conception, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à partir de Microsoft Entra ID.
• Affecté par l’utilisateur : vous pouvez également créer une identité managée en tant que ressource Azure autonome. Vous pouvez créer une identité managée affectée par l’utilisateur et l’affecter à une ou plusieurs instances d’un service Azure. Avec les identités managées affectées par l’utilisateur, vous gérez l’identité séparément des ressources qui l’utilisent.

Remarque

Lorsque vous utilisez une identité managée affectée par l’utilisateur, spécifiez l’ID client via spring.cloud.azure.credential.client-id ou spring.cloud.azure.<azure-service>.credential.client-id. Vous n’avez pas besoin de configuration d’informations d’identification si vous utilisez une identité managée affectée par le système.

Pourboire

Pour accéder à la ressource Azure, vérifiez que le principal de sécurité dispose d’une autorisation suffisante. Pour plus d’informations, consultez Autoriser l’accès avec microsoft Entra ID.

Pour plus d’informations sur l’identité managée, consultez Qu’est-ce que les identités managées pour les ressources Azure ?.

Autres types d’informations d’identification

Si vous souhaitez plus de contrôle que ce qui est fourni par DefaultAzureCredential, ou les paramètres par défaut ne prennent pas en charge votre scénario, utilisez d’autres types d’informations d’identification.

S’authentifier avec l’ID Microsoft Entra

Pour connecter des applications aux ressources qui prennent en charge l’authentification Microsoft Entra, définissez les configurations suivantes avec le préfixe spring.cloud.azure.credential ou spring.cloud.azure.<azure-service>.credential.

Le tableau suivant répertorie les propriétés d’authentification :

Propriété	Descriptif
client-id	ID client à utiliser lors de l’authentification du principal de service avec Azure.
client-secret	Clé secrète client à utiliser lors de l’authentification du principal de service avec Azure.
client-certificate-path	Chemin d’un fichier de certificat PEM à utiliser lors de l’authentification du principal de service avec Azure.
client-certificate-password	Mot de passe du fichier de certificat.
username	Nom d’utilisateur à utiliser lors de l’exécution de l’authentification par nom d’utilisateur/mot de passe avec Azure.
password	Mot de passe à utiliser lors de l’exécution de l’authentification par nom d’utilisateur/mot de passe avec Azure.
managed-identity-enabled	Indique s’il faut activer l’identité managée.
token-credential-bean-name	Nom de type bean TokenCredential à utiliser lors de l’authentification avec Azure.

Pourboire

Pour obtenir la liste de toutes les propriétés de configuration d’Azure Spring Cloud, consultez propriétés de configuration d’Azure Spring Cloud.

L’application recherche plusieurs emplacements pour trouver des informations d’identification disponibles. Chaque fabrique de générateur de clients Kit de développement logiciel (SDK) Azure adopte d'abord un haricot de type TokenCredential personnalisé si vous spécifiez la propriété token-credential-bean-nameet que vous revenez à utiliser DefaultAzureCredential si vous ne configurez pas les propriétés d'informations d'identification.

S’authentifier à l’aide d’un bean TokenCredential personnalisé

L’exemple suivant montre comment définir un haricot personnalisé TokenCredential pour effectuer l’authentification :

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

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

S’authentifier à l’aide d’une identité managée affectée par le système

L’exemple suivant montre comment s’authentifier à l’aide d’une identité managée affectée par le système :

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

S’authentifier à l’aide d’une identité managée affectée par l’utilisateur

L’exemple suivant montre comment s’authentifier à l’aide d’une identité managée affectée par l’utilisateur :

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

S’authentifier à l’aide d’un principal de service avec une clé secrète client

L’exemple suivant montre comment s’authentifier à l’aide d’un principal de service avec une clé secrète client :

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

Remarque

Les valeurs autorisées pour tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la Utilisé le point de terminaison incorrect (comptes personnels et d’organisation) section Erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans ledu locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur Microsoft Entra ID.

S’authentifier à l’aide d’un principal de service avec un certificat client

L’exemple suivant montre comment s’authentifier à l’aide d’un principal de service avec un certificat PFX client :

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>

Remarque

Les valeurs autorisées pour tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la Utilisé le point de terminaison incorrect (comptes personnels et d’organisation) section Erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans ledu locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur Microsoft Entra ID.

L’exemple suivant montre comment s’authentifier à l’aide d’un principal de service avec un certificat PEM client :

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

Remarque

Les valeurs autorisées pour tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la Utilisé le point de terminaison incorrect (comptes personnels et d’organisation) section Erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans ledu locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur Microsoft Entra ID.

S’authentifier à l’aide d’informations d’identification de l’utilisateur

L’exemple suivant montre comment s’authentifier à l’aide d’informations d’identification de l’utilisateur :

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

Authentifier un service à l’aide d’informations d’identification différentes de celles d’autres utilisateurs

L’exemple suivant montre comment s’authentifier avec Key Vault à l’aide d’un autre principal de service. Cet exemple configure l’application avec deux informations d’identification : une identité managée affectée par le système et un principal de service. Le client secret Key Vault utilise le principal de service, mais tous les autres composants utilisent plutôt l’identité managée.

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>

Remarque

Les valeurs autorisées pour tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la Utilisé le point de terminaison incorrect (comptes personnels et d’organisation) section Erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans ledu locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur Microsoft Entra ID.

Autoriser l’accès avec l’ID Microsoft Entra

L’étape d’autorisation nécessite l’attribution d’un ou plusieurs rôles Azure au principal de sécurité. Les rôles que vous affectez à un principal de sécurité déterminent les autorisations dont dispose le principal.

Pourboire

Pour obtenir la liste de tous les rôles intégrés Azure, consultez rôles intégrés Azure.

Le tableau suivant répertorie les rôles intégrés Azure pour autoriser l’accès aux services Azure pris en charge dans Spring Cloud Azure :

Rôle	Descriptif
propriétaire des données App Configuration	Autorise l’accès complet aux données App Configuration.
lecteur de données App Configuration	Autorise l’accès en lecture aux données App Configuration.
propriétaire de données Azure Event Hubs	Autorise l’accès complet aux ressources Azure Event Hubs.
récepteur de données Azure Event Hubs	Autorise l’accès aux ressources Azure Event Hubs.
l’expéditeur de données Azure Event Hubs	Autorise l’accès aux ressources Azure Event Hubs.
propriétaire des données Azure Service Bus	Autorise l’accès complet aux ressources Azure Service Bus.
récepteur de données Azure Service Bus	Autorise l’accès aux ressources Azure Service Bus.
l’expéditeur de données Azure Service Bus	Autorise l’accès aux ressources Azure Service Bus.
propriétaire des données blob du stockage	Fournit un accès complet aux conteneurs et données d’objets blob Stockage Azure, y compris l’attribution du contrôle d’accès POSIX.
Lecteur de données blob de stockage	Lire et répertorier les conteneurs et objets blob stockage Azure.
lecteur de données de file d’attente de stockage	Lire et répertorier les files d’attente et les messages de file d’attente stockage Azure.
contributeur cache Redis	Gérer les caches Redis.

Remarque

Lorsque vous utilisez Spring Cloud Azure Resource Manager pour obtenir les chaînes de connexion pour Event Hubs, Service Bus et File d’attente de stockage, ou les propriétés du cache pour Redis, attribuez le rôle Contributorintégré Azure . Azure Cache pour Redis est spécial et vous pouvez également attribuer le rôle Redis Cache Contributor pour obtenir les propriétés Redis.

Remarque

Une stratégie d’accès Key Vault détermine si un principal de sécurité donné, à savoir un utilisateur, une application ou un groupe d’utilisateurs, peut effectuer différentes opérations sur Key Vault secrets, clés et certificats. Vous pouvez attribuer des stratégies d’accès à l’aide du portail Azure, du Azure CLI ou de la Azure PowerShell. Pour plus d’informations, consultez Affecter une stratégie d’accès Key Vault.

Important

Azure Cosmos DB expose deux définitions de rôle intégrées : Cosmos DB Built-in Data Reader et Cosmos DB Built-in Data Contributor. Toutefois, la prise en charge du portail Azure pour la gestion des rôles n’est pas encore disponible. Pour plus d’informations sur le modèle d’autorisation, les définitions de rôles et l’attribution de rôle, consultez Configurer le contrôle d’accès en fonction du rôle avec Microsoft Entra ID pour votre compte Azure Cosmos DB.

S’authentifier à l’aide de jetons SAP

Vous pouvez également configurer des services pour l’authentification à l’aide de la signature d’accès partagé (SAP). Utilisez la spring.cloud.azure.<azure-service>.sas-token propriété pour configurer cette authentification. Par exemple, utilisez cette option spring.cloud.azure.storage.blob.sas-token pour vous authentifier auprès du service d’objets blob de stockage.

S’authentifier à l’aide de chaînes de connexion

Certains services Azure prennent en charge les chaînes de connexion pour fournir des informations de connexion et des informations d’identification. Pour vous connecter à ces services Azure à l’aide de chaînes de connexion, configurez spring.cloud.azure.<azure-service>.connection-string. Par exemple, configurez spring.cloud.azure.eventhubs.connection-string pour vous connecter au service Event Hubs.