Kubernetes RBAC

What it means

Kubernetes RBAC, role-based access control, decides which users and service accounts may perform which actions on which cluster resources. A Role lists permitted verbs, such as get, list or delete, on resources such as pods or secrets. A binding then grants that role to someone.

Roles apply within a namespace, while ClusterRoles apply across the cluster. Permissions are only additive: there are no deny rules, so a subject can do anything any of its bindings allows. Granting broadly is easy and taking back is hard to notice.

Why it matters

The cluster's API is the control point for everything running in it. A subject that can read secrets can read database passwords, and one that can create pods may be able to run code on a node. An over-broad binding turns a small compromise into control of the cluster.

Reviewers and customers ask who has administrator rights. RBAC is also where least privilege is actually enforced for clusters, and where privilege escalation starts when it is too loose. Few teams can say, from memory, which of their service accounts can read secrets.

How it shows up

You meet it in role and binding files, in the permissions given to pipelines and operators, and in the service account every pod receives. Repeated mistakes are giving cluster-admin to people or tools for convenience, wildcard verbs and resources, and leaving default service account tokens mounted in pods that never call the API.

Grant narrow roles in the namespace where they are needed, avoid wildcards, review bindings regularly, and disable token mounting where unused. The kubectl auth can-i command shows what a subject may do. Check the permissions of each workload as if it were compromised.