Kubernetes · Orchestration under pressure
What is a ServiceAccount and how should pods use one?
Short answer
A ServiceAccount provides an identity for pods to authenticate to the API server and external systems. Use a dedicated account per workload with minimal permissions and avoid auto-mounting tokens when unnecessary.
Every pod runs as a ServiceAccount, defaulting to the namespace's default account. Kubernetes projects a short-lived bound token into the pod, and the API server authorizes requests based on RBAC granted to that account. Cloud providers also use service account identity for workload identity federation.
- Create one ServiceAccount per workload rather than sharing default
- Set automountServiceAccountToken: false when the pod does not call the API
- Bind minimal Roles to the account, not cluster-admin
- Use workload identity or IRSA for cloud API access instead of static keys
- Rotate and scope tokens; projected tokens expire automatically
apiVersion: v1
kind: ServiceAccount
metadata:
name: report-job
namespace: production
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
name: report
spec:
serviceAccountName: report-job
automountServiceAccountToken: false
containers:
- name: report
image: registry.example.com/report:1.3.0The default ServiceAccount is a common security gap because every pod can inherit it and any RBAC granted to it applies broadly. Treat identity as part of the workload design: name it, scope it and remove API access the workload does not need.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What identity does a pod use to call the API server?
- 2Why should you disable token automounting?
- 3How does cloud workload identity differ from static keys?
- 4What permissions would a deployment controller need?
Say it in the interview
A ServiceAccount is the identity a pod uses for API authentication. Kubernetes projects a short-lived token, and RBAC decides what that identity can do. I create one account per workload, disable automounting when it is not needed, and grant minimal permissions. For cloud access I prefer workload identity over long-lived static keys because it removes a credential from the pod.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.