Kubernetes interview question · Most asked
How does RBAC work in Kubernetes, and how do you apply least privilege?
Summary
Roles (namespaced) and ClusterRoles (cluster-wide) list allowed verbs on resources; RoleBindings and ClusterRoleBindings grant them to users, groups or ServiceAccounts. Everything is deny-by-default and permissions are additive.
Longer Answer
Least-privilege practice: give each workload its own ServiceAccount with only the permissions it needs (most apps need none, so disable token automounting); bind people through groups from the identity provider; avoid cluster-admin bindings and wildcard verbs; and audit regularly (kubectl auth can-i --list --as=..., tools such as rbac-lookup or kubectl-who-can).
Dangerous permissions to watch: get/list secrets, create pods (can mount any secret or ServiceAccount in the namespace), escalate/bind/impersonate, and nodes/proxy.
Key Points
- Roles + bindings; deny by default.
- One ServiceAccount per workload.
- No cluster-admin or wildcards.
- Watch secrets, pod create, escalate/impersonate.
More most-asked Kubernetes questions
- ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?
- How does the scheduler place pods? Explain resource requests, node affinity, taints and tolerations.
- Describe the Kubernetes architecture: what runs on the control plane and what runs on the nodes?
- How do rolling updates work in a Deployment, and how do you roll back?
- Explain the Service types: ClusterIP, NodePort, LoadBalancer, ExternalName and headless.
- What happens, step by step, when you run kubectl apply for a Deployment?
- Deployment, StatefulSet, DaemonSet, Job and CronJob: when do you use each?
- What is the difference between resource requests and limits, and what are the QoS classes?