Azure-docs: Question: Documentation unclear about system MI vs user MI

[lgmorand]

" custom control plane identity enables access to be granted to the existing identity prior to cluster creation. This enables scenarios such as using an custom VNET or outboundType of UDR with a managed identity."

It does imply that these scenarios are impossible with a system-assigned MI. is it correct ? What is the difference between user MI and system MI in terms of scenarios or limitations ?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6a9c74a8-9f1a-3d3d-3aed-f8ec45f92e05
• Version Independent ID: 01e98043-dc80-490e-a761-8d558ff4e6df
• Content: Use managed identities in Azure Kubernetes Service - Azure Kubernetes Service
• Content Source: articles/aks/use-managed-identity.md
• Service: container-service
• GitHub Login: @mlearned
• Microsoft Alias: thomasge

[VikasPullagura-MSFT]

@lgmorand
Thanks for your Question! I have assigned the issue to content author to check and add comments to address your query.

[VikasPullagura-MSFT]

@TomGeske
Can you please check and add your comments on this as applicable.

[TomGeske]

System-assigned MI is being created during cluster create phase. For UDR you need to perform a role assignment ahead of cluster creation. That's why bring your own is needed.

For outboundType of UDR it will only work with bring your own identity. We are currently working on enabling it.

[SylvainVi]

This seems still unclear. Documentation states: "custom control plane identity enables access to be granted to the existing identity prior to cluster creation. This enables scenarios such as using an custom VNET or outboundType of UDR with a managed identity."

I do understand the statement concerning the UDR, but not for using a custom VNET. The statement suggests that only custom control plane can enable such a a scenario with a custom VNET.

Correct me if I'm wrong, but currently I am able to :

• create an AKS cluster (CNI) with system-assigned MI
• assign privileges (VNET contributor) to the system-assigned MI on the custom subnet where the AKS cluster is provisioned

using an custom VNET scenario can _also_ be enabled by using a system-assigned MI.
Or else are there differences / limitations between the 2 scenarios: system-assigned MI with custom VNET / user-assigned MI with custom VNET ?

[SylvainVi]

@TomGeske : do you any update / comment on my previous note ? Thank you in advance.

[TomGeske]

Sorry for my late response.

The scenario below works as long the user creating the cluster has permissions on the custom VNET to grant system-assigned MI permissions on that network. Othwerwise it will fail.

• create an AKS cluster (CNI) with system-assigned MI
• assign privileges (VNET contributor) to the system-assigned MI on the custom subnet where the AKS cluster is provisioned.

[SylvainVi]

Thank you @TomGeske

So we should understand that deploying an AKS cluster on a custom VNET scenario can be enabled:

• with a system-assigned MI => permissions can be set _during_ or _after_ AKS cluster creation
• with a user-assigned MI (BYO control plane MI) => permissions can be set _before_, _during_ or _after_ AKS cluster creation

=> this is a correct understanding ?

---

Is there any plan that needed permissions would be set automatically during the AKS cluster creation process, for a system-assigned MI ?

Here is a scenario:

• DevOps team is owner on its RG ; VNet resource is managed by another network team in another RG
• DevOps team want to use system-assigned MI along with cluster, so that there is no identity management on their side
• DevOps team want to be autonomous on the creation of a new AKS cluster
• Least-privilege is applied so that DevOps team only has the needed permission on the subnet where it deploys its AKS cluster

In this scenario, DevOps team is not owner on the subnet and cannot assign role => they must contact the network team to assign necessary privileges:

• Network team can be a bottleneck on such requests
• AKS cluster provisioning cannot be completed entirely with infra-as-code: if re-creation is needed the MI will change, and network team must be solicited again

Least-privilege permissions documented in https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni#prerequisites :

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

Thank you in advance for your feedback on such use case.

[TomGeske]

Let me try to clarify. If you are using MI either the MI needs to have all required permissions or the user creating the cluster has all required permissions. For the later AKS resource provider should grant needed permissions to MI on behalf of the user creating the cluster.

You should design your cluster creation phase to succeed in the first place. If you don't have all required permissions, it has a very high likely hood to fail.

What is the reason you can't use BYO MI for your described scenario? You need to grant access to the MI anyways, no?

[SylvainVi]

Thank you @TomGeske.

With the statement in the documentation I thought that the situation with a BYO MI would have allow to cover a use case that the system-assigned MI could not be able to cover.
But I understand that this is not the case and the situation remain the same, no matter the kind of MI: AKS cluster creation requires you to assign the appropriate role:

• either to your BYO MI beforehand
• either to your system-assigned MI druing or after (in az cli, you can sucessfully create the AKS cluster even if you are not the owner of the subnet ; a network team can then assign the role to the MI)

For my case, I would need to satisfy all the following requirements:

• enforce least-privilege principle => DevOps team must not be owner on its subnet (cannot change IP range, NSG association, UDR association) ; permission "subnets/join/action" is enough
• DevOps team need to be autonomous => DevOps team must not rely on an external process to proceed its AKS cluster creation ; "subnets/join/action" is enough to create AKS Cluster on the subnet
• DevOps team being able to create an AKS cluster with a MI that has least-privilege permissions on the target subnet => MI can have "subnets/join/action" permission on the subnet

My case could be satisfied with one of those options (as an example):
1- upon AKS cluster creation, the designated MI is automatically granted with the needed permissions on the subnet
2- the DevOps team could grant only needed permissions on the subnet, but no higher role

I understand that currently none of those option are possible.