Kubernetes · Orchestration under pressure

How does Kubernetes RBAC work in practice?

HardrbacauthorizationsecurityUpdated Oct 2026

Short answer

RBAC grants permissions through Roles or ClusterRoles bound to users, groups or service accounts. Permissions are additive and scoped by namespace unless cluster-scoped.

A Role defines rules with apiGroups, resources and verbs. A RoleBinding grants those permissions within a namespace. ClusterRoles and ClusterRoleBindings apply cluster-wide or can be bound per namespace. There are no deny rules; access is the union of all grants.

Grant the smallest verb set: get and list are different from create and delete
resourceNames can narrow access to specific objects for some verbs
Avoid binding cluster-admin to automation or developers
Aggregated ClusterRoles compose permissions from labels
Audit with kubectl auth can-i --as and reviewed access logs

yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: pod-reader-binding
subjects:
  - kind: ServiceAccount
    name: dashboard
    namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RBAC is necessary but not sufficient. Admission policies, pod security standards and network controls cover risks that RBAC cannot. Review bindings regularly, prefer group-based access over individual users, and be especially careful with permissions on Secrets, pods/exec and impersonation.

The ability to create pods can be equivalent to node-level access if the pod can mount host paths or run privileged. Treat workloads that can create pods as highly trusted.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1What is the difference between a Role and a ClusterRole?
2Why is there no deny rule in RBAC?
3How can pod create permission become a privilege escalation?
4How would you audit who can read Secrets?

Say it in the interview

RBAC defines permissions in Roles or ClusterRoles and grants them with bindings. Rules are additive and scoped by namespace unless I use ClusterRoleBindings. I follow least privilege and pay special attention to Secrets, exec and pod creation, because creating a pod can become node-level access. I also use impersonation checks and regular audits rather than trusting a one-time review.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.

Start a free Kubernetes interview Browse all questions

Follow-ups you should expect

Related questions

Now say it out loud.