L5. RBAC Deep Dive: Roles, Bindings and Least Privilege

How RBAC Works

Role-Based Access Control (RBAC) in Kubernetes uses four objects:

• Role: Defines permissions within a single namespace
• ClusterRole: Defines permissions cluster-wide or across namespaces
• RoleBinding: Grants a Role or ClusterRole to a user/group/service account within a namespace
• ClusterRoleBinding: Grants a ClusterRole across the entire cluster

The key rule: a RoleBinding can reference a ClusterRole but scopes it to the binding's namespace. This lets you reuse common role definitions without granting cluster-wide access.

Creating Least-Privilege Roles

Start with zero permissions and add only what is needed. Here is a Role that allows a deployment controller to manage pods in a specific namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-manager
  namespace: production
rules:
<ul class="list-disc pl-6 mb-4 space-y-2">
<li class="text-slate-300">apiGroups: [""]</li>
</ul>
    resources: ["pods"]
    verbs: ["get", "list", "watch", "create", "delete"]
<ul class="list-disc pl-6 mb-4 space-y-2">
<li class="text-slate-300">apiGroups: [""]</li>
</ul>
    resources: ["pods/log"]
    verbs: ["get"]

Bind it to a service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-manager-binding
  namespace: production
subjects:
<ul class="list-disc pl-6 mb-4 space-y-2">
<li class="text-slate-300">kind: ServiceAccount</li>
</ul>
    name: deploy-bot
    namespace: production
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

Common RBAC Mistakes

Granting cluster-admin to service accounts: This is the Kubernetes equivalent of running everything as root. If the pod is compromised, the attacker has full cluster control. Using ClusterRoleBindings when RoleBindings suffice: A ClusterRoleBinding grants access across every namespace. Most workloads only need access within their own namespace. Wildcards in verbs or resources: Rules like verbs: ["*"] or resources: ["*"] defeat the purpose of RBAC. Be explicit about every permission. Forgetting subresources: Resources like pods/exec, pods/portforward, and secrets are high-risk. Audit who has access to them.

Auditing RBAC

Use kubectl auth can-i to check effective permissions:

kubectl auth can-i create pods --as=system:serviceaccount:production:deploy-bot -n production
kubectl auth can-i --list --as=system:serviceaccount:production:deploy-bot -n production

For a comprehensive audit, tools like kubectl-who-can and rakkess show which subjects have access to specific resources.

Aggregated ClusterRoles

Kubernetes uses label-based aggregation to compose ClusterRoles. The built-in admin, edit, and view roles aggregate permissions from CRDs and custom roles that carry the right labels. When you install a CRD, add aggregation labels so its resources appear in the standard roles.