CKS ServiceAccount hardening — with EKS Pod Identity associations

CKS Cluster Hardening still wants automount off and short-lived tokens. On EKS, the same ServiceAccount can bind AWS IAM through an association instead of an IRSA annotation.

<!-- hal:authoritative:yaml -->

CKS Cluster Hardening still wants automount off and short-lived tokens. On EKS, the same ServiceAccount can bind AWS IAM through an association instead of an IRSA annotation.

§I — Frame

CKS blueprint weight for Cluster Hardening is about 15%. Kubestronaut opens Service Accounts with three moves: disable default automount, minimize permissions, issue tokens deliberately. Bootcamp question 03 drills automount false plus an explicit token path. Bootcamp question 30 drills projected serviceAccountToken with expirationSeconds and audience.

Kubernetes Up and Running, Chapter 14, Service Account Management, is the conceptual spine: the ServiceAccount is how the Pod authenticates to the API server.

Today's Ops lesson adds the cloud medium update after 09-06 IRSA: EKS Pod Identity associations bind IAM to namespace + ServiceAccount without eks.amazonaws.com/role-arn. CKS does not grade AWS console clicks. The transferable instinct is one dedicated ServiceAccount, no default SA for app Pods, no lasting token unless asked, and cloud IAM least privilege on a separate trust document.

§II — Objective map

§III — Q03 / Q30 drill pattern (exam core)

1. Create a dedicated ServiceAccount (never reuse default for the app).
2. Set automountServiceAccountToken: false on the SA (and confirm Pod does not override to true carelessly).
3. For Q30-style stems: add a projected volume:

volumes:
- name: api-token
  projected:
    sources:
    - serviceAccountToken:
        path: token
        expirationSeconds: 3600
        audience: api

1. Mount only where the process needs the API. Confirm no auto-mounted secret under /var/run/secrets/kubernetes.io/serviceaccount when automount is false (unless you mounted deliberately).
2. RBAC: bind a Role with the verbs the stem requires. Watch for ClusterRole overreach.

PSA (09-12) and Gateway (09-18) do not satisfy these stems.

§IV — EKS Pod Identity adjacency (not an exam click path)

On a real EKS cluster paired with Ops:

• Association keys: cluster + namespace + ServiceAccount name + role ARN.
• No requirement for eks.amazonaws.com/role-arn on the SA.
• Trust principal is pods.eks.amazonaws.com, not the cluster OIDC Federated principal.
• CKS still cares that the SA is dedicated and tokens are deliberate. Pod Identity does not replace automount hygiene.

Compare to 09-06: IRSA put the role ARN in an annotation and trusted the OIDC issuer. Same SA shelf, different bind object.

§V — Exam discriminators

• default ServiceAccount for app Pods is a Cluster Hardening smell.
• Automount false without a projected (or explicit) token breaks in-cluster clients that need the API. Read the stem.
• Audience typos on projected tokens fail auth to the intended audience.
• NetworkPolicy or PSA answers fail a ServiceAccount token stem.
• Writing an IRSA annotation does not answer a projected-token stem; writing Pod Identity AWS CLI does not either. Stay on the Kubernetes object the question names.

§VI — Practice cards

§VII — Closing

Harden the ServiceAccount on the Kubernetes side first (automount, projected tokens, RBAC). On EKS, prefer one IAM bind style per SA. Pod Identity associations are the Ops update to the 09-06 IRSA story, not a substitute for CKS token discipline.

Related

• CKS projected tokens + IRSA (09-06)
• Ops: Pod Identity versus IRSA