Why RBAC matters in Kubernetes - Why It Works

Introduction

Kubernetes controls access to its resources using RBAC, which stands for Role-Based Access Control. It helps keep your cluster safe by making sure only the right people or programs can do certain actions.

When you want to limit who can create or delete pods in your Kubernetes cluster.

When you need to give a developer permission to only view resources but not change them.

When you want to allow an automated system to update deployments but not access secrets.

When you want to prevent accidental or harmful changes by restricting permissions.

When you want to audit who did what by assigning clear roles and permissions.

Config File - rbac-role.yaml

rbac-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

This file creates a Role named pod-reader in the default namespace that allows reading pods only.

The RoleBinding connects the Role to a user named jane, giving her permission to get, watch, and list pods in that namespace.

Commands

This command applies the RBAC Role and RoleBinding to the cluster, setting up the permissions for user jane.

Terminal

kubectl apply -f rbac-role.yaml

Expected Output

role.rbac.authorization.k8s.io/pod-reader created

rolebinding.rbac.authorization.k8s.io/read-pods-binding created

This checks if user jane has permission to get pods in the default namespace, verifying the RoleBinding works.

Terminal

kubectl auth can-i get pods --as=jane -n default

Expected Output

yes

→

--as - Simulates the command as the specified user

→

-n - Specifies the namespace to check permissions in

This checks if user jane can delete pods, which she should not be able to do with the current Role.

Terminal

kubectl auth can-i delete pods --as=jane -n default

Expected Output

no

→

--as - Simulates the command as the specified user

→

-n - Specifies the namespace to check permissions in

Key Concept

If you remember nothing else from this pattern, remember: RBAC lets you control who can do what in your Kubernetes cluster to keep it safe and organized.

Common Mistakes

Not specifying the correct namespace in RoleBinding or commands

Permissions are namespace-scoped, so missing or wrong namespaces cause access denial or unexpected access.

Always specify the correct namespace when creating RoleBindings and when checking permissions.

Assigning overly broad permissions like admin roles to all users

This can lead to accidental or malicious changes that harm the cluster or leak data.

Grant only the minimum permissions needed for each user or service.

Forgetting to bind Roles to users or service accounts

Roles alone do nothing until they are bound to subjects, so users won't get the intended permissions.

Always create RoleBindings or ClusterRoleBindings to connect Roles to users or groups.

Summary

Create Roles to define what actions are allowed on Kubernetes resources.

Use RoleBindings to assign these Roles to specific users or groups in a namespace.

Verify permissions with kubectl auth can-i to ensure correct access control.

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