How do pods authenticate to the Kubernetes API, and what is a ServiceAccount?
Quick Answer
Pods authenticate using a ServiceAccount — an in-cluster identity. Kubernetes mounts a short-lived, audience-scoped token (projected) into the pod, which it presents to the API server; RBAC then decides what that ServiceAccount may do.
Detailed Answer
Every pod runs as a ServiceAccount (the namespace 'default' one if unspecified). Modern clusters use bound, projected ServiceAccount tokens: the kubelet mounts a short-lived JWT (auto-rotated, scoped to an audience and the pod's lifetime) at a well-known path, replacing the old model of long-lived Secret-based tokens. When the app calls the API, it presents this token; the API server validates it and maps it to the ServiceAccount identity, then RBAC authorizes the request. Best practices: give each workload its own ServiceAccount with a minimal Role (never reuse 'default' for privileged access), set automountServiceAccountToken: false for pods that don't call the API, and use the token's audience feature (or IRSA/Workload Identity on cloud) to federate into cloud IAM without static credentials.
Code Example
kubectl create serviceaccount deployer -n ci # in the pod spec: spec: serviceAccountName: deployer automountServiceAccountToken: true # false if the app never calls the API # token is projected at /var/run/secrets/kubernetes.io/serviceaccount/token
Interview Tip
Mention that tokens are now short-lived *projected* tokens (not long-lived Secrets) and that cloud Workload Identity/IRSA lets pods assume cloud IAM roles without static keys — that's current, security-aware knowledge.