AKS pods need to reach Azure resources, how do you do it without secrets?
Workload Identity (GA since 2022) is the right answer. No client secrets in pods, no pod-managed-identity deprecation pain. Setup is a handful of steps.
Try this first
- 1Create your AKS cluster with --enable-workload-identity and --enable-oidc-issuer (or upgrade an existing cluster with those flags).
- 2Create a Managed Identity (User-assigned). Grant it the Azure roles your pod needs (e.g. Storage Blob Data Reader on a storage account).
- 3Create a federated credential on that Managed Identity with your cluster's OIDC issuer and the namespace + service-account name.
- 4In your Kubernetes namespace: create a ServiceAccount with annotation azure.workload.identity/client-id = <client-id-of-MI>.
- 5Patch your deployment with label azure.workload.identity/use: 'true' and use that ServiceAccount. The pod automatically gets a token, no secret needed.
When to bring us in
If you have dozens of pods with different rights across namespaces, a Helm template plus naming convention is usually worth setting up once.
See also
- Everyone logs in with the AWS root accountRoot is for emergencies and billing. Day-to-day work belongs in IAM users or SSO.
- Every developer has AdministratorAccessAdministratorAccess everywhere is convenient now, painful later. Start with role-based policies.
- Everyone has individual IAM users with their own passwordIdentity Center (formerly AWS SSO) links to your IdP and issues temporary credentials per session.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.