ServiceAccounts: The Identity Card of the Pod

If you want a human to log into the cluster, you give them a certificate or an OIDC login. But what if your FastAPI code needs to talk to the cluster? What if your AI agent needs to list nodes or update its own configuration?

A pod cannot "Log in" with a username and password. Instead, it uses a ServiceAccount.

A ServiceAccount is a non-human identity that lives inside a namespace. When you assign a ServiceAccount to a pod, Kubernetes automatically injects a JWT Token into the pod's filesystem. Your code can then read this token and use it to authenticate with the API Server.

In this lesson, we will master the ServiceAccount Lifecycle, learn to control Automounting for better security, and understand the "Holy Grail" of cloud security: IAM Roles for Service Accounts (IRSA).

1. Users vs. ServiceAccounts

Users (Humans): Managed by external systems (Google, AWS, Azure, Keystone). Kubernetes doesn't store User objects itself.
ServiceAccounts (Machines): Managed entirely by the Kubernetes API. They are namespaced resources like Pods or ConfigMaps.

2. How the Token is Delivered

When a pod starts with a ServiceAccount, the Kubelet does three things:

Creates a Volume of type projected (Module 6.1).
Requests a time-limited JWT Token from the API Server.
Mounts that token at: /var/run/secrets/kubernetes.io/serviceaccount/token.

Your application's Kubernetes client library (like kubernetes-python) is pre-programmed to look in this exact folder. It picks up the token and includes it in the Authorization: Bearer <token> header of every API call.

3. The Security Trap: automountServiceAccountToken

By default, every pod you create is assigned the default service account of that namespace, and the token is automatically mounted.

The Risk:

If a hacker compromises your Next.js frontend, and that pod doesn't actually need to talk to the Kubernetes API, you have just given the hacker a valid credential for your cluster.

The Solution:

If your pod doesn't need to talk to the API, turn it off!

spec:
  automountServiceAccountToken: false # THE SECURITY BUTTON

4. Visualizing the Identity Injection

graph TD
    API["K8s API Server"] -- "Issue Token" --> K["Kubelet"]
    SA["ServiceAccount: ai-agent"] -- "Assigned To" --> Pod["AI Pod"]
    
    subgraph "Inside the Pod"
        Pod -- "Reads" --> V["Volume: /var/run/secrets/..."]
        V -- "Contains" --> T["JWT Token (Identity)"]
    end
    
    T -- "Authenticate" --> API

5. IAM Roles for Service Accounts (IRSA)

This is the most powerful security pattern in modern cloud computing.

The Problem: Secret Keys

In the old days, if your AI pod needed to talk to AWS Bedrock, you had to store persistent AWS Access Keys in a Kubernetes Secret. If those leaked, your entire AWS account was at risk.

The IRSA Solution:

You "Link" a Kubernetes ServiceAccount to an AWS IAM Role.

Your pod assumes the ServiceAccount identity.
AWS sees the pod and says: "I trust this Kubernetes ServiceAccount. I will give it temporary, 15-minute AWS credentials."
Your pod gets the AWS credentials without you ever touching a secret key.

6. Practical Example: Creating a Restricted SA

# 1. Create the identity
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ai-operator
  namespace: production

---
# 2. Use it in a pod
spec:
  serviceAccountName: ai-operator
  containers:
  - name: my-app
    image: my-app:latest

7. AI Implementation: Secure Multi-Tenant Agents

If you are building an "AI Platform" where different users can upload their own LangChain agents, you must protect your infrastructure.

Unique SA per User: Create a separate ServiceAccount for "User A" and "User B."
Explicit RBAC: For "User A's" SA, only give permission to read "User A's" specific secrets.
Isolation: By using different ServiceAccounts, you ensure that "User A's" agent cannot "Reach across the aisle" and steal "User B's" data, even if they are running on the same physical server.

8. Summary and Key Takeaways

ServiceAccount: The machine identity for apps.
Token Mount: Automated delivery of JWTs to the pod filesystem.
automountServiceAccountToken: Disable it by default to reduce the attack surface.
IRSA: The best practice for connecting K8s to Cloud services (AWS/GCP/Azure).
Pod Identity: Every pod should have a dedicated ServiceAccount, never share the "default."

In the next lesson, we will look at how we enforce security at the container level using Pod Security Standards.

9. SEO Metadata & Keywords

Focus Keywords: Kubernetes ServiceAccount tutorial, service account token mount location, disable automountServiceAccountToken k8s, IAM Roles for Service Accounts explained IRSA, K8s pod identity management, securing AWS Bedrock keys in Kubernetes.

Meta Description: Learn how to provide identities to your applications in Kubernetes. Master ServiceAccounts and tokens, understand the risks of default credentials, and discover how to securely link your AI agents to cloud providers using IAM integration.