A Deployment’s Pod template sets serviceAccountName: permits-api. Controllers create and manage those Pods, but live API calls from inside a running Pod use that ServiceAccount’s token. When debugging Forbidden errors from the application process, which identity matters most?
Select an answer to reveal the explanation.
Short Explanation
Whoever clicked apply is not who the app is when it talks to the API. The Pod wears the ServiceAccount badge in its template. Check that SA’s RoleBindings when the process itself gets Forbidden.
Full Explanation
A Deployment Pod template with serviceAccountName permits-api causes controllers to create Pods that mount that ServiceAccount's token for in-Pod API access. When debugging Forbidden errors from the application process itself, the identity that matters most is the permits-api ServiceAccount inside the Pod—not the human kubectl user who applied the Deployment. Municipal API RBAC must bind Roles to the runtime ServiceAccount for the resources the process actually calls.
Focusing only on the cluster-admin user in the kubeconfig used to create the Deployment fails because that user is not presented on the application's API client calls. Assuming the default ServiceAccount in kube-system is inherited by all app Pods fails—Pods use a ServiceAccount in their own namespace, default or named. Believing the Node's kubelet client certificate proxies every in-Pod HTTPS call fails: applications send the projected ServiceAccount bearer token to the apiserver.
Exam caveat: if automountServiceAccountToken is false, missing-token errors can look like auth problems unrelated to RoleBindings. Operational check: read the Pod's serviceAccountName, list RoleBindings for permits-api, grant least-privilege verbs the app needs, restart or retry the calls, and confirm Forbidden clears for the process identity.