Delen via

Federatieconcepten van workload-identiteit

Meer informatie over hoe federatie van workloadidentiteiten beveiligde toegang tot met Microsoft Entra beveiligde resources mogelijk maakt zonder geheimen te beheren. Dit artikel bevat een overzicht van de voordelen en 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. Voor een softwareworkload die buiten Azure wordt uitgevoerd of die in Azure wordt uitgevoerd maar gebruik maakt van app-registraties voor hun identiteit, moet u toepassingsreferenties (een geheim of een certificaat) gebruiken om toegang te krijgen tot de door Microsoft Entra beschermde 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 een app-registratie in Microsoft Entra ID te configureren, zodat het tokens van een externe id-provider (IdP), zoals GitHub of Google, kan vertrouwen. 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 op te halen van de Microsoft-id-provider en toegang te krijgen tot Azure-resources.
  • Workloads die worden uitgevoerd op Azure-rekenplatforms met behulp van app-identiteiten. Wijs eerst een door de gebruiker toegewezen beheerde identiteit toe aan uw Azure-VM of App Service. Configureer vervolgens een vertrouwensrelatie tussen uw app en de door de gebruiker toegewezen identiteit.
  • 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 Toegang tot Microsoft Entra-beveiligde bronnen 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 workload-identiteit 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 van het Microsoft Identity Platform, 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 workload-identiteit met SPIFFE en SPIRE.
  • Maak een serviceverbinding in Azure Pipelines. 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. Voor meer informatie over deze wijziging, kijk op Wat is er nieuw voor verificatie.

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.

Zie ook

  • Last updated on