Skip to main content

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 AccessIRSA (Complex OIDC Setup)EKS Pod Identity (Simple Mapping)Pod HardeningPod Security Policies (PSP)Pod Security Admissions (PSA)IAM ManagementManual Trust PoliciesEKS 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.