Azure-docs: The service principal used for the AKS cluster must have Contributor permissions to the resource group containing the existing VNet.

[SamirFarhat]

Hi,
It's stated that the "The service principal used for the AKS cluster must have Contributor permissions to the resource group containing the existing VNet."
Is this still true ? What is this requirement ? What happens if i don't honor it ?

Thanks

---

Document Details

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

• ID: 22ad4873-c73d-4b90-2063-927a1060d2a2
• Version Independent ID: 8e6643ad-7333-a786-8712-3d17291e12a7
• Content: Network configuration in Azure Kubernetes Service (AKS)
• Content Source: articles/aks/networking-overview.md
• Service: container-service
• GitHub Login: @mmacy
• Microsoft Alias: marsma

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[mimckitt]

@SamirFarhat yes this is still true.

As per this doc: https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-service-principal

This without contributor access the cluster would not function properly.

[SamirFarhat]

Based on your answer, the SPN needs contributor permissions on the RG which the LB and the Route Table is belong to, and not the VNET. This is totally different. I think that to be more clear, you need to mention it this way. We have scenarios where the LB and the Route Table are within different RG than the VNET.

[mimckitt]

@SamirFarhat I will assign to the content author to review and see if we can make it more clear.

@mmacy can you take a look to see if we can add anything?

[mmacy]

@SamirFarhat The statement within this article is still true. The article that @MicahMcKittrick-MSFT had linked is for Azure Container Service (ACS) clusters and the required SPN permission for general cluster operations. This article is in relation to Azure Kubernetes Service (AKS), and the line in question is in relation to the permissions required for AKS to manage resources within the VNet.

[SamirFarhat]

Hi,
What resources for exemple? The only resources involved in AKS theorically are Subnets. What type of operations please, this is a big concern as this is a security concern in Shared environments.
Thanks

[mmacy]

Hi @SamirFarhat,

As @sauryadas mentions in AKS issue #444, Contributor permission is required to "create resources like LB's, IP addresses, and NSG's in the VNET required for publicly accessible apps deployed in the cluster." You might also find the comment by @noelbundick in that same issue valuable for further limiting the scope of access to Network Contributor in some environments.

[SamirFarhat]

We don't require contributor role on the RG where the VNET is located, we need contributor role on the RG wher the LB and other resources are created. My requirement is in the Bring Youn VNET scenario

[noelbundick]

To add some detail here - the k8s azure cloud provider interacts with all of the things mentioned here

When new nodes are brought online, it needs the “join subnets” permission on the subnet the cluster is assigned to in order to add VMs (and Load Balancers, etc) to the subnet. It also seems to need “edit subnet” to assign an NSG to that subnet. This is why the docs call out adding permissions to the VNET RG. In my opinion we recommend too broad permissions, but I haven’t fully tested if Network Contributor (or a more limited custom role) is sufficient.

At runtime, as services are modified, LB’s can be created/modified - so the SP also needs Contributor permissions to the cluster resource group (MC_*) to modify those LB’s, Route Tables, NSG’s, etc. AKS takes care of this one for you - this is the “RG which the LB and the Route Table is belong to”

[SamirFarhat]

Allow me some time before closing this ticket. I will test my scenario and update here (2 days).

[mmacy]

Hello @SamirFarhat, do you have an update on your testing?

The article correctly advises "Contributor" permissions on the VNet RG to handle all configurations. Within your environment and use case, you might be able to configure stricter permissions as @noelbundick mentions. However, for now, we're going to leave the current "Contributor" guidance in the article to ensure compatibility, and I'll request this issue be closed.

For feedback regarding your permissions concerns, please feel free to add your comments to AKS issue 444: Contributor permissions for cluster service principal on resource group containing VNet overly broad.

please-close

[mmacy]

Hi @SamirFarhat, new details are now available on the required permissions for AKS+VNet. We've just updated the article with the following:

• The service principal used by the AKS cluster must have at least Network Contributor permissions on the subnet within your VNet. If you wish to define a custom role instead of using the built-in Network Contributor role, the following permissions are required:
  
  
  
  • Microsoft.Network/virtualNetworks/subnets/join/action
  
  
  • Microsoft.Network/virtualNetworks/subnets/read
  
  

[SamirFarhat]

That makes sense, the AKS spn needs the ability to join the nodes to the subnet, so it needs read and join permissions on the Subnet Resource itself. Thanks guys