Microsoft Entra ID - Workload Identities

📰 Blogserie Microsoft Entra ID – Identities

Microsoft Entra ID is een Identity Provider (IdP) met diverse soorten identities voor gecentraliseerde authenticatie en autorisatie in verschillende type tenants.

🗺️ Overzicht

Dit deel van de serie behandelt Workload Identities. Wil je liever eerst een ander onderwerp lezen? Onderaan deze blog vind je het overzicht van alle artikelen in deze serie!

naar het serie overzicht

Machine Identities

Entra ID onderscheidt diverse termen voor verschillende soorten identities. Naast Human Identities maakt Entra ID onderscheidt tussen Workload Identiteis en Device Identities.

Device Identities

Device Identities representeren apparaten zoals desktops, laptops, smartphones, en IoT beheerde apparaten. Voor meer informatie over dit type Identities zie Device Identities

Workload Identities

Workload identities zijn identities die je toekent aan software workloads zoals een applicatie, service, script of container, om te authentiseren en toegang te krijgen tot andere services en resources.
Wanneer een GitHub action bijvoorbeeld toegang nodig heeft tot een Azure subscriptie heeft deze GitHub action een workload identity met toegang tot die subscriptie nodig. In Microsoft Entra ID bestaan workload identities uit “applications” (app registrations), en “service principals” (enterprise applications, managed identities).

Hieronder volgt uitleg over deze type identities, maar wil je meer diepgaande informatie over access tokens (OAuth), id tokens (OIDC) en OAuth autorisatie flows dan is het raadzaam om eerst de blog Entra ID Identities – Authenticatie Protocollen in deze serie te lezen.

Entra ID App Registraties

Een Entra ID App Registratie is een representatie van je applicatie in je tenant. Met een App registratie laat je je applicatie door Entra ID veilig authentiseren en toegang vragen tot bepaalde resources.

Je applicatie heeft dus een identity nodig om zich te authentiseren voor toegang tot bijvoorbeeld een Azure resource met Azure Role Based Access Control (RBAC). RBAC bepaalt wat Entra ID identities met die resource mogen doen. De App registratie is niet de identity maar de representatie van je applicatie. Wanneer je een App registratie met de Entra portal maakt, wordt tegelijkertijd ook de bijbehorende identity, ofwel Enterprise Applicatie, ook wel Service Principal genoemd, aangemaakt.

Je kunt verschillende soorten applicaties registreren, zoals webapplicaties, single-page applicaties (SPA’s), mobile apps, en web-API’s. Tijdens de registratie kun je belangrijke instellingen configureren, zoals de redirect URI, die bepaalt waar Entra ID, na authenticatie, de autorisatie code en/of het access token naar toe moet sturen (zie Entra ID Identities – Authenticatie Protocollen).

De App registratie krijgt een Client ID (een globaal unieke identifier), een tenant ID (identificeert de tenant waarin de applicatie is geregistreerd) en optioneel een secret of certificaat voor authenticatie. Verder bevat de app registratie een of meerdere scopes (permissies). Dit zijn OAuth scopes die bepalen welke resources/acties de applicatie mag benaderen/uitvoeren. Wanneer je applicatie echter een Azure resource benadert vindt de autorisatie met Azure RBAC plaats en is de OAuth scope een ‘default’ scope voor de betreffende resource, bijvoorbeeld scope=https://storage.azure.com/.default.

Entra ID Enterprise Applications/Service Principals

Zoal zojuist beschreven hoort bij elke App registratie een Enterprise application. Een Enterprise application wordt ook wel service principal genoemd. Dit is de identity die gebruikt wordt voor authenticatie in Entra ID en autorisaties in Azure. Aan deze Identity (Enterprise App/Service principal) kun je dan ook een Azure rol (RBAC) toekennen.

Bovenstaand figuur toont een App registratie met bijbehorend Enterprise Application/Service Principal. De Enterprise Application krijgt dezelfde naam en CLIENT (Application) ID als je App Registratie. De applicatie, bijvoorbeeld een webapplicatie in een Azure Web App resource heeft het CLIENT ID en secret of certificaat nodig om zicht te authentiseren bij Entra ID. Dit secret haalt de applicatie bijvoorbeeld uit een file of beter uit een Azure KeyVault. (Maar hoe krijgt je applicatie toegang tot de Azure KeyVault?)

Na authenticatie krijgt de applicatie een OAuth access token (zie OAuth Client Credential Flow in de blogserie Entra ID Identities – Authenticatie Protocollen), waarmee de applicatie toegang krijgt tot de Azure resource, bijvoorbeeld een Azure storage account.

Een App registratie is globaal uniek en komt maar in één tenant voor. Een bijbehorend Enterprise Application/Service Principal kan in meerdere Entra ID tenants voorkomen wanneer het een multi tenant App registratie betreft:

Bovenstaand voorbeeld is nu uitgebreid met een multi-tenant App registratie in een andere Entra ID tenant (paars). In de andere tenant wordt al dan niet automatisch een bijbehorend Enterprise Application/Service Principal aangemaakt.
Om van deze App registratie een Enterprise Application/Service Principal in je “eigen” tenant te krijgen kun je Azure CLI gebruiken.

az ad sp create --id "Client ID"

Nu kun je voor dit Service Principal in je tenant de benodigde RBAC instellen en krijgt een applicatie uit een andere tenant toegang tot een resource in jouw tenant.
Standaard heeft Microsoft in ‘haar’ tenant ook App registraties met bijbehorende Enterprise Applications/Service Principals en komen veel van deze Service Principals standaard in je eigen tenant terecht.

Ook Service Principals van derde partijen zoals bijvoorbeeld Salesforce kunnen in je tenant voorkomen. Veel moderne applicaties maken gebruik van OAuth/OIDC, maar ook nog steeds heel veel applicaties gebruiken SAML als authenticatie protocol voor het realiseren van Single Sign On (SSO). Oudere Microsoft applicaties gebruiken WS-Federation (WS-Fed), en dan bestaan er nog legacy applicaties die password-bases SSO gebruiken. Indien gebruikt, komen voor al deze type applicaties Enterprise Applications/Service Principals in je tenant voor.

Gebruik in het menu van een Enterprise Application ‘Single sign-on’ om te bekijken wat voor type authenticatie protocol door het betreffende service principal gebruikt wordt:

Ook op SAML authenticatie gebaseerde applicaties hebben een gerelateerde App Registratie, maar deze zul je meestal niet terugvinden in je eigen tenant, omdat dit meestal applicaties zijn van derde partijen die in ‘hun’ home tenant een App registratie hebben.

Entra ID Managed Identities

Entra managed identities zijn ook Enterprise Applications/Service Principals. In tegenstelling tot ‘normale’ Enterprise Applications/Service Principals, waarbij een secret of certificaat geconfigureerd en beheerd moet worden in de bijbehorende App registratie, zorgt Azure hier voor het certificaat management van het Service Principal. Dat is dan ook het grote voordeel van managed identities, er is geen secret of certificaat beheer nodig. Managed Identities kunnen tegenwoordig zelfs tussen verschillende tenants gebruikt worden!

Je applicatie kan gebruik maken van een system assigned managed identity (SA MI) of user assigned managed identity (UA MI). Wanneer je gebruik maakt van een SA MI wordt de betreffende Azure resource, bijvoorbeeld een Azure Web App of Azure Virtuele Machine, gekoppeld aan een bijbehorend Service Principal.

Het aangemaakte service principal, met de dezelfde naam als de Azure resource, vind je in Entra ID – Enterprise Apps.

De Managed Identity Resource Provider (MIRP) in Azure maakt het Service Principal aan, verzorgt het certificaatbeheer en koppelt het Service Principal aan de betreffende Azure Resource. Wanneer je deze resource verwijdert wordt automatisch het Service Principal ook verwijderd.

Met het Azure CLI commando:

az login --identity

gebruikt je applicatie het gekoppeld Service Principal voor authenticatie en verkrijgt je applicatie een OAuth access token voor toegang tot een andere resource in dezelfde tenant. Uiteraard dient het Service Principal de juiste Azure Rol te hebben (RBAC).

De instance meta data service (IMDS) verzorgt de authenticatie en het verkrijgen van dit access token. Wanneer je az login –identity gebruikt roept je applicatie de IMDS aan met het verzoek voor een access token voor een specifieke resource.
Een dergelijk verzoek ziet er bijvoorbeeld als volgt uit:
GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2021-01-01&resource=https://vault.azure.net

De IMDS is bereikbaar via een niet internet routeerbaar adres 169.254.169.254. Wellicht komt dit adres je bekend voor want de IPs uit de reeks 169.254.0.0/16 zijn ook wel bekend als een (Automatic Private IP Adressen (APIPA)!

De IMDS roept de MIRP aan die het Service Principal ID en certificaat teruggeeft aan de IMDS. Nu kan de IMDS Entra ID gebruiken voor de authenticatie en het verkrijgen van het Access Token. Het acces token blijft 1 uur geldig en wordt door SDKs automatisch vernieuwd.

Naast of in plaats van een SA MI, kun je ook een of meerder UA MI(s) aanmaken via de Azure Resource Manager en deze vervolgens zelf “koppelen” aan een Azure resource:

User assigned managed idenities maak en assign je aan een resource via de Azure portal of met IaC:

UA MIs hebben geen automatisch koppeling met een resource en life cycle management (LCM) van dit type managed identity staat dus los van LCM voor de resources waar de UA MI aan gekoppeld is.
De keuze voor het gebruiken van SA Mis of UA MIs is afhankelijk van je scenario, maar in het algemeen zijn SA MIs eenvoudiger in het gebruik.

Applicatie permissies voor Managed Identities

Entra ID gebruikt “App Roles” voor het toekennen van applicatie permissies aan een in Entra ID geregistreerde App. Deze applicatie permissies worden omgezet naar een “rol-claim” in een Entra ID OAuth access token. Zodra er consent permissies gegeven worden voor applicatie permissies van een App registratie, wordt in het Service Principal van de betreffende API registratie het “Users & groups” attribuut gevuld met het Service Principal van de App registratie.

Dit principe kan ook gebruikt worden voor managed identities. Het toekennen van het managed identity Service Principal aan de “Users en groups” van het Service Principal van een geregistreerde API kan echter niet via de portal maar wel met bijvoorbeeld Azure CLI of Microsoft Graph Explorer.

Wanneer je bijvoorbeeld een script maakt wat Microsoft Graph API applicatie permissies nodig heeft kun je, wanneer je dit script draait vanuit een Azure Resource, een managed identity gebruiken i.p.v. een App registratie met een secret of certificaat.

De App registratie voor de Microsoft Graph API staat in de Microsoft Tenant. In je eigen tenant staat het bijbehorende Service Principal (Enterprise Apps-Microsoft Applications) met client ID “00000003-0000-0000-c000-000000000000”. Microsoft gebruikt rollen, zoals bijvoorbeeld Application.Read.All, voor het toekennen van applicatie permissies.

Om een managed identity appicatie permissies te geven voor de Microsoft Graph API het je o.a. een application role identitier (appRoleID) nodig van de betreffende permissie. (Application.Read.All  in onderstaand voorbeeld.)  Dit ID kun je opvragen met:

az ad sp show --id 00000003-0000-0000-c000-000000000000 --query "appRoles[?value=='Application.Read.All']"

Verder heb je de resource identifier (resourceID) van het Microsoft Graph API Service Principal nodig. Dit is het objectID van het Microsoft Graph API Service Principal:

Tenslotte nog het principalID (=objectID) van het service principal van de managed identity:

Met deze parameters kun je de managed identity de rol “Application.Read.All” geven:

az rest --method POST --uri https://graph.microsoft.com/v1.0/servicePrincipals/22041010-8665-4b3c-bc7e-a61bac4d773a/appRoleAssignedTo --body '{"principalId": "277928e8-0061-4c59-a99c-c1501b41bdc5","resourceId": "22041010-8665-4b3c-bc7e-a61bac4d773a","appRoleId": "9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30"}'

Workload Identities met Federated Credentials

Managed Identities hebben als groot voordeel dat credentials (certificaten) automatisch beheerd worden maar kunnen alleen gebruikt worden binnen één tenant. Workload Identities met federated credentials daarentegen zijn bedoeld om toegang te krijgen tot resources vanuit externe OIDC compliant Identity Providers (IdPs), zoals bijvoorbeeld GitHub, Azure DevOps of Kubernetes, zonder daarvoor credentials te hoeven creëren of beheren.

In mijn blog over AKS Mastering Azure Kubernetes Services deel 4 Secure Identity & Access Management, ga ik uitgebreid in op hoe AKS pods een Entra ID access token kunnen verkrijgen door gebruik te maken van workload identities met federated credentials.

In de basis bestaat een workload identity met federated credentials uit een op OIDC gebaseerd id-token wat vertrouwd wordt door je tenant en ‘omgeruild’ wordt voor een OAuth access token.

Tegenwoordig ondersteunen service connecties in Azure DevOps ook workload identities met federated credentials. Deze kun je automatisch laten aanmaken in Azure DevOps, of zelf handmatig configuren met een UA MI of een App Registratie met gekoppeld Enterprise Application/Service Principal.

Wanneer je voor automatisch kiest wordt in je tenant een App Registratie en Enterprise Application/Service Principal aangemaakt met federated credentials geconfigureerd in de App Registratie.

De federated credentials bestaan uit de volgende OIDC Claims:

Issuer URL

Issuer URL: https://vstoken.dev.azure.com/40403ce8-3589-4b69-ba52-a09ba68cc55

De Issuer URL is geeft aant welke OIDC compliant IdP het id token voor de federated credential uitgeeft. Azure DevOps is hier de OIDC compliant IdP en bereikbaar via vstoken.dev.azure.com. Elke service connectie krijgt een unieke identifier wat samen de Issuer URL vormt.

Subject Identifier

Subject Identifier: sc://wjvpro/Project1/svccondevops1

De Subject Identifier is een unieke Identifier voor de geauthentiseerde entiteit binnen de IdP. Dit is vaak een unieke “guid” voor een gebruiker, maar in dit geval een unieke string voor de service connectie: sc://{name-ORG}{name-project}{name-serviceconnection}.

Audience

Audience: api://AzureADTokenExchange

De audience claim representeert voor wie het id token bestemt is. Dit is meestal de CLIENT-ID van de applicatie die het token aanvraagt. Bij federated credentials met Entra ID wordt dit altijd “api://AzureADTokenExchange“.

Dit is de “logische naam” van de Entra ID token exchange service, waarmee een extern OIDC-token wordt ingewisseld voor een access token wat vervolgens gebruikt kan worden voor toegang tot Azure-resources.

Wanneer een Azure Devops Pipeline toegang wil tot een Azure resource via een service connectie, geconfigureerd met een workload identitie met federated credentials, vraagt de pipeline bij de Azure DevOps token service om een OIDC id-token. Wanneer de service connectie permissies toestaan dat die betreffende pipeline gebruik mag maken van de service connectie, geeft de token service een id-token terug aan de pipeline.

Stap 1 in onderstaand figuur.

De pipeline stuurt het id-token naar Entra ID en vraag om een OAuth access token. Entra ID valideert het id token m.b.v. het OIDC “well-known endpoint”. Via dit endpoint krijgt Entra toegang tot de public key van de Azure DevOps OIDC compliant token service en kan de digitale handtekening waarmee het id-token “gesigned” is, valideren (stap 3).

Na validatie stuurt Entra ID het op het Service Principal gebaseerde acces token naar de pipeline (stap 4).

De pipeline gebruikt het access token voor toegang tot de Azure Resource, waar het Service Principal via Azure RBAC rechten heeft gekregen (stap 5).

Beheren en beveiligen van Workload Identities

Workload Identities, zeker managed Identities zijn snel gemaakt. In de Cloud bestaan meer workload identities dan human identities. Het beheren en beveiligen van workload identities laat bij veel organisaties echter nog te wensen over. Denk aan te veel rechten voor workload identities, secrets die niet op tijd vernieuwd worden of via scripts herleidbaar zijn, en bijvoorbeeld het niet opruimen van niet meer gebruikte workload identities. Toch is dit essentieel, zeker omdat steeds meer kwaadwillende zich richten op workload identities om toegang te krijgen tot kritische systemen en/of data.

Microsoft biedt een aantal mogelijkheden om workload identities te beschermen en beheren.

Conditional Access voor workload identities

Conditional Access policies (CAP) voor workload identities maakt het mogelijk om bijvoorbeeld service principals te blokkeren die van buiten een bekende publieke IP reeks komen of door Entra ID risk detection gemarkeerd zijn als risicovol.

Het gebruik maken van CAP voor workload identities vereist Workload Identitie Premium licenties. De policies kunnen toegekend worden aan service principals die via een ‘single tenant’ App registratie aangemaakt zijn. Multi tenant App registraties zijn out of scope. Ook managed identities zijn out of scope. Deze kunnen wel in Access Reviews meegenomen worden.

Voor meer informatie zie: Microsoft Entra Conditional Access for workload identities – Microsoft Entra ID.

Continuous access evaluation voor workload identities

Workload Identities maken gebuik van ‘kort’ levende access tokens voor toegang tot resources. Continuous Access Evaluation (CAE) zorgt ervoor dat tokens meteen ongeldig worden wanneer aan bepaalde voorwaarden niet meer wordt voldaan, ook als het token nog niet verlopen is. Bijvoorbeeld wanneer een service principal verwijderd of gedisabled wordt.

Voor meer informatie zie: Continuous access evaluation for workload identities in Microsoft Entra ID – Microsoft Entra ID.

Entra ID Protection

Entra ID protection kan behalve human identities ook service principals onderzoeken op verdachte login pogingen. Voor volledige risico rapportages en toegangscontroles zijn Workload Identities Premium licenties vereist. Entra ID Protection werkt voor single tenant, mulit tenant en op niet Microsoft SaaS gebaseerde service principals.

Voor meer informatie zie: Securing workload identities with Microsoft Entra ID Protection – Microsoft Entra ID Protection.

Access Reviews

Om te voorkomen dat service principals te veel rechten krijgen kunnen m.b.v. Privileged Identity Management (PIM) access reviews ingesteld worden. Een beheerder stelt voor een reviewer een acces review in die vervolgens beoordeelt of het betreffend service principal nog in gebruik is, nog van de juiste groepen lid is en/of nog de juiste rollen toebedeeld heeft gekregen.

Zorg bij het aanmaken van een App registratie altijd dat het owner attribuut gevuld wordt, zodat je altijd weet voor of door wie het gerelateerde service principal gemaakt is!

Voor meer informatie over access reviews zie: Create an access review of Azure resource and Microsoft Entra roles in PIM – Microsoft Entra ID Governance.

Custom Security attributen

Custom security attributen zijn een manier om extra informatie toe te voegen aan een (workload) identity. Denk bijvoorbeeld aan labels zoals:
– Environment = Production,
– Owner = TeamX
– ComplianceLevel = High
– DataSensitivity = Confidential

Deze attributen kunnen vervolgens gebruikt worden in Conditional Access policies, Access reviews, Governance / Life Cyle Management (LCM) en  atribute-based access control (ABAC).

Voor meer informatie zie: Overview custom security attributes.

Defender voor Cloud Apps

Microsoft Defender for Cloud Apps (voorheen Microsoft Cloud App Security, MCAS) is een cloud access security broker (CASB) van Microsoft. Het helpt organisaties bij het beveiligen van cloudgebruik door inzicht, controle en bescherming te bieden over gebruik van SaaS-apps, PaaS-diensten en cloudactiviteit, zowel voor gebruikers als workload identities. Defender for Cloud Apps kan bijvoorbeeld verdachte Service Principal activiteiten detecteren.

Voor meer informatie zie: Overview – Microsoft Defender for Cloud Apps.

📌 Conclusie

Entra ID kent verschillende soorten workload identities waarbij managed identities voor gebruik binnen een tenant en workload identities met federated credentials voor gebruik tussen verschillende IdPs de voorkeur geniet omdat voor deze type identities geen secret of certificaat beheer nodig is en daarmee ook veiliger zijn in gebruik (minder kans op leaked credentials).

Lifecycle management en beveiligen van alle type workload identities wordt van steeds groter belang in een wereld waar services meer en meer automatisch, zonder tussenkomst van gebruikers, met elkaar communiceren en aanvallers zich meer en meer richten op dit type identities.

➡️ Vervolg

Het volgende deel van deze blogserie gaat in op moderne authenticatie en autorisatie protocollen zoals OAuth en Open ID Connect (OIDC).