Azure

RBAC in AKS – This vs That

Yash kamdarLeave a comment

Over a cup of coffee at City Centre, Deira , I was brainstorming with one of my colleagues on the most viable option to go ahead with for configuring access on AKS cluster. We had a really interesting discussion and that’s when I thought that this topic deserves a blog post.

There are 3 options that are available for configuring authentication and authorization in AKS –

  1. Local accounts with Kubernetes RBAC
  2. Azure AD authentication with Kubernetes RBAC
  3. Azure AD authentication with Azure RBAC

For those of you who are new to AKS, the official in-depth documentation for access configuration that explains all these three methods will get easier to digest if you go through this blog post.

Local accounts with Kubernetes RBAC

If Azure Active Directory integration is not enabled then by default AKS uses local accounts for authentication.

You have to then rely on client certificates (based on x509 certificates), bearer tokens, OpenID Connect tokens, Service account tokens, Bootstrap tokens etc. This is covered in detail here

User management becomes a bit difficult while using this option because it becomes difficult to differentiate between the user access.

Choose this option only if Azure AD integration is not possible or if you do not want your cluster users to be a part of Azure AD.

Azure AD authentication with Kubernetes RBAC

You will need Azure Active Directory integration enabled to access this option.

With this option, the authentication to AKS is delegated by Azure AD whereas authorization needs to be defined within the yaml manifests i.e. RoleBinding

With this option, user management becomes a bit organized because it allows you to define what role you are configuring for a user or a group of users with respect to authorization.

Lets try to understand this with the help of a scenario.

Suppose you are designing an AKS cluster based on user roles where you want –

  • Solution architect to be a cluster-admin
    • Allows super-user access to perform any action on all resources in every namespace
  • Developers to have an edit access
    • Read/write access to most resources in that namespace but no permission to create rolebindings
  • Operations engineers to have a view access
    • Read only access to most resources in that namespace but no permission to create rolebindings and access secrets

Here is what your RoleBinding YAML file would look like for your solution architect’s (cluster-admins) –

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-admin-role-binding
  namespace: TechCOE
subjects:
  - kind: Group (This can be a group of a user)
    name: <Azure AD group ID (guid)>
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin 
  apiGroup: rbac.authorization.k8s.io

Here is what your RoleBinding YAML file would look like for your developers (edit)-

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit-role-binding
  namespace: TechCOE
subjects:
  - kind: Group (This can be a group of a user)
    name: <Azure AD group ID (guid)>
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Here is what your RoleBinding YAML file would look like for your operations team (view)-

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view-role-binding
  namespace: TechCOE
subjects:
  - kind: Group
    name: <Azure AD group ID (guid)>
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

From the above 3 examples it becomes clear as to how Azure AD authentication with Kubernetes RBAC helps you organize your access delegation and authorization management.

One problem with this approach however is that while checking access or while delegating access via yaml you have to specify the guid of the Azure AD group and not the name.

Choose this option if you want authentication to be decided by Azure but authorization of resources within the cluster to be decided by Rolebindings within K8’s.

Azure AD authentication with Azure RBAC

You will need Azure Active Directory integration enabled to access this option.

With this option, the authentication as well as authorization to AKS is delegated by Azure AD.

In simple words you can manage the entire access delegation within azure and there is not need to configure anything within K8’s.

There are 4 built in roles defined in Azure that match the permission levels made available by K8’s which you can use for authorization

Azure Built-In RolesKubernetes Cluster Roles
Azure Kubernetes Service RBAC Cluster AdminCluster-Admin
Azure Kubernetes Service RBAC AdminAdmin
Azure Kubernetes Service RBAC WriterEdit
Azure Kubernetes Service RBAC ReaderView

This needs to be configured using Azure CLI. An example is as shown below –

az role assignment create --role "Azure Kubernetes Service RBAC Writer" --assignee <<group id for developers>> --scope /subscriptions/<<subscription>>/resourcegroups/<<rg>>/providers/Microsoft.ContainerService/<<cluster-name>>/namespaces/TechCoE

That’s it, hope this blog post sets the context for you and you can now sit and analyze which option suits your AKS cluster the most.

Leave a comment