I'm creating kubernetes service in Azure with Advanced Networking options where I've selected particular vNet and Subnet for it.
I'm getting error as below:
{"code":"InvalidTemplateDeployment","message":"The template deployment failed with error: 'Authorization failed for template resource '<vnetid>/<subnetid>/Microsoft.Authorization/xxx' of type 'Microsoft.Network/virtualNetworks/subnets/providers/roleAssignments'. The client '<emailid>' with object id 'xxx' does not have permission to perform action 'Microsoft.Authorization/roleAssignments/write' at scope '/subscriptions/<subid>/resourceGroups/<rgid>/providers/Microsoft.Network/virtualNetworks/<vnetid>/subnets/<subnetid>/providers/Microsoft.Authorization/roleAssignments/xxx'.'."}I've got contributor role.
There are two ways to fix the issue:
1.You just need to assign an Owner role to your account in the vnet scope.
Let your admin user(the account login the portal need the Owner role in the vnet), navigate to the vnet mentioned in the error in the portal -> Access control (IAM) -> Add -> Add role assignment -> add the account in the error as an Owner, for more details, see this link. After assigning your account to the vnet, you will be able to create the aks.
In this case, the custom role menioned by others is meaningless. Once the user gets the Microsoft.Authorization/roleAssignments/write permission, he can assign himself with any role he want, including the Owner role. So for security issues, it does not help.
2.If it is not allowed you to assign your account as Owner to the vnet in your case, here is a better way. You can let your admin user(the account has an Owner in the vnet) add the service principal which you configured in the Authentication step(not select the create new option) as a Network Contributor to the vnet, then when you create the aks, it also works with no error.
If you did not have a service principal, see this link to create it.
As per the following article, you will need Owner privileges over the vNet to change access to it.
the existing answer is not exactly true, you can get away with the Owner role, obviously, but you only need Microsoft.Authorization/roleAssignments/write over the scope of the subnet (might be vnet, didnt test this). which helps lock down security little bit. You'd need a custom role to do that. In case you dont want to go for the custom role, existing answer will be just fine.