RBAC

RBAC follows the principle of least privilege: grant only the permissions a user or workload needs. A developer in a namespace might get get, list and watch on pods and logs, but not delete or exec. A CI system might get create and patch on deployments in its own namespace only.

How it works

RBAC is enabled by adding it to the API server’s authorisation modes. It is built from four objects. A Role holds permissions within a single namespace. A ClusterRole is cluster-scoped and can cover cluster-scoped resources such as nodes, non-resource endpoints such as /healthz, or namespaced resources across all namespaces. A RoleBinding grants a Role or ClusterRole to subjects within one namespace, and a ClusterRoleBinding grants a ClusterRole cluster-wide. Subjects are users, groups or service accounts.

Permissions are purely additive: there are no deny rules, so a subject’s access is the union of every binding that applies to it. A RoleBinding can reference a ClusterRole, which is a handy way to define a reusable role once and grant it per namespace.

Authentication is separate and comes from your platform. On EKS, AWS documents access entries as the preferred way to grant IAM principals access to the Kubernetes API, replacing the legacy aws-auth ConfigMap, and entries can reference Kubernetes groups that you bind with RBAC. On AKS, you can use Microsoft Entra ID groups as RoleBinding subjects.

A practical example

A read-only role for pods in the dev namespace, bound to a group:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods
subjects:
- {kind: Group, name: developers, apiGroup: rbac.authorization.k8s.io}
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

You can test the result with kubectl auth can-i list pods --namespace dev --as jane.

Common mistakes

• Granting cluster-admin for convenience, or using wildcards in verbs and resources, which gives far more access than intended.
• Using a ClusterRoleBinding where a RoleBinding would limit the scope to one namespace.
• Forgetting that permissions are additive, then trying to remove access by adding another binding. You must remove or narrow the original binding.
• Leaving default service accounts with more permissions than the workload needs.
• Not reviewing who can read Secrets, create pods or modify RBAC objects, since those permissions can lead to wider access.

When to use it and when not to

RBAC should be on in every cluster and scoped per team and per workload. It controls API access only. It does not restrict pod-to-pod traffic, so combine it with network policies, and use namespaces as the natural boundary for most bindings. Our Kubernetes consulting service includes access reviews.

See also

• Kubernetes
• EKS
• Network Policy
• Namespace