Securing Your Azure Kubernetes Services Cluster

In this article, I will present my perspective on securing an Azure Kubernetes cluster with the principle of least privilege as a top priority. I will explain the available built-in Azure Kubernetes Roles, the function of the Microsoft Entra (formerly Azure Active Directory) groups, and how to utilize Kubernetes RBAC to manage access to the workloads.

Photo by "ArminH" on Freeimages.com

Authentication and Authorization

Configure the cluster to integrate with Microsoft Entra and take advantage of managing users and groups from central identity management.

Microsoft Entra Groups and Azure Kubernetes Roles

Create one or more Entra Groups to separate the administrators from the non-administrators. The number and structure of groups will depend on your structure. Let's assume we created two groups:

• admin
• developers

Now, we need to assign roles to these groups. There are two Azure Kubernetes Roles I use are as follows:

1. Role: Azure Kubernetes Service Cluster User Role

• Description: This role allows the user to log into the cluster; however if no (Cluster)RoleBidings exists, the user cannot execute any kubectl command.

2. Role: Azure Kubernetes Service RBAC Cluster Admin

• Description: Allows super-user access to perform any action on any resource.

The “admin” group will have the “RBAC Cluster Admin” and the “developers” have the “User Role." With this role assignment, we achieved the principle of least privilege because we denied all kubectl commands to the “developers”. From now on, I, as an administrator, will use Kubernetes RBAC to control what the developers can do. The RBAC you’ll implement will vary depending on your use cases.

Kubernetes RBAC

Now, for example, I'll give permission for the "developers" to read Pods in the dev namespace using the following Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Get the resource ID for the developers group using the az ad group show command. This group is set as the subject of a RoleBinding in the next step.

az ad group show --group developers --query id -o tsv

Create a RoleBinding for the "developers" group to use the previously created Role for reading Pods.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: Group
  namespace: dev
  name: <groupObjectId> # output of the az ad group show

And now, the members of the "developers" group will be able to read Pods in the dev namespace.

Summary

We can set up non-administrator groups with the "Azure Kubernetes Service Cluster User Role" to effectively enforce a "deny-all" policy. This means that members of these groups will have no permission to carry out any actions in the Kubernetes cluster. The administrator can then selectively grant only the necessary permissions to these groups.

This approach allows the administrator to protect Kubernetes Secrets from unauthorised access, prevent the deletion of system Pods, and control access to specific namespaces, which is particularly useful in multi-tenant environments.

In my view, it's better to begin with a closed environment and then gradually open up access as needed rather than starting with open access and then trying to restrict it.