Spring Cloud Azure-verificatie

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

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

DefaultAzureCredential

De DefaultAzureCredential is geschikt voor de meeste scenario's waarin de toepassing moet worden uitgevoerd in de Azure Cloud. Dit komt doordat de DefaultAzureCredential referenties combineert die vaak worden gebruikt voor verificatie bij implementatie met referenties die worden gebruikt voor verificatie in een ontwikkelomgeving.

Notitie

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

De DefaultAzureCredential probeert zich te verifiëren via de volgende mechanismen in de volgende volgorde:

• Omgeving: de DefaultAzureCredential leest accountgegevens die zijn opgegeven via omgevingsvariabelen en gebruikt deze om te verifiëren.
• Beheerde identiteit: als de toepassing wordt geïmplementeerd op een Azure-host waarvoor Managed Identity is ingeschakeld, wordt de DefaultAzureCredential geverifieerd met dat account.
• IntelliJ: als u bent geverifieerd via Azure Toolkit voor IntelliJ, wordt de DefaultAzureCredential geverifieerd met dat account.
• Visual Studio Code: als u bent geverifieerd via de invoegtoepassing Azure-account van Visual Studio Code, wordt de DefaultAzureCredential geverifieerd met dat account.
• Azure CLI: als u een account hebt geverifieerd via de Azure CLI-opdracht az login, wordt de DefaultAzureCredential geverifieerd met dat account.

Fooi

Zorg ervoor dat aan de beveiligingsprincipaal voldoende machtigingen zijn verleend voor toegang tot de Azure-resource. Zie Toegang autoriseren met Microsoft Entra IDvoor meer informatie.

Notitie

Aangezien Spring Cloud Azure AutoConfigure 4.1.0, wordt een ThreadPoolTaskExecutor bean met de naam springCloudAzureCredentialTaskExecutor automatisch geregistreerd en worden alle threads beheerd die door Azure Identity zijn gemaakt. 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 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 gekoppeld 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

Zorg ervoor dat aan de beveiligingsprincipaal voldoende machtigingen zijn verleend voor toegang tot de Azure-resource. 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 of als uw scenario niet wordt geleverd door de DefaultAzureCredential of de standaardinstellingen, moet u andere referentietypen gebruiken.

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.

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.

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 en gebruikt DefaultAzureCredential als er geen referentie-eigenschappen zijn geconfigureerd. Als u specifieke referenties wilt gebruiken, raadpleegt u de volgende voorbeelden voor hulp.

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

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}

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.

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.

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}

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 gebruikt de service-principal, maar alle andere onderdelen gebruiken in plaats daarvan beheerde identiteit.

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.

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.

Verbindingsreeksen

Verbindingsreeks wordt ondersteund door sommige Azure-services 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.