Kubernetes RBAC is simple at object level and subtle at security level. A Role lists allowed actions, a binding grants those actions to subjects, and a seemingly narrow permission such as creating Pods can unlock access to credentials and workloads.

A sound design begins with job functions and trust boundaries, then grants explicit verbs on explicit resources. This guide covers namespaced and cluster-wide roles, ServiceAccounts, escalation risks, validation commands and a review process that prevents silent privilege growth.

What you will learn

  • Prefer RoleBindings and namespace scope unless the task genuinely spans the cluster.
  • Avoid wildcards because new API resources can silently expand a grant.
  • Pod creation, Secret access, role binding, impersonation and exec need special scrutiny.
  • Give each workload a dedicated ServiceAccount and disable unused token mounting.

Roles define; bindings grant

A Role is scoped to one namespace. A ClusterRole is cluster-scoped, but a RoleBinding can grant its namespaced permissions in one namespace. ClusterRoleBinding grants applicable permissions cluster-wide. This distinction controls blast radius.

Permissions combine API groups, resources, optional resource names and verbs. Start from exact operations. Do not begin with admin rights and attempt to subtract risk later.

A namespaced read-only pattern

This Role lets support inspect Pods and logs in one namespace. It cannot create Pods, execute commands or read Secrets. Separating read access from mutation makes approval and auditing clearer.

Group subjects should come from a revocable identity provider. Avoid long-lived individual client certificates where centralized identity is available.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-observer
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

ServiceAccounts for workloads

The default ServiceAccount should not become a shared application identity. Create one per workload or tightly related component, and bind only the required API permissions.

If the application never calls Kubernetes, set automountServiceAccountToken to false. This removes an unnecessary credential from the container filesystem and limits post-compromise access.

Permissions that escalate

Reading Secrets is sensitive, but indirect permissions matter. Pod creation can permit credential mounts or risky host resources subject to admission. Binding roles, impersonating identities, or using bind and escalate verbs can cross expected boundaries.

Access to pods/exec gives code execution inside workloads. Node proxy access and privileged custom resources can also expose powerful functions. Review how controllers react to every custom resource you authorize.

Test effective access

Query authorization, not only manifests. kubectl auth can-i tests a verb, resource, namespace and impersonated subject. Automated checks can assert both required allows and important denials.

RBAC is additive and has no deny rule. One forgotten binding can restore broad access. Inventory RoleBindings, ClusterRoleBindings and identity-provider group membership.

kubectl auth can-i get pods -n production --as=alice@example.com
kubectl auth can-i create secrets -n production --as=alice@example.com
kubectl auth can-i --list --as=system:serviceaccount:production:api -n production

Operate RBAC as reviewed code

Store roles and bindings in version control, require review for cluster-wide grants and attach ownership. Keep break-glass access short-lived, monitored and tested before an incident.

Review unused subjects, direct user bindings, wildcards and duplicated roles. Correlate configuration with audit logs to identify grants broader than observed need.

Production checklist

  • Use RoleBinding when namespace scope is sufficient.
  • Eliminate wildcard verbs, resources and API groups.
  • Assign dedicated ServiceAccounts and disable unused token mounts.
  • Review Pod, Secret, exec, bind, escalate and impersonate access.
  • Test allow and deny expectations with kubectl auth can-i.
  • Version and periodically recertify privileged bindings.

Frequently asked questions

Can a ClusterRole be limited to one namespace?

Yes. A RoleBinding can reference a ClusterRole and grant its namespaced permissions only in that namespace.

Does RBAC support explicit deny?

No. Permissions are additive, so removal means ensuring that no applicable binding grants the ability.

Why is create pods powerful?

A Pod executes code and may access service-account tokens, namespace Secrets or host resources unless other controls block it.

Continue learning Kubernetes

Official Kubernetes references