Delen via

Workloadidentiteitsfederatie

  • Artikel

Dit artikel biedt een overzicht van workloadidentiteitsfederatie voor softwareworkloads. Met behulp van workloadidentiteitsfederatie hebt u toegang tot met Microsoft Entra beveiligde resources zonder dat u geheimen hoeft te beheren (voor ondersteunde scenario's).

U kunt workloadidentiteitsfederatie gebruiken in scenario's zoals GitHub Actions, workloads die worden uitgevoerd in Kubernetes of workloads die worden uitgevoerd op rekenplatforms buiten Azure.

Waarom zou u workloadidentiteitsfederatie gebruiken?

Bekijk deze video om te zien waarom u workloadidentiteitsfederatie zou gebruiken.

Normaal gesproken heeft een softwareworkload (zoals een toepassing, service, script of containergebaseerde toepassing) een identiteit nodig om resources te kunnen verifiëren en openen of met andere services te kunnen communiceren. Wanneer deze workloads worden uitgevoerd in Azure, kunt u beheerde identiteiten gebruiken en het Azure-platform beheert de referenties voor u. U kunt echter alleen beheerde identiteiten gebruiken voor softwareworkloads die worden uitgevoerd in Azure. Voor een softwareworkload die buiten Azure wordt uitgevoerd, moet u toepassingsreferenties (een geheim of certificaat) gebruiken voor toegang tot met Microsoft Entra beveiligde resources (zoals Azure, Microsoft Graph, Microsoft 365 of resources van derden). Deze referenties vormen een beveiligingsrisico en moeten veilig worden opgeslagen en regelmatig worden geroteerd. U loopt ook het risico op service-downtime als de referenties verlopen.

U gebruikt workloadidentiteitsfederatie om een door de gebruiker toegewezen beheerde identiteit of app-registratie in Microsoft Entra ID te configureren om tokens te vertrouwen van een externe id-provider (IdP), zoals GitHub of Google. De door de gebruiker toegewezen beheerde identiteit of app-registratie in Microsoft Entra ID wordt een identiteit voor softwareworkloads die worden uitgevoerd, bijvoorbeeld in on-premises Kubernetes- of GitHub Actions-werkstromen. Zodra deze vertrouwensrelatie is gemaakt, wisselen uw externe softwareworkload vertrouwde tokens uit vanuit de externe IdP voor toegangstokens van het Microsoft Identity Platform. Uw softwareworkload gebruikt dat toegangstoken om toegang te krijgen tot de met Microsoft Entra beveiligde resources waaraan de workload toegang heeft gekregen. U elimineert de onderhoudslast van het handmatig beheren van referenties en elimineert het risico dat geheimen worden gelekt of certificaten verlopen.

Ondersteunde scenario's

De volgende scenario's worden ondersteund voor toegang tot met Microsoft Entra beveiligde resources met behulp van workloadidentiteitsfederatie:

  • Workloads die worden uitgevoerd op een Kubernetes-cluster (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE) of on-premises. Stel een vertrouwensrelatie tot stand tussen uw door de gebruiker toegewezen beheerde identiteit of app in Microsoft Entra-id en een Kubernetes-workload (beschreven in het overzicht van de workloadidentiteit).
  • GitHub Actions. Configureer eerst een vertrouwensrelatie tussen uw door de gebruiker toegewezen beheerde identiteit of toepassing in Microsoft Entra-id en een GitHub-opslagplaats in het Microsoft Entra-beheercentrum of met behulp van Microsoft Graph. Configureer vervolgens een GitHub Actions-werkstroom om een toegangstoken te verkrijgen van de Microsoft-id-provider en toegang te krijgen tot Azure-resources.
  • Google Cloud. Configureer eerst een vertrouwensrelatie tussen uw door de gebruiker toegewezen beheerde identiteit of app in Microsoft Entra ID en een identiteit in Google Cloud. Configureer vervolgens uw softwareworkload die wordt uitgevoerd in Google Cloud om een toegangstoken op te halen van de Microsoft-id-provider en toegang te krijgen tot met Microsoft Entra beveiligde resources. Zie Beveiligde bronnen van Microsoft Entra vanuit een app in Google Cloud.
  • Workloads die worden uitgevoerd in Amazon Web Services (AWS). Configureer eerst een vertrouwensrelatie tussen uw door de gebruiker toegewezen beheerde identiteit of app in Microsoft Entra ID en een identiteit in Amazon Cognito. Configureer vervolgens uw softwareworkload die wordt uitgevoerd in AWS om een toegangstoken van microsoft-id-provider op te halen en toegang te krijgen tot met Microsoft Entra beveiligde resources. Zie Federatie van workloadidentiteit met AWS.
  • Andere workloads die worden uitgevoerd op rekenplatforms buiten Azure. Configureer een vertrouwensrelatie tussen uw door de gebruiker toegewezen beheerde identiteit of toepassing in Microsoft Entra ID en de externe IdP voor uw rekenplatform. Tokens die door dat platform zijn uitgegeven, kunt u gebruiken om u te verifiëren bij het Microsoft-identiteitsplatform en API's aan te roepen in het Microsoft-ecosysteem. Gebruik de clientreferentiestroom om een toegangstoken op te halen uit het Microsoft-identiteitsplatform, waarbij de JWT van de id-provider wordt doorgegeven in plaats van dat u er zelf een maakt met behulp van een opgeslagen certificaat.
  • SPIFFE en SPIRE zijn een set platformagnostische, opensource-standaarden voor het bieden van identiteiten aan uw softwareworkloads die zijn geïmplementeerd in platformen en cloudleveranciers. Configureer eerst een vertrouwensrelatie tussen uw door de gebruiker toegewezen beheerde identiteit of app in Microsoft Entra ID en een SPIFFE-id voor een externe workload. Configureer vervolgens uw externe softwareworkload om een toegangstoken op te halen van de Microsoft-id-provider en toegang te krijgen tot met Microsoft Entra beveiligde resources. Zie Federatie van workloadidentiteit met SPIFFE en SPIRE.
  • Maak een nieuwe serviceverbinding in Azure Pipelines (preview). Maak een Azure Resource Manager-serviceverbinding met behulp van workloadidentiteitsfederatie.

Notitie

Door Microsoft Entra ID uitgegeven tokens kunnen niet worden gebruikt voor federatieve identiteitsstromen. De stroom federatieve identiteitsreferenties biedt geen ondersteuning voor tokens die zijn uitgegeven door Microsoft Entra ID.

Hoe het werkt

Maak een vertrouwensrelatie tussen de externe IdP en een door de gebruiker toegewezen beheerde identiteit of toepassing in Microsoft Entra-id. De federatieve identiteitsreferentie wordt gebruikt om aan te geven welk token van de externe IdP moet worden vertrouwd door uw toepassing of beheerde identiteit. U configureert een federatieve identiteit:

Notitie

De federatieve identiteitsreferenties issuer, subjecten audience waarden moeten hoofdlettergevoelig overeenkomen met de bijbehorende issuerwaarden subject en audience waarden die zijn opgenomen in het token dat door de externe IdP naar Microsoft Entra-id wordt verzonden om het scenario te kunnen geautoriseerd. Ga naar Wat is er nieuw voor verificatie voor meer informatie over deze wijziging.

De werkstroom voor het inwisselen van een extern token voor een toegangstoken is echter hetzelfde voor alle scenario's. In het volgende diagram ziet u de algemene werkstroom van een workload die een extern token voor een toegangstoken uitwisselt en vervolgens toegang krijgt tot met Microsoft Entra beveiligde resources.

Diagram met een extern token dat is uitgewisseld voor een toegangstoken en toegang tot Azure

  1. De externe workload (zoals een GitHub Actions-werkstroom) vraagt een token aan bij de externe IdP (zoals GitHub).
  2. De externe IdP geeft een token uit aan de externe workload.
  3. De externe workload (de aanmeldingsactie in een GitHub-werkstroom, bijvoorbeeld) verzendt het token naar het Microsoft Identity Platform en vraagt een toegangstoken aan.
  4. Microsoft Identity Platform controleert de vertrouwensrelatie op de door de gebruiker toegewezen beheerde identiteit of app-registratie en valideert het externe token op basis van de OIDC-verlener-URL (OpenID Connect) op de externe IdP.
  5. Wanneer aan de controles wordt voldaan, geeft het Microsoft-identiteitsplatform een toegangstoken uit aan de externe workload.
  6. De externe workload heeft toegang tot met Microsoft Entra beveiligde resources met behulp van het toegangstoken van het Microsoft Identity Platform. Een GitHub Actions-werkstroom gebruikt het toegangstoken bijvoorbeeld om een web-app te publiceren naar Azure App Service.

Het Microsoft Identity Platform slaat alleen de eerste 100 ondertekeningssleutels op wanneer deze worden gedownload van het OIDC-eindpunt van de externe IdP. Als de externe IdP meer dan 100 ondertekeningssleutels beschikbaar maakt, kunnen er fouten optreden bij het gebruik van workloadidentiteitsfederatie.

Volgende stappen

Meer informatie over hoe workloadidentiteitsfederatie werkt: