Workload ID, Deel 1: Hoe Authenticeer Je Richting Azure Zonder Secrets?

Secrets in je Kubernetes setup kunnen soms aanvoelen als een noodzakelijk kwaad. Client secrets en certificaten die je constant moet roteren en veilig bewaren, credentials die kunnen lekken of in je Git-history kunnen belanden, … Het is niet alleen omslachtig en gevoelig, maar ook een serieus securityrisico. Gelukkig is er een alternatief voor AKS: Microsoft Entra Workload ID. Deze aanpak laat je AKS-applicaties veilig authenticeren bij Azure zonder langlevende secrets. Federated workloads bestaan trouwens ook voor andere providers, maar in deze blog focussen we op de Azure-oplossing. 

Aangezien er best wat over valt te vertellen, splitsen we deze blog op in twee delen. In dit eerste deel leggen we de basis uit: waarom traditionele secrets problematisch zijn en hoe het mechanisme achter Workload ID fundamenteel werkt. In deel 2 duiken we dieper in de praktische configuratie, best practices en de concrete voordelen.

Waarom zijn secrets geen goed idee (meer)? 

Vroeger waren er twee manieren om communicatie tussen Azure-componenten veilig te laten verlopen: client secrets of certificaten, beiden gekoppeld aan een Entra ID App Registration. Maar beide opties zorgen ook voor kopzorgen: 

• Zowel secrets als certificaten hebben een beperkte levensduur en moeten geregeld vervangen (geroteerd) worden. Dit is een manueel of complex geautomatiseerd proces, en wordt dus makkelijk vergeten. 
• Als een secret of certificaat lekt, heeft een aanvaller mogelijk toegang tot je Azure resources. Wie heeft de sleutel en wanneer is die voor het laatst vervangen? Het overzicht raak je in een ingewikkelde setup al snel zoek. 
• In een moderne GitOps-setup wil je je volledige clusterconfiguratie in Git beheren. Maar secrets of certificaten inchecken in Git is absoluut not done. Zodra het in de versiegeschiedenis zit, is het potentieel voor altijd gecompromitteerd. 

Een tijdlang was er nog een derde optie: AAD Pod Managed Identity. Die oplossing is inmiddels deprecated en wordt door Microsoft dan ook afgeraden voor nieuwe implementaties. Dus: de oude methodes zijn omslachtig, onveilig en passen niet goed in moderne development workflows. Wat werkt er dan wel? 

De oplossing: Workload ID uitgelegd 

Microsoft Entra Workload ID (vroeger gekend als Azure AD Workload ID) biedt een handige oplossing voor al die problemen. Het laat je AKS workloads authenticeren bij Azure resources zonder dat je zelf secrets of certificaten hoeft te beheren. 

Hoe? Door een vertrouwensrelatie op te bouwen tussen je AKS cluster en Microsoft Entra ID (vroeger gekend als Azure AD). Dit gebeurt via een standaardprotocol genaamd OpenID Connect (OIDC).  

Je kunt het zien als een soort digitale introductie: je AKS cluster heeft een ingebouwde uitgever voor een identiteitskaart (de OIDC Issuer). Je configureert Entra ID om deze uitgever te vertrouwen voor specifieke workloads. Als jouw workload zich dan aanmeldt bij Entra ID met een identiteitsbewijs (een token) van de AKS OIDC Issuer, doet Entra ID het volgende: 

• Het verifieert of de token wel effectief komt van wie het beweert.  
• Het vergelijkt de configuratie met wat er in de token zit. 
• Het geeft een toegangstoken aan de workload. 

Het resultaat: je applicatie krijgt toegang tot Azure resources waarvoor de gekoppelde identiteit gemachtigd is, zonder dat er ergens een secret opgeslagen of beheerd hoeft te worden. 

De “token dans”: hoe werkt het onder de motorkap? 

Het concept van een vertrouwensrelatie klinkt goed, maar hoe werkt dat nu precies technisch? Het is een slim samenspel tussen verschillende componenten, die voortdurend informatie uitwisselen. 

Azure	AKS
User Assigned Managed Identity (of App Registration)	OIDC issuer
Federated Credentials	Service Account
Entra ID	Kubelet & Workload ID Webhook

1. AKS OIDC Issuer 
   Je AKS cluster heeft (na activatie) een ingebouwde OpenID Connect (OIDC) issuer. Deze kan speciale, kortlevende tokens uitgeven voor service accounts binnen de cluster.
2. Kubernetes Service Account 
   Je pod draait onder een specifieke Kubernetes Service Account. Dit is de “identiteit” van je pod binnen de cluster.
3. User-Assigned Managed Identity or App Registration 
   In Azure maak je een User-Assigned Managed Identity aan. Dit wordt de “identiteit” van je workload in Azure. Je kan hier ook kiezen voor App Registration, aangezien dit ook federated credentials ondersteunt.
4. Federated Credential 
   This is the crucial link between AKS and Entra ID, where you define:
   1. De URL van de OIDC Issuer van jouw specifieke AKS cluster. 
   2. De namespace waarin de Kubernetes Service Account leeft. 
   3. De naam van het Kubernetes Service Account.
   4. Een subject identifier (meestal automatisch gegenereerd) die uniek is voor deze combinatie.
5. Kubelet & Service Account Token Volume Projection
   Wanneer je pod start (en het juiste label heeft), gebeurt het volgende:
   1. De Kubelet (de agent op elke AKS node) vraagt, met hulp van de Workload ID mutating webhook, een Service Account (SA) Token aan bij de AKS OIDC Issuer, specifiek voor de Service Account van de pod. 
   2. De Kubelet injecteert de token die hij kreeg van de OIDC issuer in de pod op een bepaalde, geconfigureerde plaats.
6. Entra ID verificatie
   Entra ID ontvangt de SA Token en controleert de volgende aspecten:
   1. Wie: voor wie (welke namespace en Service Account) is de token uitgegeven? 
   2. Wat: is de token wel geldig? Komt het ook effectief van diegene die beweert de token uitgegeven te hebben? 
   3. Wanneer: wanneer is de token gemaakt, en is het nog geldig? 
   4. Waar: waar komt de token vandaan? Met andere woorden: wie is de issuer?
7. Azure AD token uitgifte
   Als alles klopt, geeft Entra ID een standaard access token terug aan de workload, alsof de User-Assigned Managed Identity zelf heeft ingelogd. Vanaf de token wordt teruggegeven door Azure wordt die gecached door de applicatie
8. Automatische refresh
   De Kubelet houdt de vervaldatum van de Service Account token in de gaten en vraagt automatisch een nieuwe token aan bij de OIDC issuer. Dat gebeurt ruim voordat de huidige token verloopt; standaard na 80% van de geldigheidsduur.

Het mooie is dat jouw applicatiecode zich hier meestal niet bewust van hoeft te zijn. Als je de moderne Azure SDK’s gebruikt, detecteren die automatisch de aanwezigheid van het geprojecteerde token en gebruiken ze dit voor authenticatie. 

Bron afbeelding

What’s next? 

Workload ID biedt dus een elegante oplossing voor een complex probleem. Door een vertrouwensrelatie op te zetten tussen je AKS cluster en Entra ID, kun je veilig authenticeren zonder het gedoe en de risico’s van langlevende secrets. Het mechanisme van OIDC federation en token exchange zorgt voor een veilige en grotendeels automatische afhandeling achter de schermen. 

Nu je begrijpt wat Workload ID is en hoe het conceptueel werkt, ben je klaar voor de volgende stap. In deel 2 van deze blog duiken we in de praktijk: we overlopen de concrete configuratiestappen in Azure en Kubernetes en bespreken de belangrijke aandachtspunten en best practices.