✅ CKAD — RBAC Question # 8 (Final Notes, Exam-Style)

📌 Question

You are given a Deployment running in namespace analytics. It is failing due to RBAC issues.

A task list is provided:

  1. Create a ServiceAccount named scout.
  2. In the same namespace, three Role manifests are provided under /opt/roles/. Examine them and deploy only the correct Role that satisfies the Deployment’s needs.
  3. Create a RoleBinding in the namespace attaching the correct Role to the scout ServiceAccount.
  4. Update the Deployment so it uses the new ServiceAccount.
  5. Roll out the fix and verify that the Deployment logs no longer report RBAC errors.

The Deployment container runs the following command in a loop:

kubectl get pods

🎯 What the question is REALLY testing

This question evaluates your ability to:

  • Read Pod logs to understand RBAC failures
  • Identify whether the requirement is Role or ClusterRole
  • Identify which verbs and resources are needed
  • Choose the correct RBAC manifest from multiple wrong ones
  • Bind it via RoleBinding
  • Patch the Deployment correctly
  • Roll out the fix and verify

🔍 Hidden Traps (Very Common in CKAD)

These must be explicitly remembered:

1. Logs contain “Error from server (Forbidden)” + “in namespace …”

This means:

  • It is NOT cluster-scoped
  • You must use Role, NOT ClusterRole
  • You must create a RoleBinding, NOT ClusterRoleBinding

2. The wrong Role may:

  • Use the wrong verbs (watch, patch, delete)
  • Have unrelated resources (events, secrets, deployments)
  • Have incomplete resources (pods/log without pods)
  • Have only partial verbs
  • Have only the sub-resource (pods/log) which is never valid alone

3. pods/log NEVER works alone.

If a manifest contains:

resources:
- pods/log

But does NOT contain:

- pods

→ This Role is invalid. Reject it.

4. The Role manifests may be valid YAML but logically incorrect.

You must match resources + verbs to the Deployment’s error.

5. Deployment logs are long (10–90 days old).

Use:

kubectl logs deploy/mydeploy -n analytics --since=2m --timestamps

So you see only the recent RBAC errors.

🧠 Interpreting the Logs (critical step)

Example log:

Error from server (Forbidden): pods is forbidden:
User "system:serviceaccount:analytics:default"
cannot list resource "pods" in API group "" in the namespace "analytics"

From this we extract:

Required Resource:

  • pods

Required Verb:

  • list
  • (sometimes also get, but list is the minimum)

Scope:

  • namespaced, because it says: in the namespace "analytics"

Required Role Type:

  • Role only (NOT ClusterRole)

Required Binding Type:

  • RoleBinding only.

Required ServiceAccount:

  • NOT default
  • Must use the newly created one → scout

🧪 Step-by-Step Solution

🔍 Universal Step — Extract Required Permissions From Logs

👉 This is the step you perform as soon as you inspect the logs.

As soon as you check the Pod logs, you will see one or more Forbidden errors:

Error from server (Forbidden): system:serviceaccount:<namespace>:<service-account>
cannot <verb> resource "<resource>" in API group "" in the namespace "<namespace>"

From this single log line, extract:

  1. Which ServiceAccount is actually used
  2. Which resources the Pod is trying to access
  3. Which verbs (list / get / watch / etc.)

  4. Whether the scope is namespace or cluster

  5. If log ends with: in the namespace "X" → Role needed

  6. If log ends with: at the cluster scope or uses -A internally → ClusterRole needed

🔎 Step 0 — Check Whether the SA Currently Has Those Permissions

Run:

kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa> -n <ns>

Example:

kubectl auth can-i list pods --as=system:serviceaccount:ops:default -n ops

You will get:

no

This confirms the RBAC issue.

⭐ The goal after fixing the RBAC is:

When you run the exact same command again:

kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa> -n <ns>

The answer must now be:

yes

This means your ServiceAccount + Role/RoleBinding (or ClusterRoleBinding) are correct.

Step 1 — Create the ServiceAccount

(They may give a YAML, or only key/values.)

kubectl create sa scout -n analytics

Step 2 — Inspect the three Roles provided

The exam provides three Role manifests inside a folder such as:

/opt/roles/
   ├── role1.yaml
   ├── role2.yaml
   └── role3.yaml

Below are the exact three roles, matching the type you saw in the exam.

🔹 role1.yaml — WRONG

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

❌ Why this Role is NOT correct

  • The Deployment logs clearly show it is trying to access pods, not events.
  • Even though verbs get and list are correct, the resource is completely wrong → events.

➡ Reject this Role immediately.

🔹 role2.yaml — CORRECT

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

✅ Why this Role IS correct

Matches the log error exactly:

  • Resource needed → pods
  • Verbs needed → list (and optionally get)
  • Scope → namespaced, and this Role is namespaced

➡ This is the Role you MUST apply.

🔹 role3.yaml — WRONG

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

❌ Why this Role is NOT correct

This is one of the most dangerous traps in CKAD & CKA:

  1. pods/log CANNOT appear alone Kubernetes RBAC rules require the main resource (pods) before its subresource (pods/log) is allowed.

  2. A valid subresource rule must look like:

resources:
- pods
- pods/log
  1. This Role does not allow listing pods, so the Deployment would still fail.

➡ Reject this Role. It is invalid for the scenario.

🧠 Summary Table (quick reference)

Role File Resources Verbs Valid? Reason
role1.yaml events get, list ❌ Wrong resource
role2.yaml pods get, list ✅ Matches log error exactly
role3.yaml pods/log get, list ❌ Subresource cannot exist alone

Step 3 — Apply ONLY the correct Role

kubectl apply -f /opt/roles/role2.yaml -n analytics

Step 4 — Create the RoleBinding

kubectl create rolebinding allow-pods \
  --role=role2 \
  --serviceaccount=analytics:scout \
  -n analytics

Important:

  • Must be RoleBinding
  • Must reference Role, not ClusterRole
  • Must reference correct SA: scout

Step 5 — Patch the Deployment to use the ServiceAccount

Option 1 (recommended):

kubectl set serviceaccount deploy/analytics-app scout -n analytics

Option 2:

kubectl edit deploy analytics-app -n analytics

Under .spec.template.spec.serviceAccountName: set:

serviceAccountName: scout

Step 6 — Restart Pods so the new SA takes effect

Two methods:

Method A — rollout restart

kubectl rollout restart deploy analytics-app -n analytics

Method B — delete pods by label

kubectl delete pod -l app=analytics-app -n analytics

Step 7 — Verify RBAC is fixed

kubectl logs deploy/analytics-app -n analytics --since=2m

You should see no more Forbidden errors.

📄 Final Answer (Minimal RBAC YAML)

Below are the correct objects.

Correct Role (role2.yaml)

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

RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-pods
  namespace: analytics
subjects:
- kind: ServiceAccount
  name: scout
  namespace: analytics
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

🎯 Summary (short and crisp)

  • Logs tell you exactly which resource & verb is missing.
  • “in namespace” → use Role + RoleBinding
  • Ignore Roles that have only pods/log
  • Create the ServiceAccount
  • Choose correct Role
  • Bind it
  • Patch Deployment
  • Restart pods
  • Verify logs → success.