Create a new ServiceAccount named backend-sa in the existing namespace default, which has the capability to list the pods inside the namespace default. Create a new Pod named backend-pod in the…

This simulation tests your ability to configure Kubernetes RBAC by creating a ServiceAccount, granting it least-privilege permissions via a Role and RoleBinding, mounting it into a Pod, and verifying access using kubectl from inside the running container.

Submitted by kim_seoul· May 5, 2026Minimize Microservice Vulnerabilities

Question

Create a new ServiceAccount named backend-sa in the existing namespace default, which has the capability to list the pods inside the namespace default. Create a new Pod named backend-pod in the namespace default, mount the newly created sa backend-sa to the pod, and Verify that the pod is able to list pods. Ensure that the Pod is running.

Explanation

Approach. Step 1 - Create the ServiceAccount: kubectl create serviceaccount backend-sa -n default. Step 2 - Create a Role that allows listing pods: kubectl create role pod-lister --verb=list --resource=pods -n default. Step 3 - Bind the Role to the SA: kubectl create rolebinding pod-lister-binding --role=pod-lister --serviceaccount=default:backend-sa -n default. Step 4 - Create the Pod with the SA mounted: kubectl run backend-pod --image=nginx --serviceaccount=backend-sa -n default (or write a YAML manifest with spec.serviceAccountName: backend-sa). Step 5 - Verify the pod is Running with kubectl get pod backend-pod -n default, then exec into it and run kubectl auth can-i list pods --as=system:serviceaccount:default:backend-sa or kubectl exec backend-pod -- curl -s --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/default/pods to confirm the token has list-pods access.

Concept tested. Kubernetes RBAC - ServiceAccounts, Roles, RoleBindings, and Pod identity. The scenario validates understanding that a ServiceAccount alone grants no permissions; a Role (namespaced) must define the allowed verbs/resources, and a RoleBinding must associate the Role to the ServiceAccount. The token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/ and used by in-cluster clients to authenticate to the API server.

Reference. https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions

Topics

#ServiceAccounts#RBAC#Least Privilege#Pod Security

Community Discussion

No community discussion yet for this question.

Full CKS Practice