Workload ID (Deel 2): Configuratie & Best Practices

In deel 1 van deze blog hebben we uitgelegd waarom traditionele methodes met secrets of certificaten voor authenticatie van AKS naar Azure problematisch zijn. We introduceerden Microsoft Entra Workload ID als de moderne, secretless oplossing en gaven een kijkje onder de motorkap van het proces via OIDC federation en token exchange.

Nu de basis duidelijk is, is het tijd voor de praktijk. In dit tweede deel duiken we in de concrete configuratiestappen, de valkuilen waar je zeker op moet letten, en de best practices. Laten we aan de slag gaan!

Hoe zet je Workload ID op?

Als je Workload ID wil opzetten, moet je zowel in Azure als Kubernetes configureren. Dit zijn de zes stappen.

1. Activeer de OIDC Issuer op AKS

Controleer eerst of de OIDC issuer feature al ingeschakeld is op je AKS cluster. Dit is een vereiste, dus sla het zeker niet over!

Er zijn twee opties: ofwel tijdens het aanmaken van je cluster (met –enable-oidc-issuer) of achteraf via een update commando:

az aks update --resource-group <your-resource-group> --name <your-aks-cluster-name> --enable-oidc-issuer

Vervolgens haal je de unieke OIDC issuer URL van je cluster op. Die zullen we later in stap 3 gebruiken.

az aks show --resource-group <your-resource-group> --name <your-aks-cluster-name> --query "oidcIssuerProfile.issuerUrl" -o tsv

2. Maak een User-Assigned Managed Identity aan (Azure)

Creëer een User-Assigned Managed Identity (UAMI) in Azure. Dit kan op 3 mogelijke manieren:

Via de Azure portal
Via de Azure CLI
Via een Infrastructure as Code (IaC) tool naar keuze (bv. Bicep of Terraform)

Noteer zeker ook de Client ID (ook wel Application ID genoemd) en de Tenant ID van deze nieuwe Managed Identity.

P.S. Zoals we in de eerste blog al aanhaalden kan je ook kiezen voor App Registration, maar wij raden doorgaans een User Assigned Managed Identity aan.

3. Maak een Kubernetes Service Account aan

Nadat we de federated credential opgesteld hebben, moeten we een Service Account opzetten in onze Kubernetes configuratie (YAML-file).

Concreet is het de bedoeling dat we de azure.workload.identity/client-id annotatie toevoegen aan de metadata, met de Client ID van je User-Assigned Managed Identity die we in stap 2 gemaakt hebben. Dit zal de Kubernetes Service Account linken aan de Azure identiteit.

apiVersion: v1 
kind: ServiceAccount 
metadata: 
  name: <your-service-account-name> # Must match step 3 
  namespace: <your-namespace> # Must match step 3 
  annotations: 
    azure.workload.identity/client-id: "<client-id-of-managed-identity>" 
    # Optional: azure.workload.identity/tenant-id: "<your-tenant-id>"

4. Configureer de Federated Credential (Azure)

In deze stap leg je de vertrouwensrelatie vast die alles doet werken. Dat doe je als volgt:

Open de Azure Portal (of gebruik IaC!) en ga naar de User-Assigned Managed Identity die je net hebt aangemaakt.
Navigeer naar ‘federated credentials’.
Klik op ‘add credential’ en kies het scenario ‘Kubernetes accessing Azure resources’.
Vul de volgende details in:
1. Cluster Issuer URL: De OIDC issuer URL van je AKS cluster (uit stap 1).
2. Namespace: De Kubernetes namespace waarin je Service Account (zie stap 4) zal draaien.
3. Service Account name: De naam die je aan je Kubernetes Service Account zal geven.
4. Audience: Laat deze meestal op de default waarde: api://AzureADTokenExchange
5. Credential name: Geef de credential een duidelijke, beschrijvende naam.
Save the credential.

5. Configureer je pod of deployment

In de YAML-file van je deployment of pod moeten we nog twee zaken instellen. Ten eerste moeten we verwijzen naar de Service Account die we in de vorige stap gemaakt hebben via spec.serviceAccountName: <jouw-service-account-naam>.

Ten tweede moeten we het azure.workload.identity/use: “true” label toevoegen aan de spec.template.metadata.labels (voor een deployment) of metadata.labels (voor een pod). Dit label zal de Workload ID webhook voor deze pod activeren.

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: my-application 
  namespace: <your-namespace> 
spec: 
  # ... replicas, selector ... 
  template: 
    metadata: 
      labels: 
        # ... other labels ... 
        azure.workload.identity/use: "true" # <-- ESSENTIAL LABEL 
    spec: 
      serviceAccountName: <your-service-account-name> # <-- Link to SA 
      containers: 
      # ... container definition ...

6. Stel de Azure permissies in

Last but not least moeten we natuurlijk nog de nodige permissies toekennen in Azure. Geef de User-Assigned Managed Identity uit stap 2 de juiste Azure RBAC-rollen op de resources waartoe je applicatie toegang moet hebben. Zo kan je bijvoorbeeld kiezen voor ‘Key Vault Secrets User’, ‘Storage Blob Data Reader’, of een andere rol die je hebt ingesteld.

Hier kunnen we alvast een best practice meegeven: ken dezelfde rollen ook toe aan de specifieke resources die je gebruikt, niet enkel op een volledige subscriptie.

Code & SDK‘s: wat moet je nog aanpassen?

Het goede nieuws is dat je applicatiecode vaak geen aanpassingen nodig heeft om met Workload ID te werken. Als je recente versies van de Azure Identity SDK’s gebruikt, zullen die automatisch detecteren dat ze binnen een AKS pod draaien met een Workload ID configuratie. Ze vinden het geïnjecteerde token en gebruiken het voor authenticatie.

Zorg wel dat je minimaal de volgende SDK-versies gebruikt:

Ecosystem	Library	Minimumversie
.NET	Azure.Identity	1.9.0
C++	azure-identity-cpp	1.6.0
Go	azidentity	1.3.0
Java	azure-identity	1.9.0
Node.js	@azure/identity	3.2.0
Python	azure-identity	1.13.0

Bron

Pitfalls en best practices

Workload ID maakt authenticatie een stuk eenvoudiger dan de oude methodes, maar (zoals bij elke technologie) zijn er wel een paar punten waar je extra op moet letten tijdens de implementatie.

Pitfall: Kubernetes configuratie

Het correct instellen van de azure.workload.identity/client-id annotatie op de Service Account en het azure.workload.identity/use: “true” label op de Pod-template is absoluut cruciaal. Vergeet je ze of configureer je ze verkeerd, dan zal de token exchange simpelweg niet werken. Controleer deze instellingen dus altijd!

Best practice: vergeet pods niet te herstarten

Als je de annotaties op een bestaande Service Account aanpast (bijvoorbeeld om naar een andere Managed Identity te linken), zullen de pods die deze Service Account gebruiken een herstart nodig hebben. Pas dan pikken ze de nieuwe configuratie op en kunnen ze de juiste Entra ID tokens verkrijgen.

Best practice: granulariteit

Volg altijd het least privilege principe: geef een workload alleen de rechten die strikt noodzakelijk zijn. Idealiter heb je een aparte User-Assigned Managed Identity (met bijbehorende Federated Credential en Service Account) voor elke applicatie of component die unieke permissies nodig heeft. Dit zorgt voor een duidelijke scheiding en minimaliseert de impact als een identiteit ooit gecompromitteerd zou raken.

Bundel workloads enkel onder dezelfde Managed Identity (een zogenaamde ‘many-to-one’ configuratie) als ze exact dezelfde set Azure-rechten delen. Denk bijvoorbeeld aan meerdere monitoring componenten die allemaal dezelfde toegang tot een Storage Account nodig hebben.

De limiet van maximaal 20 federated credentials per User-Assigned Managed Identity ondersteunt de granulaire aanpak. Het dwingt je bijna om na te denken over het opsplitsen van identities per workload of functioneel domein, wat de veiligheid ten goede komt.

Pitfall: regional support

Workload ID is breed beschikbaar in vrijwel alle Azure regio’s, inclusief West-Europa en Noord-Europa. Check voor de zekerheid de officiële Microsoft documentatie voor de meest actuele (zeer korte) lijst van uitzonderingen, maar de kans is klein dat je hierdoor beperkt wordt.

Tijd om over te stappen!

Zoals je merkt vraagt het configureren van Workload ID aandacht voor de details, zowel in Azure als Kubernetes. Maar: van zodra het er staat, pluk je de vruchten van een significant veiligere, eenvoudigere en modernere manier van authenticeren. Geen secret-stress meer, betere controle en een setup die perfect past in je GitOps workflow.

Wat ons betreft is Workload ID dus dé manier om veilige communicatie tussen AKS en Azure op te zetten. Daarom hebben we het ook deel gemaakt van onze AKS Baseline!

Kan je wat hulp gebruiken bij het implementeren van Workload ID in jouw AKS-omgeving, of wil je meer weten over onze AKS Baseline? Neem gerust contact met ons op, we helpen je graag verder op jouw cloud journey.

Workload ID, Deel 2: Praktische Configuratie & Best Practices