> ## 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.

# Demo RBAC Roles and Bindings

> Guide to Kubernetes RBAC, creating Roles and ClusterRoles, binding users and service accounts, verifying permissions with impersonation, and applying least privilege and best practices

Everything on your platform starts with one question: who is allowed to do what and where?

Role-Based Access Control (RBAC) is a core Kubernetes security model that answers that question. Roles define permissions (verbs on resources) and bindings attach those permissions to identities (users, groups, or service accounts). Misconfigured RBAC either locks teams out or leaves the cluster exposed — so use least privilege and verify changes.

RBAC follows the principle of least privilege: grant only the permissions that an identity needs. If a permission isn't explicitly granted, it's denied.

This guide walks through:

* Inspecting namespaces and service accounts
* Creating a namespaced Role and RoleBinding
* Creating a ClusterRole and ClusterRoleBinding
* Binding roles to service accounts
* Verifying permissions with impersonation and best practices

## Inspect namespaces and service accounts

List namespaces and then list service accounts in each team namespace:

```bash theme={null}
# List namespaces
kubectl get namespaces

# List service accounts in team-alpha
kubectl get sa -n team-alpha

# List service accounts in team-beta
kubectl get sa -n team-beta
```

Example output:

```bash theme={null}
controlplane ~ » kubectl get namespaces
NAME               STATUS   AGE
default            Active   18h
kube-flannel       Active   18h
kube-node-lease    Active   18h
kube-public        Active   18h
kube-system        Active   18h
team-alpha         Active   5m41s
team-beta          Active   5m41s

controlplane ~ » kubectl get sa -n team-alpha
NAME        AGE
default     6m1s
deploy-bot  6m1s

controlplane ~ » kubectl get sa -n team-beta
NAME         AGE
default      6m8s
readonly-sa  6m8s
```

## Namespaced Role: developer

Create a Role scoped to the `team-alpha` namespace that grants CRUD-like permissions on core resources and the `apps` group.

```yaml theme={null}
# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: team-alpha
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
```

Apply the Role:

```bash theme={null}
kubectl apply -f developer-role.yaml
```

You should see:

```bash theme={null}
role.rbac.authorization.k8s.io/developer created
```

### Bind the Role to a user (RoleBinding)

Bind the `developer` Role to the user `alice` in `team-alpha`:

```bash theme={null}
kubectl create rolebinding alice-developer --role=developer --user=alice -n team-alpha
```

Expected output:

```bash theme={null}
rolebinding.rbac.authorization.k8s.io/alice-developer created
```

### Verify Alice's permissions (impersonation)

Use `kubectl auth can-i` with `--as` to impersonate `alice` and validate permissions:

```bash theme={null}
# Can Alice create pods in team-alpha?
kubectl auth can-i create pods -n team-alpha --as=alice

# Can Alice create pods in team-beta?
kubectl auth can-i create pods -n team-beta --as=alice
```

Expected output:

```bash theme={null}
controlplane ~ » kubectl auth can-i create pods -n team-alpha --as=alice
yes

controlplane ~ » kubectl auth can-i create pods -n team-beta --as=alice
no
```

Because the RoleBinding is namespaced to `team-alpha`, Alice can create pods there but not in `team-beta`. This enforces least privilege by design.

When granting or revoking RBAC permissions, exercise caution. Impersonation (using `--as`) helps validate changes before committing them.

## ClusterRole: viewer

For cluster-wide view-only access, use a ClusterRole (not namespaced). The `viewer` ClusterRole below grants `get`, `list`, and `watch` on selected core and apps resources across the cluster.

```yaml theme={null}
# viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: viewer
rules:
- apiGroups: [""]
  resources: ["pods", "services", "namespaces", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch"]
```

Apply the ClusterRole and create a ClusterRoleBinding for user `bob`:

```bash theme={null}
kubectl apply -f viewer-clusterrole.yaml
kubectl create clusterrolebinding bob-viewer --clusterrole=viewer --user=bob
```

Expected output:

```bash theme={null}
clusterrole.rbac.authorization.k8s.io/viewer created
clusterrolebinding.rbac.authorization.k8s.io/bob-viewer created
```

Verify Bob's permissions with impersonation:

```bash theme={null}
# Can Bob list pods in team-alpha?
kubectl auth can-i list pods --as=bob -n team-alpha

# Can Bob list pods in team-beta?
kubectl auth can-i list pods --as=bob -n team-beta

# Can Bob create pods in team-beta?
kubectl auth can-i create pods --as=bob -n team-beta
```

Expected output:

```bash theme={null}
controlplane ~ » kubectl auth can-i list pods --as=bob -n team-alpha
yes

controlplane ~ » kubectl auth can-i list pods --as=bob -n team-beta
yes

controlplane ~ » kubectl auth can-i create pods --as=bob -n team-beta
no
```

Bob has read-only access across the cluster but cannot create or modify resources.

## Binding a Role to a ServiceAccount

Service accounts are identities used by in-cluster workloads (CI/CD pipelines, controllers, automation). You bind Roles the same way you bind users.

Create a RoleBinding to give the `team-alpha:deploy-bot` service account the `developer` role:

```bash theme={null}
kubectl create rolebinding deploy-bot-developer \
  --role=developer \
  --serviceaccount=team-alpha:deploy-bot \
  -n team-alpha
```

Expected output:

```bash theme={null}
rolebinding.rbac.authorization.k8s.io/deploy-bot-developer created
```

Verify the service account can create deployments in `team-alpha` by impersonating its system name:

```bash theme={null}
kubectl auth can-i create deployments -n team-alpha \
  --as=system:serviceaccount:team-alpha:deploy-bot
```

Expected output:

```bash theme={null}
controlplane ~ » kubectl auth can-i create deployments -n team-alpha --as=system:serviceaccount:team-alpha:deploy-bot
yes
```

Now check the `readonly-sa` in `team-beta`, which has no bindings — it should not be able to get pods:

```bash theme={null}
kubectl auth can-i get pods -n team-beta --as=system:serviceaccount:team-beta:readonly-sa
```

Expected output:

```bash theme={null}
controlplane ~ » kubectl auth can-i get pods -n team-beta --as=system:serviceaccount:team-beta:readonly-sa
no
```

By default, Kubernetes RBAC denies permissions that are not explicitly granted.

## Role vs ClusterRole and Bindings — quick reference

| Type | Scope | Use case | Bindings |
| - | - | - | - |
| Role | Namespaced | Grant permissions within a specific namespace | RoleBinding (namespace-scoped) |
| ClusterRole | Cluster-wide | Grant permissions across the cluster or for non-namespaced resources | ClusterRoleBinding (cluster-scoped) |
| RoleBinding | Namespaced | Attach a Role or ClusterRole to subjects within a namespace | N/A |
| ClusterRoleBinding | Cluster-scoped | Attach a ClusterRole to subjects cluster-wide | N/A |

## Debugging and best practices

* Validate permissions with `kubectl auth can-i` and `--as` to impersonate users or service accounts.
* Prefer namespaced Roles and RoleBindings whenever possible; use ClusterRoles sparingly.
* Follow least privilege: grant only the verbs/resources required and scope them to the appropriate namespace.
* Test RBAC changes in a staging or non-production cluster before rolling them out to production.
* Keep Role and ClusterRole manifests in version control and review changes (code review/PR) before applying.

Practice creating Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings in a safe environment to build confidence and enforce secure access patterns.

## Links and references

* [Kubernetes RBAC documentation](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 authorization overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/35a7fadb-02d8-4557-a819-2e4dcfa970cc/lesson/cfeb58dd-916f-46fd-805a-ff58b8242fcc)**

> **[Practice Lab](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/35a7fadb-02d8-4557-a819-2e4dcfa970cc/lesson/cfac0a94-3720-4891-9aac-3f80c4454333)**


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