Why RBAC matters in Kubernetes - Visual Breakdown

Process Flow - Why RBAC matters in Kubernetes

User or Service Account

↓

Request to Kubernetes API

↓

RBAC Policy Check

↓

Allowed

↓

Access Granted

↓

Action Performed

This flow shows how Kubernetes checks RBAC policies to decide if a user or service can perform an action.

Execution Sample

Kubernetes

kubectl auth can-i create pods
kubectl auth can-i delete pods
kubectl auth can-i get secrets

These commands check if the current user can create, delete pods or get secrets in Kubernetes.

Process Table

Step	Command	RBAC Check	Result	Explanation
1	kubectl auth can-i create pods	Check if user has 'create' permission on pods	yes	User allowed to create pods by RBAC policy
2	kubectl auth can-i delete pods	Check if user has 'delete' permission on pods	no	User denied delete permission on pods
3	kubectl auth can-i get secrets	Check if user has 'get' permission on secrets	no	User denied access to secrets

💡 All permission checks completed with results based on RBAC policies

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
User Permissions	Defined by RBAC policies	create pods: allowed	delete pods: denied	get secrets: denied

Key Moments - 2 Insights

Why does 'kubectl auth can-i delete pods' return 'no' even if I can create pods?

RBAC policies control permissions separately for each action and resource. As shown in execution_table step 2, delete permission is not granted even if create is allowed.

What happens if RBAC denies access to secrets?

As in execution_table step 3, the user cannot get secrets, so Kubernetes returns an error denying access to protect sensitive data.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of checking 'create pods' permission?

A error

B yes

C no

D unknown

💡 Hint

See execution_table row 1 under Result column

At which step does the user get denied permission to delete pods?

A Step 2

B Step 1

C Step 3

D No denial

💡 Hint

Check execution_table row 2 for permission denial

If the user was granted 'get' permission on secrets, how would the execution_table change?

A Step 1 Result would be 'no'

B Step 2 Result would be 'yes'

C Step 3 Result would be 'yes'

D No change

💡 Hint

Look at execution_table step 3 Result column

Concept Snapshot

RBAC in Kubernetes controls who can do what.
Permissions are set per user, action, and resource.
kubectl auth can-i checks permissions.
Denied actions return errors to protect the cluster.
RBAC keeps Kubernetes secure by limiting access.

Full Transcript

RBAC, or Role-Based Access Control, is important in Kubernetes because it controls what users or services can do. When a user sends a request to the Kubernetes API, the system checks RBAC policies to decide if the action is allowed. For example, using 'kubectl auth can-i create pods' checks if the user can create pods. If allowed, the action proceeds; if denied, Kubernetes returns an error. This protects resources like secrets and controls cluster security by limiting permissions. Each permission is checked separately, so a user might be allowed to create pods but not delete them. This step-by-step permission check ensures only authorized actions happen in the cluster.

Practice

1. What is the main purpose of RBAC in Kubernetes?

easy

A. To automatically scale pods based on load

B. To control who can access and perform actions on cluster resources

C. To monitor the health of Kubernetes nodes

D. To speed up the deployment of applications

Solution

1. Step 1: Understand RBAC's role in Kubernetes

   RBAC stands for Role-Based Access Control, which manages permissions for users and apps.

2. Step 2: Identify RBAC's main function

   It controls who can do what on cluster resources to keep the system secure.

3. Final Answer:

   To control who can access and perform actions on cluster resources -> Option B

4. Quick Check:

   RBAC controls access [OK]

Hint: RBAC is about permissions, not performance or monitoring [OK]

Common Mistakes:

• Confusing RBAC with scaling or monitoring features
• Thinking RBAC speeds up deployments
• Assuming RBAC manages pod health

2. Which of the following is the correct syntax to create a Role in Kubernetes RBAC?

easy

A. apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]

B. apiVersion: v1
kind: Role
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]

C. apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]

D. apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]

Solution

1. Step 1: Check apiVersion and kind for Role

   The correct apiVersion for RBAC Role is "rbac.authorization.k8s.io/v1" and kind is "Role".

2. Step 2: Verify metadata and rules structure

   apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] correctly defines metadata and rules for a Role to access pods with verbs get, watch, list.

3. Final Answer:

   apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] -> Option D

4. Quick Check:

   Role uses rbac.authorization.k8s.io/v1 and kind Role [OK]

Hint: Role uses rbac.authorization.k8s.io/v1 and kind Role exactly [OK]

Common Mistakes:

• Using wrong apiVersion like v1 instead of rbac.authorization.k8s.io/v1
• Confusing Role with RoleBinding or ClusterRole
• Mixing Role and ClusterRole in the same definition

3. Given this RoleBinding YAML snippet, what does it do?

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

medium

A. Revokes all permissions from user 'alice'

B. Grants user 'alice' permission to create pods cluster-wide

C. Grants user 'alice' permission to read pods in the namespace

D. Binds user 'alice' to a ClusterRole named pod-reader

Solution

1. Step 1: Analyze RoleBinding components

   The RoleBinding binds a Role named 'pod-reader' to user 'alice' in the current namespace.

2. Step 2: Understand Role permissions

   The Role 'pod-reader' typically allows reading pods (get, watch, list) in the namespace.

3. Final Answer:

   Grants user 'alice' permission to read pods in the namespace -> Option C

4. Quick Check:

   RoleBinding + Role = namespace-scoped permission [OK]

Hint: RoleBinding links Role permissions to a user in a namespace [OK]

Common Mistakes:

• Confusing RoleBinding with ClusterRoleBinding
• Assuming permissions are cluster-wide
• Thinking it revokes permissions

4. You created a RoleBinding but the user still cannot access pods. What is the most likely cause?

medium

A. The RoleBinding references a Role that does not exist

B. The user is not logged into the cluster

C. The RoleBinding is missing the apiVersion field

D. The RoleBinding uses ClusterRole instead of Role

Solution

1. Step 1: Check RoleBinding references

   If the RoleBinding points to a Role that does not exist, permissions won't apply.

2. Step 2: Verify Role existence

   Without the referenced Role, Kubernetes cannot grant permissions, causing access failure.

3. Final Answer:

   The RoleBinding references a Role that does not exist -> Option A

4. Quick Check:

   RoleBinding must reference an existing Role [OK]

Hint: Always verify Role exists before binding [OK]

Common Mistakes:

• Ignoring Role existence and blaming user login
• Assuming missing apiVersion causes access denial
• Confusing Role with ClusterRole in RoleBinding

5. You want to allow a service account to manage deployments across all namespaces securely. Which RBAC setup is best?

hard

A. Create a ClusterRole with deployment permissions and bind it with a ClusterRoleBinding to the service account

B. Create a Role with deployment permissions in each namespace and bind it with RoleBindings

C. Create a RoleBinding with cluster-wide scope to the service account

D. Assign admin cluster role directly to the service account

Solution

1. Step 1: Understand scope of permissions needed

   Managing deployments across all namespaces requires cluster-wide permissions.

2. Step 2: Choose appropriate RBAC objects

   ClusterRole defines permissions cluster-wide; ClusterRoleBinding assigns it to the service account.

3. Step 3: Avoid less secure or inefficient options

   Creating Roles per namespace is tedious; RoleBinding cannot grant cluster-wide scope; admin role is too broad.

4. Final Answer:

   Create a ClusterRole with deployment permissions and bind it with a ClusterRoleBinding to the service account -> Option A

5. Quick Check:

   ClusterRole + ClusterRoleBinding = cluster-wide access [OK]

Hint: Use ClusterRole + ClusterRoleBinding for cluster-wide permissions [OK]

Common Mistakes:

• Using RoleBindings for cluster-wide access
• Assigning overly broad admin role unnecessarily
• Creating many Roles instead of one ClusterRole