L10. Container & Compute Hardening: ECS/EKS Security & Patch Manager

Two IAM Roles, One ECS Task

ECS tasks are governed by two distinct IAM roles that are easy to confuse and frequently tested. The task execution role is used by the ECS agent itself, for infrastructure-level work like pulling the container image from ECR and writing logs to CloudWatch. The task role is what the application code running inside the container assumes at runtime to call AWS APIs, such as reading from S3 or writing to DynamoDB. Least privilege means scoping the task role tightly to exactly what that one service needs, since it is the role your actual application code exercises against production data.

Pod-Level Least Privilege in EKS

On EC2-backed Kubernetes nodes, every pod scheduled on a node would, by default, inherit that node's IAM role, which is often broad enough to serve many different workloads. IAM Roles for Service Accounts (IRSA) breaks that inheritance by associating a specific Kubernetes service account with a specific IAM role. A pod that uses that service account assumes only the permissions of its associated role, not the node's role, giving each workload its own tightly scoped set of AWS permissions regardless of what else is running on the same node.

Scanning That Never Stops

Amazon ECR enhanced scanning, powered by Amazon Inspector, continuously rescans stored container images for OS package and programming-language package vulnerabilities as new CVEs are published, not only at the moment an image is pushed. A vulnerability disclosed six months after an image was pushed and deployed would be missed by a push-time-only scan; enhanced scanning keeps checking already-stored images against the latest vulnerability data so those gaps get surfaced.

Kubernetes-Native Guardrails

Two more Kubernetes controls come up on the exam alongside IRSA and image scanning:

Network policies act like security groups for pods, limiting which pods can talk to which. Pod Security Standards, enforced through admission controllers, prevent pods from running in privileged mode or reaching into the host's network namespace, both common paths to a container escape.

Patching the Fleet, Not Just the Image

For EC2-based workloads outside containers, AWS Systems Manager Patch Manager automates OS and application patching across a fleet using patch baselines (which define which patches are approved) and scheduled maintenance windows, removing the need to patch instances by hand one at a time. EC2 Image Builder complements this by automating the creation of hardened, pre-patched "golden" AMIs, so new instances launch already compliant instead of needing Patch Manager to catch them up after the fact. Exam tip: When a scenario says "a pod needs its own scoped permission, not the node's," the answer is IRSA. When it says "catch a CVE published after the image was already deployed," the answer is ECR enhanced scanning, not a one-time push scan.