Why Short‑Lived Tokens Are the Key to True Kubernetes Security

Core Concepts

1. ServiceAccount

Definition: A ServiceAccount is an identity for processes running inside a Pod, represented as a user in the API Server authentication system.

In the API Server it appears as

system:serviceaccount:<namespace>:<serviceaccount-name>

. Example: system:serviceaccount:default:demo-sa Typical manifest:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-sa
  namespace: default
secrets:
  - name: demo-sa-token-xyz12

Namespace‑scoped resource

Each namespace has a default default ServiceAccount

Represents the Pod’s "user identity" in the Kubernetes API

Naturally binds to RBAC permissions

2. Token

A Token is the ServiceAccount’s "ID card" and is a JWT.

Long‑lived Token : stored in a Secret (traditional, less secure)

Short‑lived Token : dynamically generated via the TokenRequest API (recommended)

Traditional Secret example:

apiVersion: v1
kind: Secret
metadata:
  name: demo-token
  annotations:
    kubernetes.io/service-account.name: demo-sa
type: kubernetes.io/service-account-token
data:
  ca.crt: ...
  namespace: ...
  token: ...

Identity Authentication Flow

1. Token Injection at Pod Creation (recommended)

Pod spec that requests a projected ServiceAccount token:

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  serviceAccountName: demo-sa
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: kube-api-access
      mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      readOnly: true
  volumes:
  - name: kube-api-access
    projected:
      sources:
      - serviceAccountToken:
          path: token
          expirationSeconds: 3600

Inside the Pod the following files are automatically mounted:

/var/run/secrets/kubernetes.io/serviceaccount/
├── ca.crt
├── namespace
└── token

2. API Server Authentication & Authorization (illustrated)

Token Evolution History

K8s ≤1.21: automatically creates ServiceAccount Token Secret.

K8s 1.22: default disables automatic Secret creation.

K8s 1.24+: strongly recommends using short‑lived TokenRequest tokens.

Conclusion: Secret‑based tokens are legacy; new clusters should use short‑lived tokens exclusively.

Three Core Advantages of Short‑Lived Tokens

1. Automatic Rotation

Kubelet refreshes the token file before expiration:

Kubelet → TokenRequest API → updates token file → Pod sees no change

2. Short Lifespan

Reduces attack window dramatically.

Long‑lived Token: permanent, high leakage risk.

Short‑lived Token: expires within a few hours, low risk.

3. Audience Mechanism (prevents misuse)

Specify an audience in the projected token:

serviceAccountToken:
  audience: api

Resulting JWT contains "aud": ["api"], meaning only services that accept audience api can use the token.

Kubernetes API → audience api Custom system → audience my-service Cloud IAM → audience sts.amazonaws.com This isolates token usage to intended services.

RBAC Integration with ServiceAccount

# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-sa

# Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: pod-reader-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Security tip: Granting resources: ["*"] and verbs: ["*"] creates a dangerous RBAC configuration.

Why Not Use the Default ServiceAccount

Uncontrolled permissions : often bound to high‑privilege roles by mistake.

Difficult to audit : cannot distinguish workloads.

Increased attack surface : a compromised Pod can access the API server.

Standard practice: create a dedicated ServiceAccount and reference it in the Pod spec:

spec:
  serviceAccountName: myapp-sa

Attack‑Perspective Security Model

If an attacker gains pod access:

1. Exploit vulnerability to enter Pod
2. Read the token file
3. Call the Kubernetes API
4. Enumerate resources, privilege‑escalate, lateral move

Defensive layers:

Identity: short‑lived token + audience

Permissions: least‑privilege RBAC

Network: NetworkPolicy

Audit: API Audit Log

Alerting: anomalous token usage detection

Cloud‑Provider Pod Identity Solutions (no longer using AK/SK)

AWS → IRSA

Alibaba Cloud → RRSA

GCP → Workload Identity

Tencent Cloud → Pod Identity

Unified model:

Pod → ServiceAccount → Cloud IAM Role → Cloud Resources

Overall Component Mapping

ServiceAccount – identity

Token – ID card

RBAC – law

NetworkPolicy – border defense

Audit Log – surveillance camera

Final takeaway: Kubernetes security is not about merely having a token; it hinges on using short‑lived, audience‑restricted tokens, enforcing minimal RBAC, and ensuring full auditability.