Module 4

Identity and security

A Pod that calls S3 or DynamoDB needs AWS credentials. The secure answer is short-lived, scoped credentials delivered by the platform, plus hardening at every layer.

Why it matters. Credential leaks and over-broad node roles are the most common EKS security failures. Workload identity removes the largest class of them.

After this module you can answer

How does a Pod get AWS credentials without secrets?
Pod Identity or IRSA, and how do I migrate?
Where should secrets live, and how are they encrypted?
Which logs and detections should be on from day one?
How do I control what images and Pods are allowed?

What is inside

1EKS Pod Identity

2Pod Identity versus IRSA

3Secrets and encryption

4Hardening checklist

5Logs and detection

6Images and admission

7Module infographic

Identity and security: no long-lived keys, layered defences

Module 4 starts with the most valuable control on EKS: workload identity. Before it existed, teams either gave every Pod the node's IAM role (too broad) or stored access keys in Secrets (leakable). Pod Identity and its predecessor IRSA let a specific ServiceAccount assume a specific IAM role, with temporary credentials.

Then we look at secrets, a hardening checklist across node, cluster, workload and network layers, the logging and detection you should enable on day one, and the supply-chain controls for images. Deck 5 returns to Kubernetes-native security (RBAC depth, Pod Security, Falco) across all platforms; this module is the AWS-specific layer.

Shopwave's rule: no long-lived AWS keys anywhere in the cluster, ever, and every namespace has its own ServiceAccounts and roles.