Question - 8

📌 Question (Exam Style)

A Deployment named mydeploy is running in namespace analytics. It is failing due to RBAC errors.

Look at the Pod logs and you will see messages similar to:

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

You are provided with:

A requirement to create a new ServiceAccount named panther in the namespace analytics.
Three Role manifest files located in:

/opt/roles/

Their contents differ in:

resources: (events, pods, pods/log)
verbs: (get, list)
No RoleBindings are provided — you must create one.
The question explicitly states:
“Do NOT modify any of the provided Role manifest files.”

🔧 Your tasks:

Create the ServiceAccount panther in the analytics namespace.
Inspect all three provided Roles and select the only Role that satisfies the Pod’s RBAC requirements.
Apply ONLY the correct Role file.
Create a new RoleBinding in the same namespace that:
Binds the selected Role
To the panther ServiceAccount
Update the Deployment scanner so that it uses the panther ServiceAccount.
Restart the Deployment so the new Pod picks up the new RBAC permissions.
Confirm that the logs no longer show Forbidden errors.

🔍 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:

Which ServiceAccount is actually used
Which resources the Pod is trying to access
Which verbs (list / get / watch / etc.)
Whether the scope is namespace or cluster
If log ends with: in the namespace "X" → Role needed
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.

1️⃣ Understand the Question

A Deployment is running inside a specific namespace. Its logs show RBAC failures:

Error from server (Forbidden): system:serviceaccount:<namespace>:<sa-name> 
cannot list resource "pods" in API group "" in the namespace "<namespace>"

This tells us:

The app is trying to list pods
The service account inside the pod does NOT have correct RBAC access
The scope is namespaced (because logs say in the namespace…)

We must fix it using:

One new ServiceAccount (given by question)
Three provided Role manifests (we must choose the correct one)
A new RoleBinding we must create

Goal: make the Deployment able to list pods successfully.

2️⃣ Step-by-Step Breakdown (Exam Strategy)

Step 1 — Create the ServiceAccount

If the question gives:

Create a ServiceAccount named panther in namespace analytics

Then:

kubectl create sa panther -n analytics

⭐ Step 2 — Inspect the three provided Roles

Inside /opt/roles/ the exam provides three Role manifests.

We must:

Read all of them
Identify which Role matches the RBAC error
Reject the invalid ones

Provided Role Manifests

role1.yaml — WRONG

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

❌ Wrong because:

Resource is events
Deployment needs access to pods

role2.yaml — CORRECT

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

✅ Correct because:

Resource = pods
Verbs = get, list
Scope is namespaced → matches error message

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"]

❌ Invalid Role because:

RBAC cannot allow pods/log alone
Must include pods as a resource:

Correct form would be:

resources:
- pods
- pods/log

Since the provided Role does not include pods, it can never satisfy the Deployment's error.

➡ Therefore: The ONLY correct Role is `role2.yaml`.

We apply it:

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

Step 3 — Create the RoleBinding

The RoleBinding needs:

Role: pod-reader
ServiceAccount: gorilla
Namespace: analytics

kubectl create rolebinding panther-rb \
  --role=pod-reader \
  --serviceaccount=analytics:panther \
  -n analytics

Step 4 — Patch the Deployment to Use This ServiceAccount

Two valid methods:

Method A — Imperative (Fastest for CKAD)

kubectl set serviceaccount deployment/mydeploy panther -n analytics

Method B — kubectl edit

kubectl edit deployment mydeploy -n analytics

Add under .spec.template.spec:

serviceAccountName: panther

Step 5 — Restart Pods so RBAC Takes Effect