AKS-pods moeten bij Azure-resources, hoe regel je dat zonder secrets?
Workload Identity (sinds 2022 GA) is het juiste antwoord. Geen client-secrets in pods, geen pod-managed-identity-deprecation-pijn meer. Setup is een handvol stappen.
Probeer dit eerst zelf
- 1Maak je AKS-cluster aan met --enable-workload-identity en --enable-oidc-issuer (of upgrade een bestaand cluster met die flags).
- 2Maak een Managed Identity (User-assigned). Geef die de Azure-rollen die je pod nodig heeft (bijvoorbeeld Storage Blob Data Reader op een storage account).
- 3Maak een federated credential aan op die Managed Identity, met je cluster-OIDC-issuer en de namespace + service-account-naam.
- 4In je Kubernetes-namespace: maak een ServiceAccount met annotatie azure.workload.identity/client-id = <client-id-van-MI>.
- 5Patch je deployment met label azure.workload.identity/use: 'true' en gebruik die ServiceAccount. Pod krijgt automatisch een token, geen secret nodig.
Wanneer ons inschakelen
Heb je tientallen pods met verschillende rechten en gaat het door verschillende namespaces, dan is een Helm-template + naming-conventie meestal de moeite waard om eenmalig op te zetten.
Zie ook
- Iedereen logt in met het root-account van AWSHet root-account is voor noodgevallen en facturatie. Dagelijks werk hoort via IAM-users of SSO.
- Iedere developer heeft AdministratorAccessAdministratorAccess overal is gemak nu, drama later. Begin met rolgebaseerde policies.
- Iedereen heeft losse IAM-users met eigen wachtwoordIdentity Center (voorheen AWS SSO) koppelt aan je IdP en geeft tijdelijke credentials per sessie.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.