Spring Cloud Azure-verificatie

Dit artikel is van toepassing op: ✔️ versie 4.14.0 ✔️ versie 5.8.0

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

DefaultAzureCredential

Dit DefaultAzureCredential is geschikt voor de meeste scenario's waarin de toepassing moet worden uitgevoerd in de Azure Cloud. Dit komt doordat de DefaultAzureCredential referenties die vaak worden gebruikt voor verificatie, worden gecombineerd 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 veelvoorkomende 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 op volgorde via de volgende mechanismen te verifiëren:

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

Tip

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

Notitie

Aangezien Spring Cloud Azure AutoConfigure 4.1.0 is, 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 nemen de noodzaak voor ontwikkelaars weg 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 verbindingsreeks of sleutel in uw toepassing te gebruiken, omdat deze veiliger is en de problemen met het beheren van geheimen en referenties zal besparen. In dit geval DefaultAzureCredential kan het scenario van het lokaal ontwikkelen beter worden gebruikt met behulp van accountgegevens die lokaal zijn opgeslagen, en vervolgens de toepassing in Azure Cloud implementeren en beheerde identiteit gebruiken.

Typen beheerde identiteiten

Er zijn twee typen beheerde identiteit:

• 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. Als de resource wordt verwijderd, wordt de identiteit automatisch door Azure voor u verwijderd. Standaard kan alleen die Azure-resource deze identiteit gebruiken voor het aanvragen van tokens van 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.managed-identity-client-id of spring.cloud.azure.<azure-service>.credential.managed-identity-client-id. U hebt geen referentieconfiguratie nodig als u een door het systeem toegewezen beheerde identiteit gebruikt.

Tip

Zorg ervoor dat aan de beveiligingsprincipaal voldoende machtigingen zijn verleend voor toegang tot de Azure-resource. Zie Toegang autoriseren met Microsoft Entra-id voor 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:

Eigenschappen	Beschrijving
client-id	De client-id die moet worden gebruikt bij het uitvoeren van service-principal-verificatie met Azure.
client-secret	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.
password	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.

Tip

Zie De configuratie-eigenschappen van Spring Cloud Azure voor de lijst met alle configuratie-eigenschappen van Spring Cloud Azure.

De toepassing zoekt op verschillende plaatsen naar een beschikbare referentie en wordt 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 toegestane tenant-id waarden zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het verkeerde eindpunt (persoonlijke en organisatieaccounts) van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in de tenant. Zie De app met één tenant converteren naar meerdere tenants in Microsoft Entra ID voor 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 toegestane tenant-id waarden zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het verkeerde eindpunt (persoonlijke en organisatieaccounts) van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in de tenant. Zie De app met één tenant converteren naar meerdere tenants in Microsoft Entra ID voor 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 toegestane tenant-id waarden zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het verkeerde eindpunt (persoonlijke en organisatieaccounts) van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in de tenant. Zie De app met één tenant converteren naar meerdere tenants in Microsoft Entra ID voor 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 toegestane tenant-id waarden zijn: common, organizations, consumersof de tenant-id. Zie voor meer informatie over deze waarden het verkeerde eindpunt (persoonlijke en organisatieaccounts) van Fout AADSTS50020 - Gebruikersaccount van id-provider bestaat niet in de tenant. Zie De app met één tenant converteren naar meerdere tenants in Microsoft Entra ID voor 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.

Tip

Zie ingebouwde Azure-rollen voor 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
Eigenaar van app-configuratiegegevens	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.
Lezer voor opslagblobgegevens	Azure Storage-containers en -blobs lezen en vermelden.
Opslagwachtrijgegevenslezer	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 verbindingsreeks s voor Event Hubs, Service Bus en Storage Queue op te halen, of de eigenschappen van Cache voor Redis, wijst u de ingebouwde Azure-rol Contributortoe. Azure Cache voor Redis is speciaal en u kunt ook de rol toewijzen om de Redis Cache Contributor 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 Toegangsbeleid voor Key Vault toewijzen voor meer informatie.

Belangrijk

Azure Cosmos DB maakt twee ingebouwde roldefinities beschikbaar: 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-account voor 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

Verbinding maken iontekenreeks wordt ondersteund door sommige Azure-services om verbindingsgegevens en referenties te bieden. Als u verbinding wilt maken met deze Azure-services met behulp van verbindingsreeks, configureert u spring.cloud.azure.<azure-service>.connection-stringgewoon . Configureer spring.cloud.azure.eventhubs.connection-string bijvoorbeeld om verbinding te maken met de Event Hubs-service.