> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RBAC You Can Live With Least Privilege Without Pain

> Practical guide to Kubernetes RBAC, explaining Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, least privilege practices, examples and debugging with kubectl auth can-i

Role-based access control (RBAC) is the most fundamental security layer in Kubernetes. This guide makes RBAC practical: you'll learn the four RBAC resources, how to author Roles, how to bind them to users and ServiceAccounts, and how to debug permissions with `kubectl auth can-i`.

Why RBAC matters — a real cost of skipping least privilege

A SaaS company avoided delays by giving all forty developers `cluster-admin`. A junior developer ran:

```bash theme={null}
kubectl delete ns staging
```

but their kubeconfig pointed at production. The production namespace was deleted: thirty-two Deployments, fifteen Services, eight StatefulSets, and all PVCs. Because the PVC reclaim policy was `Delete`, that data was permanently lost. The outage lasted six hours and cost the company significant revenue and recovery expenses.

The root cause: everyone had broad `cluster-admin` rights, so there was no separation of environments and no restriction on destructive actions.

![A slide titled "The cluster-admin Anti-Pattern" showing three colored arrows pointing down with reasons why it happened: "Everyone had cluster-admin," "No restriction on destructive actions," and "No separation between environments." The slide is © KodeKloud.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Security-and-Policy-Enforcement/RBAC-You-Can-Live-With-Least-Privilege-Without-Pain/clusteradmin-anti-pattern-everyone-had-access.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=d422df49e042767f16c689eb64c72a09)

That entire class of incidents is prevented by well-applied RBAC. Below is a concise reference and practical examples.

What are the four RBAC resources?

Kubernetes RBAC has exactly four objects. Two define permissions (the “what”) and two assign those permissions to identities (the “who”):

* Role — namespace-scoped permissions.
* ClusterRole — cluster-scoped permissions or permissions for non-namespaced resources (nodes, CRDs).
* RoleBinding — grants a Role or ClusterRole within a single namespace.
* ClusterRoleBinding — grants a ClusterRole across all namespaces.

Start with namespace-scoped Roles and RoleBindings. Only escalate to cluster-scoped permissions when there is a documented, repeatable need.

![An infographic titled "The Four RBAC Resources" that summarizes Kubernetes RBAC objects: Role (namespace-scoped) and ClusterRole (cluster-wide) under "WHAT (Permissions)", and RoleBinding (namespace) and ClusterRoleBinding (cluster-wide) under "WHO (Binding)". Each box briefly explains the scope and purpose of the resource.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Security-and-Policy-Enforcement/RBAC-You-Can-Live-With-Least-Privilege-Without-Pain/kubernetes-rbac-resources-infographic.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=863429b20d5d9bd113e857600211d115)

Quick reference table

| Resource | Scope | Purpose | Typical use case |
| -: | :-: | :- | :- |
| Role | Namespace | Define permissions (`apiGroups`, `resources`, `verbs`) | Developer access to their namespace |
| ClusterRole | Cluster | Define cluster-wide or non-namespaced permissions | Monitoring that needs cluster read access |
| RoleBinding | Namespace | Bind a Role or ClusterRole to subjects within a namespace | Grant CI/CD deploy rights in a namespace |
| ClusterRoleBinding | Cluster | Bind a ClusterRole to subjects across the cluster | Platform/team-wide admin roles |

How to write a Role (example)

Create a namespace-scoped Role that grants read-only access to pods in the `payments` namespace:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: payments
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
```

Rule fields explained

* `apiGroups`: an empty string (`""`) is the core API group (pods, services, secrets). Other groups include `apps` (Deployments, StatefulSets) and `batch` (Jobs).
* `resources`: the resource types this rule applies to (e.g., `pods`, `secrets`, `deployments`).
* `verbs`: allowed actions. Common sets:
  * Read-only: `get`, `list`, `watch`
  * Read-write: add `create`, `update`, `patch`
  * Delete: include `delete`
  * Wildcard: `"*"` — avoid unless absolutely necessary
* `resourceNames`: narrow scope to specific named resources for very precise access control.

A Role by itself does nothing — you must bind it.

RoleBinding examples

RoleBindings connect subjects (the who) with Roles or ClusterRoles (the what). Two common examples:

* RoleBinding for a single user in the `payments` namespace:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-payments
  namespace: payments
subjects:
  - kind: User
    name: alice
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

* RoleBinding that grants the reusable `edit` ClusterRole to a CI/CD ServiceAccount (bound per-namespace):

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cicd-deployer
  namespace: payments
subjects:
  - kind: ServiceAccount
    name: deploy-bot
    namespace: cicd
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
```

Subject kinds you’ll use

* `User` — human identities provisioned by your identity provider.
* `Group` — collections of users from your IdP (useful for role assignment at scale).
* `ServiceAccount` — identities used by Pods inside the cluster.

When to choose Role vs. ClusterRole (decision guide)

* Developer viewing pods in their own namespace: use `Role` + `RoleBinding`.
* CI/CD deploying to multiple namespaces: create a reusable `ClusterRole`, and bind it per-namespace with `RoleBinding`.
* Monitoring or tools that require read access across namespaces: `ClusterRole` + `ClusterRoleBinding`.
* Platform teams that manage nodes, CRDs, or cluster-level resources: `ClusterRole` + `ClusterRoleBinding`.
* `cluster-admin` should be reserved for emergency or break-glass scenarios only — not day-to-day use.

![A presentation slide titled "Namespace vs Cluster Scope: The Key Decision" showing a table that maps example scenarios (e.g., dev viewing pods, CI/CD deploying, monitoring, admin tasks) to Kubernetes role types and binding types. The slide includes entries like Role/RoleBinding for namespace access and ClusterRole/ClusterRoleBinding for cluster-wide access.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Security-and-Policy-Enforcement/RBAC-You-Can-Live-With-Least-Privilege-Without-Pain/namespace-cluster-scope-roles-bindings.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=9098dbfc8711865d32f01febd8592602)

Debugging RBAC with kubectl auth can-i

`kubectl auth can-i` is the primary tool for testing and troubleshooting RBAC permissions.

Basic examples:

```bash theme={null}
# Can I create Deployments in the payments namespace?
kubectl auth can-i create deployments -n payments
# Can user alice delete secrets in production?
kubectl auth can-i delete secrets -n production --as=alice
# What can the deploy-bot ServiceAccount do in payments?
kubectl auth can-i --list -n payments --as=system:serviceaccount:cicd:deploy-bot
```

Tips for using `can-i` effectively

* Single-action checks return a simple `yes` or `no`.
* Use `--as=<user>` or `--as=system:serviceaccount:<ns>:<name>` to impersonate an identity.
* Use `--list` to enumerate all allowed actions for the impersonated identity in a namespace.
* Apply your Role and RoleBinding manifests, then confirm behavior with `kubectl auth can-i` before granting wider access.

Avoid granting broad cluster-scoped rights to large groups. The cluster-admin anti-pattern leads to accidental deletions and data loss — follow least-privilege principles.

Summary — practical checklist

* Know the four RBAC objects: `Role`, `ClusterRole`, `RoleBinding`, `ClusterRoleBinding`.
* Start with namespace-scoped `Role` + `RoleBinding`. Escalate only when necessary.
* Build Roles from `apiGroups`, `resources`, and `verbs`. Use `resourceNames` for precise limits.
* Bind Roles to `User`, `Group`, or `ServiceAccount`.
* Validate and debug with `kubectl auth can-i`.

Links and references

* [Kubernetes RBAC Reference](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
* [kubectl auth can-i documentation](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#auth)
* [Kubernetes Concepts: RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#overview)

> **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/35a7fadb-02d8-4557-a819-2e4dcfa970cc/lesson/997cda2d-bff5-4d6c-af4d-47784cdd3498)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.