I've just setup a Managed Identity in my AKS cluster to authenticate with an Azure Key Vault resource, using the following guide:

Any clarification would be super helpful - thanks,

CodePudding user response：

When you are creating a AKS Cluster ,it creates a kubelet_identity by default evenif you have not specified anything. Kubelet identity is a User-Assigned Identity. If you go to the VMSS >> Identity , You will see two tabs System-Assigned and User-Assigned , the System-Assigned is by default No but in User defined you will find the aks-agentpool assigned to it . So , Even if you don't assign System-Identity , You can assign contributor roles to the Agentpool managed identity.

Example:

I created a AKS Cluster using the Command az aks create -g ansumantest -n MyAKSansuman --location uksouth --generate-ssh-keys.

If I go to MC_ resource group which is the node resource group , I see the Managed Identity present there:

In Identity Blade of VMSS , you can see as below the System-assigned Identity is not present but User-assigned Identity is present:

Now if I want to add a access policy for the AKS in Keyvault then I can refer to the Managed-Identity:

Generally using the above only you can assign Access Policy for key vault or any RBAC Role required by AKS to access other Azure services. As that is being used by AKS by default.

CodePudding user response：

When you do that assignment of your VMSS, under the covers it is assigning the role to the system assigned managed identity. The "MyAKS agentpool" is a different managed identity from the one you created.

We are dealing with multiple identity concepts, and unfortunately all of them are not super clear. (you can read through a few articles that shed some light: https://docs.microsoft.com/en-us/azure/aks/concepts-identity, https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)

Let's walk through a few basics, so the answer makes more sense:

#1: when you created your AKS cluster, a system-assigned managed identity was created for you. The cluster uses this to authenticate and do actions it needs to do (such as manage VMs)

#2: when AKS created the VMSS, it created a "user-assigned managed identity" which shows up in the "MyAKS-agentpool" in your portal. This is the identity that is deployed on the VMSS for the kubelet to authenticate in the context of that VMSS. Depending on what you are trying to do, you could potentially use it for your purpose, instead of creating a system-assigned managed identity.

#3: when you used a "system-assigned managed identity" on your VMSS, it caused a system-assigned managed identity to be deployed on all those VMs. The notion of a system-assigned managed identity is that it is part of the original azure resource itself: it does not show up as another entity. So when you are giving a role to something, you are picking the VMSS (even though under the covers the access gets granted to the system-assigned managed identity). You will not find this as a separate "managed identity" in the portals.

So hope that answers why you had to grant the role to the VMSS and not the managed identity you see in the portal.

Having said all of this: I generally think it's a bad idea to do this kind of assignment: since the system assigned identity is available to every pod running on the node irrespective of the namespace. And you probably need a better finer granularity than that, in which case a better route is to use the https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity