Azure / Azure/azure-workload-identity
Documentation steps just don't work
- Dominant language
- Go
- Stars
- 337
- Forks
- 122
- Avg merge
- 1h 7m
- Merged PRs (30d)
- 3
Description
I've tried this a few different ways and either the documentation has been wrong or things have now changed in the project or when I went right back to basics and just used the az commands to create a cluster and configure workload identity from scratch it still doesn't work either at all or in the way it's described.
Has anyone actually followed the steps described here and got a working cluster with workload identity? https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster
My observerations following the steps documented in the above link...
All was fine until the key vault section, where you just make an assumption there is a keyvault. https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster#create-a-managed-identity-and-grant-permissions-to-access-azure-key-vault
It's only really one command so why not just detail how to create a keyvault if you don't already have one, which as this is a new stack, lets assume you don't. Secondly the commands are all for when you don't have an RBAC enabled keyvault and in fact there is no detail about RBAC, but surely the whole point of using the managed identities is that you will be using roles to grant permissions. The commands all detailed are then about set-policy which obviously doesn't work with an RBAC enabled keyvault. I configured the appropriate role assignments instead at this point.
Next you get on to creating a kubernetes service account, not a massive problem but you always reference kubetctl commands in bash with no powershell alternatives, which is fine but do windows users not get considered (much like the azwi cli installation having only details to brew install on osx).
So I created the service account and federated identity credential and I deployed an application using the latest AzureIdentity package. It would be nice if you at least gave an example here like some hello world app or the azurecli or something.
First note, which differed from my original terraform attempt of configuring this, we obviously have no instruction of installing the helm 3 chart for the workload identity webhook, I assume this is done for us with the --enable-workload-identity flag on the cluster?
Secondly the pods for the webhook in the kube-system namespace were called azure-wi-webhook-controller when using the helm command in my original attempt. However following this document they are called wi-webhook-controller, but all the other references I see in documentation refer to azure-wi-webhook-controller. On an intermediate attempt (I've trashed my cluster a fair few times to check things), I ended up with both azure-wi-webhook-controller pods and wi-webhook-controller pods.
The other documentation you have starting here: https://azure.github.io/azure-workload-identity/docs/installation/managed-clusters.html#azure-kubernetes-service-aks
Sends you to this link to create a cluster with oidc enabled: https://learn.microsoft.com/en-us/azure/aks/cluster-configuration#oidc-issuer In that link there is absolutely no mention of OIDC at all.
So you obviously go to the first document I read from, and then move on to mutating the webhook, which there is no mention of in the first set of instructions I refered to. This tells you to run the helm install steps: https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html#helm-3-recommended
If you do that after creating a cluster with --enable-oidc-issuer and --enable-workload-identity you endup with both the azure-wi-webhook-controller pods and wi-webhook-controller pods.
So I'll jump back to the end of the first document now where we are just told to deploy our application, as mentioned I deployed a simple web-api that using an AzureDefaultCredential. I tried it first without specifying a ManagedIdentityClientId, and acutally for the first time in the 3 days I've been trying to get this to work I got a token back....
Previous attempts without a ManagedIdentityClientId defined in the DefaultAzureCredential complained about multiple identities being found.
So I inspected the token, and despite creating a service account and federated identity as per the steps in the original document, this is in fact using the nodepool identity.
I then specified the id of my service account (which is also referenced in the manifest for my pod as per the documentation) and got back to an error I'd seen in a previous attempt:
Azure.Identity.CredentialUnavailableException: ManagedIdentityCredential authentication unavailable. The requested identity has not been assigned to this resource.
As mentioned my last attempt followed the documentation here: https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster with the only change being that I created an RBAC enabled cluster and did a role assignment as opposed to an access policy.
Any direction on how I could get this working would be fantastic and I'd also encourage whoever is documenting this to either try to follow the steps by the letter themselves or get someone else to try to follow the steps and see if you get a working cluster with workload identity working. I'm more than happy to give feedback on a set of instructions that should give the intended result if someone can provide them.
Finally conepts https://azure.github.io/azure-workload-identity/docs/concepts.html this is how I envisioned it to work, however as detailed above when I follow the steps, it uses the nodepool identity not the service account we created.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the workload-identity-deploy-cluster guide alongside the linked managed-cluster and mutating-admission-webhook pages. Reproduce the documented AKS flags, Key Vault permissions, webhook installation, and application deployment, including the reported duplicate webhook names and nodepool identity behavior. Done means a single tested path with prerequisites, platform alternatives, and expected identity behavior documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, helm, kubernetes
- Domain
- authentication, cloud, devops, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100