RBAC and effective authority

The mechanism

RBAC authorizes API operations using roles and bindings. A Role describes permissions in a namespace; a ClusterRole can describe cluster-wide or reusable permissions. Bindings connect those permissions to users, groups or ServiceAccounts. Authentication identifies the caller; authorization decides whether the operation is allowed.

Permissions are additive. There is no ordinary RBAC deny rule that cancels a grant from another binding. Review the full set of effective grants rather than one carefully written Role in isolation.

A read-only ParcelOps observer might need to list Pods in one lab namespace. It does not need secret reads, workload creation or role administration. Indirect capabilities matter: creating workloads, impersonating identities or changing bindings can lead to much broader authority.

Worked example

This offline Role manifest describes narrow read access. It does not create a binding and therefore grants nothing by itself. No permission changes are executed in the handbook.

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

Practice: predict, inspect, explain

Offline exercise. Evaluate get Pods, delete Pods, read Secrets and list Pods in another namespace against this Role alone. Then add a hypothetical second binding granting broader permissions and explain why the first Role does not restrict that additional grant.

Expected observation: a narrow role is not an exclusive permission envelope. Review all bindings and sensitive indirect actions. In an optional approved lab, permission queries can help inspect effective access, but they do not replace understanding admission policy or the effects of allowed operations.

Troubleshooting and trade-offs

If a request is forbidden, inspect the exact subject, API group, resource, subresource, verb and namespace. Do not respond by assigning cluster-admin. If a permission appears unexpectedly allowed, look for another binding. Separate workload identity from human administration and avoid wildcard rules unless a justified, reviewed requirement truly needs them.

Interview practice

Completion check

Evaluate four requests and explain why a second binding changes the effective authority.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

• Official documentation: Rbac
• Official documentation: Service accounts
• Official documentation: Overview