Library consortium apps currently share one ServiceAccount; ops wants each app to carry its own identity for RBAC. What should they do?
Select an answer to reveal the explanation.
Short Explanation
Shared badges blur who did what—give each library app its own ServiceAccount and point the Pod at it. That identity is what RBAC binds to, not the person who ran kubectl. Separate accounts make least-privilege bindings actually stick.
Full Explanation
Library consortium apps that share one ServiceAccount blur accountability and force one oversized Role onto every workload. Ops should create a dedicated ServiceAccount per application and set spec.serviceAccountName on each Deployment or Pod so the runtime identity matches the app. RBAC then binds narrowly to each ServiceAccount—the civic equivalent of issuing separate staff badges instead of one shared lanyard for the whole consortium. Mapping Pods to the human deployer’s kubeconfig user via an annotation does not change Pod authentication; the API still sees the ServiceAccount token, not the person who ran kubectl apply. Reusing the default ServiceAccount while widening a ClusterRole until everything works concentrates privilege and undoes least privilege. Disabling ServiceAccounts and relying on node SSH keys for in-cluster API calls abandons the Kubernetes identity model and is not a supported substitute for RBAC-bound ServiceAccounts. Exam caveat: Pods authenticate as their ServiceAccount (default if unset); human users and Pod identities are separate subjects. Operational check: create per-app ServiceAccounts, update serviceAccountName, apply RoleBindings to those accounts only, and confirm each Pod’s projected token maps to the intended account with kubectl get pod -o yaml and auth can-i checks as that ServiceAccount.