RBAC & Security
Service Accounts — Identity for Pods
Authorizing applications inside pods to interact with the API Server.
Introduction
While standard Kubernetes users represent human actors authenticating with external certificate authorities or LDAP services, applications running inside pods need an identity to authenticate with the internal Kubernetes API Server.
Service Accounts provide this machine identity. They are namespaced resources managed directly by the Kubernetes control plane. When a pod is assigned a ServiceAccount, the API Server generates a token that the pod container uses to authenticate API requests.
Why It Matters
By default, if you do not specify a ServiceAccount, Kubernetes assigns the default ServiceAccount of the namespace to the pod, and automounts its authentication token. If the pod runs a public-facing application that gets compromised, an attacker can steal this token. If the default service account has cluster access permissions, the compromise can spread node-wide.
Real-World Analogy
Think of a ServiceAccount like **a valet key or a restricted database API token**. Instead of giving a valet driver your house keys, master security passcode, and passport (admin certificates), you hand them a valet key that only unlocks the driver's door and starts the engine. If someone steals the valet key, they cannot enter your house or access your safe (isolated credentials boundary).
How It Works
When a pod configuration declares a ServiceAccount, the API Server processes it during scheduling. The token controller generates a JWT token bound to that specific pod. The kubelet mounts the token as a projected volume into the container filesystem at start. Whenever the container code makes API requests using client SDKs, the SDK automatically loads the token header, authenticating with the API Server.
Internal Architecture
Modern Kubernetes clusters utilize the TokenRequest API instead of static secrets. The token has:
- Expiration: The token automatically expires and rotates (default is 1 hour).
- Audience Restriction: The token target is matched specifically to the API Server.
- Projected Mounts: Projected volumes mount the token directory on a temporary node storage layer (tmpfs), ensuring the JWT is never written to node disk.
Visual Explanation
Practical Example
Here is how to create a custom ServiceAccount that does not automount its token by default, and a Pod manifest that uses it:
1. Declarative ServiceAccount (serviceaccount.yaml)
2. Declarative Pod Spec using the ServiceAccount (pod.yaml)
Common Mistakes
- Broad Default Access: Binding broad RBAC policies to the
defaultservice account. - Unused Token Mounting: Leaving automount active on backend API containers that do not need to call the control plane.
- Shared Accounts: Sharing a single ServiceAccount across different systems, which complicates security audits.
Quick Quiz
Q1: What is the security recommendation for pods that do not need to call the Kubernetes API Server?
A) Delete the default namespace entirely.
B) Set automountServiceAccountToken: false on the Pod or ServiceAccount specification to avoid exposing unused credentials inside the container.
C) Route pod network traffic through a public VPN.
D) Run the pod container as privileged root.
Answer: B — If an application (like a frontend UI or caching database) has no business calling the Kubernetes API, automounting should be disabled. Exposing unnecessary tokens increases the container's threat profile.
Q2: Where are mounted ServiceAccount tokens stored inside the container filesystem by default?
A) /var/run/secrets/kubernetes.io/serviceaccount/
B) /etc/kubernetes/admin.conf
C) /root/.kube/config
D) /tmp/tokens/
Answer: A — The kubelet automatically mounts the namespace, CA certificate, and the token file to this path within the container filesystem, enabling client SDKs to find them automatically.
Scenario-Based Challenge
Production Scenario:
A third-party monitoring pod requires access to read namespace resource quotas. You configured a ServiceAccount named monitor-sa for the pod, but it continues to fail with 403 Unauthorized when calling the API Server. What steps are required to establish authentication?
A ServiceAccount has no permissions of its own when created. You must link it using a RoleBinding:
1. Verify the pod's serviceAccountName matches monitor-sa.
2. Create a ClusterRole (or Role if restricted to one namespace) granting read verbs on quotas:
3. Create a
RoleBinding in the target namespace linking the ServiceAccount to the ClusterRole:
Debugging Exercise
Broken Configuration:
Your backup container attempts to dump databases, but the logs show permission denied when trying to get endpoints. The Pod is configured without declaring a serviceAccountName:
Reason: Because no serviceAccountName is specified, the pod uses the default ServiceAccount inside data-ns, which has no API access rules.
The Fix: Create a ServiceAccount named backup-sa, bind it to a Role granting endpoint access, and reference it in the pod:
Interview Questions
1. Conceptual: How does Pod Identity (like AWS IRSA or GCP Workload Identity) improve ServiceAccount security?
Cloud Pod Identity allows a Kubernetes ServiceAccount to assume an IAM Role in the cloud provider. Instead of hosting long-lived static AWS/GCP access keys inside Kubernetes Secrets, the pod uses its local OIDC ServiceAccount token to negotiate short-lived cloud keys directly with the cloud metadata API.
2. Technical: How do you manually request a temporary ServiceAccount token using kubectl?
Use the kubectl create token command followed by the service account name: kubectl create token my-service-account --duration=1h -n production. This generates a temporary JWT token without creating a persistent Secret resource.
Production Considerations
Keep ServiceAccounts dedicated to specific applications. Do not share a single ServiceAccount across multiple distinct deployments (e.g. database operator and backend API). Sharing accounts violates least-privilege principles and makes audit logs difficult to trace.