How to list Azure RBAC Roles to Secure AKS Clusters

When working on a managed Kubernetes cluster, such as on cloud platforms, securing access to it becomes a very critical aspect. You would not want your cluster to be accessed by anyone having access to the cloud platform. To secure this access to your cluster, we have the concept of Role-based access control (RBAC).

In the cloud ecosystem, Azure is one of the leading cloud provider in the world. Azure provides a managed Kubernetes service named as Azure Kubernetes Service (AKS). What you get in a managed Kubernetes cluster is a managed controlplane where you do not need to worry about managing your kube-apiserver, etcd, kube control manager, scheduler, etc. All this is managed by Azure free of cost. You just need to pay for the nodes (underlying VMs) that you are going to use to run your pods.

Azure provides an awesome and easy way of implementing RBAC to your managed Kubernetes clusters. To implement, you can use your existing knowledge of Azure RBAC that you apply on various Azure resources and experience the same for Azure Kubernetes cluster security.

RBAC experience on Azure is all about permissions that are given to the roles. And to grant a security principal access, you need to create role assignment.

To view the list of various Azure RBAC roles available for Azure Kubernetes Service, run the following Azure Cli command.

$ az role definition list \
	--query "[?contains(roleName, 'Azure Kubernetes Service RBAC')].{roleName:roleName,description:description}"

This will output:

[
  {
    "description": "Lets you manage all resources in the cluster.",
    "roleName": "Azure Kubernetes Service RBAC Cluster Admin"
  },
  {
    "description": "Lets you manage all resources under cluster/namespace, except update or delete resource quotas and namespaces.",
    "roleName": "Azure Kubernetes Service RBAC Admin"
  },
  {
    "description": "Allows read-only access to see most objects in a namespace. It does not allow viewing roles or role bindings. This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation). Applying this role at cluster scope will give access across all namespaces.",
    "roleName": "Azure Kubernetes Service RBAC Reader"
  },
  {
    "description": "Allows read/write access to most objects in a namespace.This role does not allow viewing or modifying roles or role bindings. However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace. Applying this role at cluster scope will give access across all namespaces.",
    "roleName": "Azure Kubernetes Service RBAC Writer"
  }
]

To drill down and see the specific permissions assigned in the role run the following command.

$ az role definition list --role-name "Azure Kubernetes Service RBAC Cluster Admin"

which would output the permissions as:

[
    ...
    "permissions": [
      {
        "actions": [
          "Microsoft.Authorization/*/read",
          "Microsoft.Insights/alertRules/*",
          "Microsoft.Resources/deployments/write",
          "Microsoft.Resources/subscriptions/operationresults/read",
          "Microsoft.Resources/subscriptions/read",
          "Microsoft.Resources/subscriptions/resourceGroups/read",
          "Microsoft.Support/*",
          "Microsoft.ContainerService/managedClusters/listClusterUserCredential/action"
        ],
        "dataActions": [
          "Microsoft.ContainerService/managedClusters/*"
        ],
        "notActions": [],
        "notDataActions": []
      }
    ],
    "roleName": "Azure Kubernetes Service RBAC Cluster Admin",
    "roleType": "BuiltInRole",
    "type": "Microsoft.Authorization/roleDefinitions"
  }
]

You can also work on RBAC from Azure Portal:

I hope you find this helpful and this makes your Kubernetes security journey a step easier.