Delen via

Spring Cloud Azure-verificatie

  • Artikel

Dit artikel is van toepassing op:✅ versie 4.19.0 ✅ versie 5.21.0

In dit artikel worden alle Spring Cloud Azure-verificatiemethoden beschreven.

Verificatie en autorisatie met Microsoft Entra-id

Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. Dit kan een gebruiker of toepassingsservice-principal zijn. Wanneer een beveiligingsprincipaal (een gebruiker of een toepassing) probeert toegang te krijgen tot een Azure-resource, bijvoorbeeld een Event Hubs-resource, moet de aanvraag worden geautoriseerd. Met Microsoft Entra ID is toegang tot een resource een proces in twee stappen:

  1. Eerst wordt de identiteit van de beveiligingsprincipaal geverifieerd en wordt een OAuth 2.0-token geretourneerd.
  2. Vervolgens wordt het token doorgegeven als onderdeel van een aanvraag aan de Azure-service om toegang tot de opgegeven resource te autoriseren.

Referentietypen

Met Spring Cloud Azure kunt u verschillende referentietypen configureren voor verificatie, waaronder DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, AzureCliCredentialenzovoort.

DefaultAzureCredential

DefaultAzureCredential geschikt is voor de meeste scenario's waarin de toepassing is bedoeld om te worden uitgevoerd in de Azure Cloud, omdat de volgende referenties worden gecombineerd:

  • Referenties die vaak worden gebruikt voor verificatie bij implementatie.
  • Referenties die worden gebruikt voor verificatie in een ontwikkelomgeving.

Notitie

DefaultAzureCredential is bedoeld om aan de slag te gaan met de Azure SDK te vereenvoudigen door veelvoorkomende scenario's met redelijk standaardgedrag te verwerken. Als u meer controle wilt of als de standaardinstellingen uw scenario niet ondersteunen, moet u andere referentietypen gebruiken.

DefaultAzureCredential probeert te verifiëren via de volgende mechanismen:

diagram met het verificatiemechanisme voor DefaultAzureCredential.

  • Omgeving: DefaultAzureCredential probeert accountgegevens te lezen die zijn opgegeven via omgevingsvariabelen en deze te gebruiken om te verifiëren.
  • Beheerde identiteit: als de toepassing wordt geïmplementeerd op een Azure-host waarvoor Managed Identity is ingeschakeld, DefaultAzureCredential probeert te verifiëren met dat account.
  • Workloadidentiteit: als de toepassing wordt geïmplementeerd op een virtuele machine (VM), probeert DefaultAzureCredential te verifiëren met dat account.
  • Gedeelde tokencache: als u bent geverifieerd via Visual Studio, DefaultAzureCredential probeert te verifiëren met dat account.
  • IntelliJ: als u bent geverifieerd via Azure Toolkit voor IntelliJ, probeert DefaultAzureCredential te verifiëren met dat account.
  • Azure CLI: als u een account hebt geverifieerd via de azure CLI-opdracht az login, probeert DefaultAzureCredential te verifiëren met dat account.
  • Azure PowerShell: als u bent geverifieerd via Azure PowerShell, probeert DefaultAzureCredential te verifiëren met dat account.
  • Azure Developer CLI: als u bent geverifieerd via de Azure Developer CLI, probeert DefaultAzureCredential te verifiëren met dat account.

Fooi

Zorg ervoor dat de beveiligingsprincipaal voldoende machtigingen heeft om toegang te krijgen tot de Azure-resource. Zie Toegang autoriseren met Microsoft Entra IDvoor meer informatie.

Notitie

Sinds Spring Cloud Azure AutoConfigure 4.1.0 moet u een ThreadPoolTaskExecutor bean met de naam springCloudAzureCredentialTaskExecutor registreren om alle threads te beheren die zijn gemaakt door Azure Identity. De naam van elke thread die wordt beheerd door deze threadgroep, wordt voorafgegaan door az-identity-. Deze ThreadPoolTaskExecutor bean is onafhankelijk van de Executor bean die wordt geleverd door Spring Boot.

Beheerde identiteiten

Een veelvoorkomende uitdaging is het beheer van geheimen en referenties die worden gebruikt om de communicatie tussen verschillende onderdelen van een oplossing te beveiligen. Beheerde identiteiten elimineren de noodzaak om referenties te beheren. Beheerde identiteiten bieden een identiteit die toepassingen kunnen gebruiken bij het maken van verbinding met resources die ondersteuning bieden voor Microsoft Entra-verificatie. Toepassingen kunnen de beheerde identiteit gebruiken om Microsoft Entra-tokens te verkrijgen. Een toepassing kan bijvoorbeeld een beheerde identiteit gebruiken om toegang te krijgen tot resources zoals Azure Key Vault, waar u referenties op een veilige manier kunt opslaan of toegang hebt tot opslagaccounts.

We raden u aan om een beheerde identiteit te gebruiken in plaats van een verbindingsreeks of sleutel in uw toepassing te gebruiken, omdat deze veiliger is en de problemen met het beheren van geheimen en referenties opslaat. In dit geval kan DefaultAzureCredential het scenario van het lokaal ontwikkelen met behulp van accountgegevens die lokaal zijn opgeslagen, de toepassing vervolgens implementeren in Azure Cloud en beheerde identiteit gebruiken.

Typen beheerde identiteiten

Er zijn twee typen beheerde identiteiten:

  • door het systeem toegewezen: met sommige Azure-services kunt u een beheerde identiteit rechtstreeks op een service-exemplaar inschakelen. Wanneer u een door het systeem toegewezen beheerde identiteit inschakelt, wordt er een identiteit gemaakt in Microsoft Entra die is gebonden aan de levenscyclus van dat service-exemplaar. Dus wanneer de resource wordt verwijderd, wordt de identiteit automatisch voor u verwijderd. Alleen die Azure-resource kan deze identiteit gebruiken om tokens aan te vragen bij Microsoft Entra-id.
  • door de gebruiker toegewezen: u kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. U kunt een door de gebruiker toegewezen beheerde identiteit maken en deze toewijzen aan een of meer exemplaren van een Azure-service. Met door de gebruiker toegewezen beheerde identiteiten wordt de identiteit afzonderlijk beheerd van de resources die deze gebruiken.

Notitie

Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, kunt u de client-id opgeven via spring.cloud.azure.credential.client-id of spring.cloud.azure.<azure-service>.credential.client-id. U hebt geen referentieconfiguratie nodig als u een door het systeem toegewezen beheerde identiteit gebruikt.

Fooi

Als u toegang wilt krijgen tot de Azure-resource, moet u ervoor zorgen dat de beveiligingsprincipaal voldoende machtigingen heeft. Zie Toegang autoriseren met Microsoft Entra IDvoor meer informatie.

Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten?.

Andere referentietypen

Als u meer controle wilt dan wat wordt geleverd door DefaultAzureCredential, of als de standaardinstellingen uw scenario niet ondersteunen, moet u andere referentietypen gebruiken.

Verifiëren met Microsoft Entra-id

Als u toepassingen wilt verbinden met resources die ondersteuning bieden voor Microsoft Entra-verificatie, kunt u de volgende configuraties instellen met het voorvoegsel spring.cloud.azure.credential of spring.cloud.azure.<azure-service>.credential

De volgende tabel bevat verificatie-eigenschappen:

Eigenschap Beschrijving
client-id De client-id die moet worden gebruikt bij het uitvoeren van service-principal-verificatie met Azure.
clientgeheim Het clientgeheim dat moet worden gebruikt bij het uitvoeren van service-principal-verificatie met Azure.
client-certificate-path Pad van een PEM-certificaatbestand dat moet worden gebruikt bij het uitvoeren van service-principalverificatie met Azure.
client-certificate-password Het wachtwoord van het certificaatbestand.
gebruikersnaam De gebruikersnaam die moet worden gebruikt bij het uitvoeren van verificatie met gebruikersnaam en wachtwoord met Azure.
wachtwoord Het wachtwoord dat moet worden gebruikt bij het uitvoeren van verificatie met gebruikersnaam en wachtwoord met Azure.
beheerde identiteit ingeschakeld Of beheerde identiteit moet worden ingeschakeld.
token-credential-bean-name De naam van het type bean TokenCredential te gebruiken bij het uitvoeren van verificatie met Azure.

Fooi

Zie Configuratie-eigenschappen van Spring Cloud Azurevoor de lijst met alle eigenschappen van Spring Cloud Azure-configuratie.

De toepassing zoekt op verschillende plaatsen naar een beschikbare referentie. Elke Azure SDK-clientbouwerfactory neemt eerst een aangepaste bean van het type TokenCredential als de eigenschap token-credential-bean-name is opgegeven en valt terug om DefaultAzureCredential te gebruiken als er geen referentie-eigenschappen zijn geconfigureerd.

Verifiëren met een aangepast tokenCredential bean

In het volgende voorbeeld ziet u hoe u een aangepaste TokenCredential bean definieert om de verificatie uit te voeren:

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

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

Verifiëren met behulp van een door het systeem toegewezen beheerde identiteit

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een door het systeem toegewezen beheerde identiteit:

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

Verifiëren met een door de gebruiker toegewezen beheerde identiteit

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een door de gebruiker toegewezen beheerde identiteit:

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

Verifiëren met behulp van een service-principal met clientgeheim

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een service-principal met een clientgeheim:

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

Notitie

De waarden die zijn toegestaan voor tenant-id zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het Het verkeerde eindpunt (persoonlijke en organisatieaccounts) gebruikt sectie van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in tenant. Zie App met één tenant converteren naar multitenant op Microsoft Entra IDvoor meer informatie over het converteren van uw app met één tenant.

Verifiëren met behulp van een service-principal met clientcertificaat

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een service-principal met een PFX-clientcertificaat:

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>

Notitie

De waarden die zijn toegestaan voor tenant-id zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het Het verkeerde eindpunt (persoonlijke en organisatieaccounts) gebruikt sectie van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in tenant. Zie App met één tenant converteren naar multitenant op Microsoft Entra IDvoor meer informatie over het converteren van uw app met één tenant.

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een service-principal met een PEM-clientcertificaat:

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

Notitie

De waarden die zijn toegestaan voor tenant-id zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het Het verkeerde eindpunt (persoonlijke en organisatieaccounts) gebruikt sectie van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in tenant. Zie App met één tenant converteren naar multitenant op Microsoft Entra IDvoor meer informatie over het converteren van uw app met één tenant.

Verifiëren met behulp van een gebruikersreferentie

In het volgende voorbeeld ziet u hoe u zich verifieert met behulp van een gebruikersreferentie:

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

Een service verifiëren met een andere referentie dan anderen

In het volgende voorbeeld ziet u hoe u zich verifieert met Key Vault met behulp van een andere service-principal. In dit voorbeeld wordt de toepassing geconfigureerd met twee referenties: één door het systeem toegewezen beheerde identiteit en één service-principal. De Key Vault Secret-client maakt gebruik van de service-principal, maar andere onderdelen gebruiken in plaats daarvan beheerde identiteiten.

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>

Notitie

De waarden die zijn toegestaan voor tenant-id zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het Het verkeerde eindpunt (persoonlijke en organisatieaccounts) gebruikt sectie van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in tenant. Zie App met één tenant converteren naar multitenant op Microsoft Entra IDvoor meer informatie over het converteren van uw app met één tenant.

Toegang autoriseren met Microsoft Entra-id

Voor de autorisatiestap moeten een of meer Azure-rollen worden toegewezen aan de beveiligingsprincipaal. De rollen die zijn toegewezen aan een beveiligingsprincipaal bepalen de machtigingen die de principal heeft.

Fooi

Zie ingebouwde Azure-rollenvoor de lijst met alle ingebouwde Azure-rollen.

De volgende tabel bevat de ingebouwde Azure-rollen voor het autoriseren van toegang tot Azure-services die worden ondersteund in Spring Cloud Azure:

Rol Beschrijving
App Configuration-gegevenseigenaar Hiermee heeft u volledige toegang tot App Configuration-gegevens.
App Configuration-gegevenslezer Hiermee staat u leestoegang tot App Configuration-gegevens toe.
Azure Event Hubs-gegevenseigenaar Biedt volledige toegang tot Azure Event Hubs-resources.
Azure Event Hubs-gegevensontvanger Hiermee krijgt u toegang tot Azure Event Hubs-resources.
Azure Event Hubs-gegevenszender Hiermee kunt u toegang tot Azure Event Hubs-resources verzenden.
Azure Service Bus-gegevenseigenaar Biedt volledige toegang tot Azure Service Bus-resources.
Azure Service Bus-gegevensontvanger Hiermee krijgt u toegang tot Azure Service Bus-resources.
Azure Service Bus-gegevenszender Hiermee kunt u toegang tot Azure Service Bus-resources verzenden.
eigenaar van opslagblobgegevens Biedt volledige toegang tot Azure Storage-blobcontainers en -gegevens, waaronder het toewijzen van POSIX-toegangsbeheer.
Storage Blob-gegevenslezer Azure Storage-containers en -blobs lezen en vermelden.
Storage Queue Data Reader Azure Storage-wachtrijen en wachtrijberichten lezen en vermelden.
Redis Cache-inzender Redis-caches beheren.

Notitie

Wanneer u Spring Cloud Azure Resource Manager gebruikt om de verbindingsreeksen op te halen voor Event Hubs, Service Bus en Storage Queue, of de eigenschappen van Cache voor Redis, wijst u de ingebouwde Azure-rol toe Contributor. Azure Cache voor Redis is speciaal en u kunt ook de Redis Cache Contributor rol toewijzen om de Redis-eigenschappen op te halen.

Notitie

Een Key Vault-toegangsbeleid bepaalt of een bepaalde beveiligingsprincipaal, namelijk een gebruiker, toepassing of gebruikersgroep, verschillende bewerkingen kan uitvoeren op Key Vault-geheimen, -sleutels en -certificaten. U kunt toegangsbeleid toewijzen met behulp van Azure Portal, de Azure CLI of Azure PowerShell. Zie Key Vault-toegangsbeleid toewijzenvoor meer informatie.

Belangrijk

Azure Cosmos DB biedt twee ingebouwde roldefinities: Cosmos DB Built-in Data Reader en Cosmos DB Built-in Data Contributor. Azure Portal-ondersteuning voor rolbeheer is echter nog niet beschikbaar. Zie Op rollen gebaseerd toegangsbeheer configureren met Microsoft Entra ID voor uw Azure Cosmos DB-accountvoor meer informatie over het machtigingsmodel, roldefinities en roltoewijzing.

Verifiëren met SAS-tokens

U kunt ook services configureren voor verificatie met Shared Access Signature (SAS). spring.cloud.azure.<azure-service>.sas-token is de eigenschap die moet worden geconfigureerd. Gebruik bijvoorbeeld spring.cloud.azure.storage.blob.sas-token om te verifiëren bij de Storage Blob-service.

Verifiëren met behulp van verbindingsreeksen

Sommige Azure-services ondersteunen verbindingsreeks om verbindingsgegevens en referenties te bieden. Als u verbinding wilt maken met deze Azure-services met behulp van de verbindingsreeks, hoeft u alleen spring.cloud.azure.<azure-service>.connection-stringte configureren. Configureer bijvoorbeeld spring.cloud.azure.eventhubs.connection-string om verbinding te maken met de Event Hubs-service.