EKS Workload Security

1. EKS Pod Identity: The Modern Key to AWS

Your application often needs to talk to other AWS services—maybe to upload a photo to S3 or read a secret from Secrets Manager.

• The Dangerous Way: Giving the Worker Node a massive IAM Role. This means every Pod on that node can do anything. If a hacker breaks into one tiny Pod, they have the keys to your entire AWS account.
• The Modern Way (EKS Pod Identity): This is the 2026 standard. It allows you to link a specific AWS IAM Role to a specific Kubernetes ServiceAccount. Only the Pod using that ServiceAccount gets the permissions. It’s like giving a specific key to a specific person instead of leaving the front door unlocked for everyone.

2. Pod Security Admissions (PSA): The Cluster Guardrails

How do you prevent a developer from running a container as “Root” or a container that can see the host’s hard drive? We use Pod Security Admissions.

PSA is built into Kubernetes and works at the Namespace level. It has three levels:

• Privileged: Unrestricted. Usually only for system tools (like Networking or Logging).
• Baseline: Prevents the most obvious security holes (like sharing the host network).
• Restricted: The gold standard for DevSecOps. It forces the container to run as a non-root user and strips away all dangerous “Linux capabilities.”

3. Comparison: The Evolution of Security

Feature	The Old Way (Pre-2024)	The Modern Way (2026)
AWS Access	IRSA (Complex OIDC Setup)	EKS Pod Identity (Simple Mapping)
Pod Hardening	Pod Security Policies (PSP)	Pod Security Admissions (PSA)
IAM Management	Manual Trust Policies	EKS Add-on managed automation

Supply Chain & Runtime Security

1. Supply Chain Security: Image Signing with Sigstore (Cosign) How does your Kubernetes cluster know that the nginx:latest image it just downloaded was actually created by your team and not a hacker?

• The Solution: Cryptographic Signing. When your CI/CD pipeline builds a Docker image, it uses a tool called Cosign (part of the Sigstore project) to “sign” the image.
• The 2026 Standard (Keyless Signing): Managing private encryption keys is a nightmare. Cosign now uses “Keyless Signing” backed by OIDC (OpenID Connect) and transparency logs. Your pipeline signs the image using a temporary identity, leaving an immutable, tamper-proof record that proves the image is authentic.

2. Policy-as-Code: The Admission Controllers Signing an image doesn’t help if your cluster doesn’t bother to check the signature! We need an “Admission Controller” to act as a bouncer at the Kubernetes API door. Instead of writing complex custom webhooks, the industry uses Policy-as-Code engines:

• Kyverno: The favorite for Kubernetes-native teams. Policies are written in standard YAML. It can validate, mutate, and generate resources automatically.
• OPA Gatekeeper: The general-purpose giant. Policies are written in a specialized language called Rego. It is incredibly powerful and used if your company wants to share the exact same policy language across Kubernetes, Terraform, and microservices.

3. eBPF Security: Cilium and Tetragon If an attacker bypasses the supply chain (e.g., they find a zero-day vulnerability in your legitimate, signed application), they will usually try to run a shell command (like /bin/bash or curl) from inside your running container to steal data.

• The Old Way: Running clunky security sidecars in every Pod that scanned files and killed CPU performance.
• The 2026 Standard (eBPF): We use Cilium Tetragon. eBPF is a technology that allows us to run security programs directly inside the Linux Kernel of the Worker Node safely. Tetragon monitors every single system call (like execve for running commands). If a web server suddenly tries to execute a bash shell, Tetragon blocks the kernel from executing it synchronously (in real-time), killing the hacker’s process before it even starts.