K8s Service Accounts and Token Management

💡 Quick Answer: Configure service accounts, bound tokens, OIDC federation, and workload identity for Kubernetes. Migrate from legacy tokens to projected volumes.

The Problem

This is a critical skill for managing production Kubernetes clusters at scale. Without it, teams face operational complexity, security risks, and reliability issues.

The Solution

Modern Kubernetes issues short-lived, audience-bound tokens via projected volumes instead of long-lived Secret tokens. Mount a bound token that a pod presents to an external API:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  serviceAccountName: app-sa
  containers:
    - name: app
      image: myorg/app:1.0
      volumeMounts:
        - name: api-token
          mountPath: /var/run/secrets/tokens
  volumes:
    - name: api-token
      projected:
        sources:
          - serviceAccountToken:
              path: api-token
              expirationSeconds: 3600
              audience: vault

Create the service account and grant least-privilege RBAC:

kubectl create serviceaccount app-sa
kubectl create rolebinding app-sa-ro \
  --clusterrole=view --serviceaccount=default:app-sa

Avoid the legacy auto-generated Secret tokens; prefer TokenRequest/projected tokens and OIDC federation for cloud workload identity.

Common Issues

Troubleshooting

Check logs and events first. Most issues have clear error messages pointing to the root cause.

Best Practices

• Follow the principle of least privilege for all configurations
• Test in staging before applying to production
• Monitor and alert on key metrics
• Document your runbooks for the team

Key Takeaways

• Essential knowledge for Kubernetes operations at scale
• Start simple and evolve your approach as needed
• Automation reduces human error and operational toil
• Share learnings across your team