Azure Kubernets Service: Regular user with RBAC enabled cluster has system:masters role

609 views Asked by At

I have set up a AKS cluster from portal. With Kubernets RBAC enabled but no integration with AAD. enter image description here

When i am logged in with my user(which is also cluster admin) and perform az aks get-credentials --name <cluster-name> --resource-group <resource-group> Context is added to ./kube/config file and from there i copied the client-certificate-data field, decoded it and found out that CN = masterclient O = system:masters is what my certificate has. In AKS there is an existing ClusterRoleBinding which allows the access to all the cluster for the users with group system:masters.

Now i added a ServicePrincipal and assigned it below roles only on the AKS cluster.

enter image description here

Now when i do az login --service-principal --username <sp_name> --password <pwd> --tenant <tenant_id> and

 az aks get-credentials --name <cluster-name> --resource-group <resource-group>

I figured out that same system:masters is being set as the group in the client-certificate-data and having full access to the cluster.

Is this behavior correct? Shouldn't it be like that CN and Group in certificate data be different to master and we would then need additional Role/ClusterRole Bindings to manage them?.

1

There are 1 answers

0
GPuri On

I guess if "Local accounts with Kubernetes RBAC" option is enabled both roles "Azure Kubernetes Service Cluster User Role" or "Azure Kubernetes Service Cluster Admin Role" behaves the same. If we do az aks get-credentials we will get same certificate for both the roles as also mentioned in a note in below article. We need to have AKS integrated with Azure AD to have the specific behavior i was expecting.

https://learn.microsoft.com/en-us/azure/aks/control-kubeconfig-access

Edit: 1 Jan 2023

Even with local accounts RBAC could be performed for individual users. We need to make sure every user/group is given separate certificates and corresponding Role/RoleBindings need to be created in kubernetes cluster. For certificate automation please refer

https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/

P.S:- CN in the certificate is the corresponding User subject in RoleBinding, while O in the certificate represents the group in role binding.