Spring Cloud Azure-verificatie

In dit artikel wordt uitgelegd hoe Spring Cloud Azure verificatiemethoden en u het juiste referentietype kunt kiezen om de toegang tot Azure resources te beveiligen.

Verificatie en autorisatie met Microsoft Entra-id

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

1. Verifieer eerst de identiteit van de beveiligingsprincipaal en retourneer een OAuth 2.0-token.
2. Geef vervolgens het token door 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, waaronderDefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, , ClientSecretCredentialen AzureCliCredentialmeer.

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

DefaultAzureCredentialvereenvoudigt het aan de slag gaan met de Azure SDK door algemene scenario's met redelijk standaardgedrag te verwerken. Als u meer controle wilt of als de standaardinstellingen uw scenario niet ondersteunen, gebruikt u andere referentietypen.

DefaultAzureCredential probeert te verifiëren via de volgende mechanismen:

• 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 Beheerde identiteit is ingeschakeld, DefaultAzureCredential probeert u te verifiëren met behulp van dat account.
• Workloadidentiteit: als de toepassing wordt geïmplementeerd op een virtuele machine (VM), DefaultAzureCredential probeert u te verifiëren met behulp van dat account.
• Gedeelde tokencache: als u bent geverifieerd via Visual Studio, DefaultAzureCredential probeert u te verifiëren met behulp van dat account.
• IntelliJ: als u bent geverifieerd via Azure Toolkit voor IntelliJ, DefaultAzureCredential probeert u zich te verifiëren met behulp van dat account.
• Azure CLI: als u een account hebt geverifieerd via de opdracht Azure CLIaz login, DefaultAzureCredential probeert u te verifiëren met behulp van dat account.
• Azure PowerShell: als u bent geverifieerd via Azure PowerShell, DefaultAzureCredential probeert u te verifiëren met behulp van dat account.
• Azure Developer CLI: als u bent geverifieerd via de Azure Developer CLI, DefaultAzureCredential probeert u zich te verifiëren met behulp van 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.

Gebruik beheerde identiteit 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 opslaat. In dit geval DefaultAzureCredential dient het scenario van het lokaal ontwikkelen beter met behulp van accountgegevens die lokaal zijn opgeslagen, en vervolgens de toepassing te implementeren in Azure Cloud en beheerde identiteit te 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, maakt u een identiteit in Microsoft Entra die is gebonden aan de levenscyclus van dat service-exemplaar. Dus wanneer u de resource verwijdert, verwijdert Azure automatisch de identiteit voor u. 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 beheert u de identiteit afzonderlijk van de resources die deze gebruiken.

Notitie

Wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt, geeft u de client-id 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 de beveiligingsprincipaal over voldoende machtigingen beschikt om toegang te krijgen 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

Gebruik andere referentietypen als u meer controle wilt dan wordt geleverd door DefaultAzureCredentialde standaardinstellingen of als de standaardinstellingen uw scenario niet ondersteunen.

Verifiëren met Microsoft Entra-id

Als u toepassingen wilt verbinden met resources die ondersteuning bieden voor Microsoft Entra verificatie, stelt u de volgende configuraties in 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.
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.
username	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.
managed-identity-enabled	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 client builder factory neemt eerst een aangepaste bean van het type TokenCredential als u de eigenschap token-credential-bean-nameopgeeft en valt terug om te gebruiken DefaultAzureCredential als u geen referentie-eigenschappen configureert.

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 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 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 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 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 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 kunt verifiëren 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 moet een of meer Azure rollen worden toegewezen aan de beveiligingsprincipaal. De rollen die u aan een beveiligingsprincipaal toewijst, 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.
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 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 Contributortoe. 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 de 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 behulp van SAS-tokens

U kunt ook services configureren voor verificatie met behulp van Shared Access Signature (SAS). Gebruik de spring.cloud.azure.<azure-service>.sas-token eigenschap om deze verificatie te configureren. 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 verbindingsreeksen om verbindingsgegevens en referenties te bieden. Als u verbinding wilt maken met deze Azure-services met behulp van verbindingsreeksen, configureert u spring.cloud.azure.<azure-service>.connection-string. Configureer bijvoorbeeld spring.cloud.azure.eventhubs.connection-string om verbinding te maken met de Event Hubs-service.