Why RBAC matters in Kubernetes - See It in Action

Why RBAC Matters in Kubernetes

📖 Scenario: You are managing a Kubernetes cluster for a small company. Different team members need different levels of access to the cluster resources. You want to control who can do what to keep the cluster safe and organized.

🎯 Goal: Learn how to create a simple Role-Based Access Control (RBAC) setup in Kubernetes. You will create a Role, a RoleBinding, and see how they control access to resources.

📋 What You'll Learn

Create a Role with specific permissions

Create a RoleBinding to assign the Role to a user

Understand how RBAC controls access in Kubernetes

Use kubectl commands to apply and check RBAC resources

💡 Why This Matters

🌍 Real World

In real companies, RBAC helps protect sensitive data and operations by limiting access to only those who need it.

💼 Career

Understanding RBAC is essential for Kubernetes administrators and DevOps engineers to secure and manage clusters effectively.

1

Create a Role with permissions

Create a YAML file named read-pods-role.yaml that defines a Role called pod-reader in the default namespace. This Role should allow the get, watch, and list verbs on the resource pods.

Kubernetes

# Write the YAML content for the Role named pod-reader
# Your code here

Hint

Remember to specify apiVersion, kind, metadata with name and namespace, and rules with resources and verbs.

2

Create a RoleBinding to assign the Role

Create a YAML file named read-pods-rolebinding.yaml that defines a RoleBinding called read-pods-binding in the default namespace. This RoleBinding should assign the Role pod-reader to the user jane.

Kubernetes

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

# Write the YAML content for the RoleBinding named read-pods-binding
# Your code here

Hint

Make sure to include subjects with the user jane and roleRef pointing to the Role pod-reader.

3

Apply the Role and RoleBinding in Kubernetes

Use the kubectl apply command to apply both read-pods-role.yaml and read-pods-rolebinding.yaml files to your Kubernetes cluster.

Kubernetes

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

# Write the kubectl command to apply both YAML files
# Your code here

Hint

Use kubectl apply -f followed by the file names to apply the configurations.

4

Verify the RoleBinding and test access

Run the command kubectl get rolebinding read-pods-binding -n default -o yaml to display the RoleBinding details. Then, explain why RBAC is important in Kubernetes in one sentence.

Kubernetes

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

kubectl apply -f read-pods-role.yaml
kubectl apply -f read-pods-rolebinding.yaml

# Run the command to get RoleBinding details and print why RBAC matters
# Your code here

Hint

Use the kubectl get rolebinding command with -n default and -o yaml to see details, then print the explanation.

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