ServiceAccounts are Kubernetes-native identities for workloads (Pods, Jobs, controllers). They provide the mechanism for Pods to authenticate with the API server and external services. Understanding how to create, assign, and secure them is fundamental for both CKA and CKS.

1. ServiceAccount Basics

# Create a ServiceAccount:
kubectl create serviceaccount app-sa -n production

# Or declaratively:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: production
  annotations:
    # AWS: associate with IAM role (IRSA):
    eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/app-role
    # GCP: Workload Identity:
    iam.gke.io/gcp-service-account: app@project.iam.gserviceaccount.com

The Default ServiceAccount

Every namespace automatically gets a default ServiceAccount. Every Pod without an explicit serviceAccountName uses it.

kubectl get sa -n default
# NAME      SECRETS   AGE
# default   0         30d

# Pod without explicit SA:
spec:
  # serviceAccountName: default  ← implicit (auto-assigned)

Assigning a ServiceAccount to a Pod

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  serviceAccountName: app-sa        # ← Explicit SA assignment
  containers:
    - name: app
      image: myapp:latest

# The Pod's identity becomes:
# user: system:serviceaccount:production:app-sa
# groups: [system:serviceaccounts, system:serviceaccounts:production]

# This identity is used for RBAC authorization

2. Token Projection (How Pods Get Tokens)

Since K8s 1.22, Pods receive bound projected tokens — short-lived JWTs mounted automatically:

# What kubelet mounts into every Pod:
/var/run/secrets/kubernetes.io/serviceaccount/
├── token        # ← Bound JWT (rotated every ~1h by kubelet)
├── ca.crt       # ← Cluster CA (to verify API server)
└── namespace    # ← Pod's namespace (text file)

Token Properties

Custom Token Projection

# Request a token with custom audience and expiry:
spec:
  containers:
    - name: app
      volumeMounts:
        - name: vault-token
          mountPath: /var/run/secrets/vault
  volumes:
    - name: vault-token
      projected:
        sources:
          - serviceAccountToken:
              path: token
              expirationSeconds: 7200       # 2 hours
              audience: vault               # Custom audience (for Vault auth)

Verifying Token Content

# Read the token inside a Pod:
kubectl exec web -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Decode the JWT (it's base64-encoded sections):
kubectl exec web -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | \
  cut -d'.' -f2 | base64 -d 2>/dev/null | jq .
# {
#   "aud": ["https://kubernetes.default.svc"],
#   "exp": 1705334400,
#   "sub": "system:serviceaccount:production:app-sa",
#   "kubernetes.io": {
#     "pod": {"name": "web", "uid": "..."},
#     "serviceaccount": {"name": "app-sa"}
#   }
# }

3. Disabling Auto-Mount

Most Pods don't need to talk to the Kubernetes API. Mounting a token unnecessarily increases the attack surface — a compromised Pod gains API access for free.

Disable at the Pod Level

spec:
  automountServiceAccountToken: false    # No token mounted into this Pod
  containers:
    - name: app
      image: myapp:latest
# Result: /var/run/secrets/kubernetes.io/serviceaccount/ doesn't exist

Disable at the ServiceAccount Level

apiVersion: v1
kind: ServiceAccount
metadata:
  name: no-api-access
automountServiceAccountToken: false     # No Pod using this SA gets a token
# Unless the Pod explicitly overrides with automountServiceAccountToken: true

Priority

4. Security Best Practices

Cloud Workload Identity

# AWS IRSA (IAM Roles for Service Accounts):
# Annotate SA → Pod gets AWS credentials via projected token
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/s3-reader
# Pod can assume the IAM role using its SA token — no AWS keys in cluster!

# GCP Workload Identity:
metadata:
  annotations:
    iam.gke.io/gcp-service-account: reader@project.iam.gserviceaccount.com
# Pod authenticates to GCP APIs using its SA token

Summary