Built-in roles for Azure Kubernetes Service, AKS

Question

Hi.. I'm having a hard time figuring out the differences in below lot of built-in roles. I have a RBAC enabled AKS cluster. I want to deploy from Github Actions. I have created a Service Principal which I want to have a role to be able to deploy in the cluster. But what ever role I give the SP, it fails because it needs Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action. The only role that have that action is Azure Kubernetes Service Cluster Admin Role, so what is the point with the other roles if you always need the Cluster Admin role ? What is the difference between the first 3 roles and the last RBACroles ?

Answer 1

@Patrick Kerwood Apologies for the delay in response and all the inconvenience caused because of the issue.

RBAC role give you the granular control as an admin. to control who user should be having what access to resources. Role-based access control covers among others role permissions, user roles, and can be used to address multiple needs of organizations, from security and compliance, over efficiency and cost control.

RBAC lets employees have access rights only to the information they need to do their jobs and prevents them from accessing information that doesn't pertain to them.

Let us take a simple example you have a user who you need to just give read access because of security reason or any other reason as well. Now you have a scenario where you only need user to see logs or any particular information so you will give Writer Role so that they can only view the data and can't make any changes to same. This is ideal scenario where user need to have limited access and it will be targeted to only that particular resource.

Again now if you want user to have access to resource and apart from read and write then you give them contributor access over the resource. Having this role also mean that user access will be limited to that resource itself and even though have a capability to make changes they don't have capability to create a new resource on same.

Now comes AKS Cluster User Role It only has limited permission to get cluster user credential of the managed cluster with a specified resource group and name.

Now AKS Admin role can be said to have combination of all these role. It has all the permission over AKS resource and it can read, write, make changes and can assign new user to the cluster and provide them necessary permissions. This way you operate in a secure manner and you only give access to user to what component it is intended to.

You can refer to this article to understand RBAC in general and the roles associated with same.

Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action is used when you do az aks get-credentials --admin

If you indeed want to use cluster admin credential, instead of using SP's credential, to access api-server, you will need to assign "Azure Kubernetes Service Cluster Admin Role".

Though, based on the description, you want to use SP and Azure RBAC instead.
In that case, you will assign "Azure Kubernetes Service RBAC Cluster Admin" to SP and use az aks get-credentials to download kubeconfig. For SP to talk to api-server (non-interactive AAD login), they will need to use https://github.com/Azure/kubelogin

Hope it helps!!!

Please "Accept as Answer" if it helped so it can help other in community looking for help on similar topic.