RBAC: Who Can Do What

Key Takeaways for AI & Readers

• Model: Role-Based Access Control (additive permissions only).
• Subjects: Users, Groups, and ServiceAccounts.
• Scope: Roles (Namespaced) vs. ClusterRoles (Global).

Kubernetes security follows the Principle of Least Privilege.

0. The "Default Deny" Philosophy

In Kubernetes, permissions are additive only. There are no "Deny" rules.

1. Everything starts with Zero permissions.
2. You add "Allow" rules via Roles.
3. If a user has two Roles, and one allows "Delete" while the other doesn't, the user can delete.

Rule of Thumb: If you don't explicitly grant it, it is forbidden.

---

1. Namespaces: The Virtual Cluster

A Namespace allows you to partition a single physical cluster into multiple virtual clusters.

Why use them?

• Isolation: Separate dev, staging, and prod environments.
• Access Control: Give "Team A" full control over namespace-a but no access to namespace-b.
• Resource Quotas: Limit how much CPU/RAM a namespace can consume.

Common Namespaces

• default: Where things go if you don't specify a namespace.
• kube-system: System components (API server, DNS, etc.). Don't touch this.
• kube-public: Auto-readable by everyone (rarely used).

---

2. Role-Based Access Control (RBAC)

Security in Kubernetes is deny-by-default. No one (User or Pod) can do anything unless they are explicitly granted permission via RBAC.

Interactive RBAC Graph

Visualize the relationship: Subject (User) → RoleBinding → Role → Permissions.

User: alice

Bind to pod-readerBind to cluster-admin

User: bob

Bind to pod-readerBind to cluster-admin

How RBAC Works:

• Users have no permissions by default.
• Roles define "what" can be done (Verbs) to "which" objects (Resources).
• RoleBindings connect a User to a Role.

User: alice

User: bob

Role: pod-reader

get, list → pods

Role: cluster-admin

get, list, create, delete → pods, secrets, services

📦 Pods

🔑 Secrets

🌐 Services

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Role vs ClusterRole

This distinction trips up everyone.

Feature	Role	ClusterRole
Scope	Single Namespace	Entire Cluster
Binding	RoleBinding	ClusterRoleBinding
Use Case	App Developer, Team Member	Cluster Admin, CI/CD System

Example Scenarios

Scenario A: "Alice is a developer on Team Frontend"

1. Create Namespace frontend.
2. Create Role in frontend allowing create, get, list on pods, services.
3. Create RoleBinding in frontend connecting User: Alice to that Role. Result: Alice can manage pods in frontend, but can't see backend or delete Nodes.

Scenario B: "Bob is the SRE Admin"

1. Use built-in cluster-admin ClusterRole.
2. Create ClusterRoleBinding connecting User: Bob to cluster-admin. Result: Bob can do anything.

Aggregated ClusterRoles

You can combine multiple ClusterRoles into one using labels.

• Use Case: Creating a default "view" role that automatically includes new CRD read permissions when you install a new Operator.

User Impersonation

"Can Alice really delete pods?" You can test permissions without logging in as the user:

kubectl auth can-i delete pods --as alice --as-group developers

Result: yes or no.

💬 Feedback & Comments

Have a question or found a bug? Leave a comment below using your GitHub account.