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.
Authentication and Authorization
Configure the cluster to integrate with Microsoft Entra and take advantage to manage users and groups from a 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:
Role | Description |
Azure Kubernetes Service Cluster User Role | This role allows the user to log into the cluster; however if no (Cluster)RoleBidings exists, the user cannot execute any kubectl command. |
Azure Kubernetes Service RBAC Cluster Admin | Allows super-user access to perform any action on any resource. |
The "admin" group will have the "RBAC Cluster Admin" and the "developers" 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 permissions 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 tsvCreate 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 showAnd 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.
Comments