Why RBAC matters in Kubernetes - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a Role that allows reading pods in a namespace.

Kubernetes

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

Drag options to blanks, or click blank then click option'

Aget

Bdelete

Ccreate

Dupdate

Attempts:

3 left

💡 Hint

Common Mistakes

Using verbs like delete or create which modify resources instead of reading.

The verb get allows reading pods, which is essential for viewing pod details without modifying them.

2fill in blank

medium

Complete the code to bind the Role 'pod-reader' to a user named 'alice'.

Kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User
  name: [1]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Drag options to blanks, or click blank then click option'

Aalice

Bbob

Cadmin

Dsystem

Attempts:

3 left

💡 Hint

Common Mistakes

Using other user names not specified in the task.

The user alice is the one to whom the Role is being assigned, allowing her to read pods.

3fill in blank

hard

Fix the error in the RoleBinding that incorrectly references a ClusterRole instead of a Role.

Kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: [1]
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Drag options to blanks, or click blank then click option'

AClusterRole

BServiceAccount

CUser

DRole

Attempts:

3 left

💡 Hint

Common Mistakes

Using ClusterRole in RoleBinding causes permission errors.

The RoleBinding must reference a Role (not a ClusterRole) when binding permissions within a namespace.

4fill in blank

hard

Fill both blanks to create a ClusterRole that allows listing and watching all pods across namespaces.

Kubernetes

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

Drag options to blanks, or click blank then click option'

Alist

Bwatch

Cdelete

Dcreate

Attempts:

3 left

💡 Hint

Common Mistakes

Including verbs like delete or create which change resources.

The verbs list and watch allow seeing pods and tracking changes across all namespaces.

5fill in blank

hard

Fill all three blanks to create a RoleBinding that assigns the 'pod-list-watch' ClusterRole to a service account named 'monitor' in the 'monitoring' namespace.

Kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: monitor-pods
  namespace: monitoring
subjects:
- kind: [1]
  name: [2]
  namespace: monitoring
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: [3]
  name: pod-list-watch
  apiGroup: rbac.authorization.k8s.io

Drag options to blanks, or click blank then click option'

AUser

Bmonitor

CClusterRole

DServiceAccount

Attempts:

3 left

💡 Hint

Common Mistakes

Using User instead of ServiceAccount or Role instead of ClusterRole.

The subject kind is ServiceAccount, the name is monitor, and the roleRef kind is ClusterRole because the role is cluster-wide.

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