Container Security

Container Security covers the practices for securing containers across their lifecycle, from building images to running them in production on ECS, EKS, or Fargate.

Image Security

• ECR Image Scanning: basic scanning uses AWS native technology against the CVE database for OS vulnerabilities; enhanced scanning integrates Amazon Inspector for continuous scanning of both OS and programming language packages
• Minimal Base Images: use distroless or Alpine to reduce attack surface
• Immutable Tags: enable tag immutability in ECR to prevent image tampering
• Image Signing: use Sigstore/Cosign or AWS Signer for container image provenance

Runtime Security

• Non-root Users: run containers as non-root; ECS supports user in task definition
• Read-only Root Filesystem: prevent runtime modifications to the container filesystem
• Fargate: AWS manages the underlying host, reducing OS-level attack surface
• EKS Pod Security Standards: enforce baseline or restricted policies at the namespace level

Network & Access

• Use awsvpc network mode on ECS for per-task security groups
• Kubernetes Network Policies on EKS to restrict pod-to-pod traffic
• Task/pod IAM roles for fine-grained AWS access (not the node role)

How It Goes Wrong in Practice

The container-specific failure that turns an application bug into an AWS account problem is credential inheritance through the node. On EC2-backed ECS and EKS clusters, every container shares the host's network path to the instance metadata service. If nothing blocks that path, a compromised container, one shell injection or SSRF away, can request the node's instance role credentials from the metadata endpoint. The node role is typically far more powerful than any single workload needs: it can pull every image in the registry, write logs, join the cluster, and often much more, so the attacker escapes the container's intended blast radius without any kernel exploit at all. The whole per-workload identity model (task roles on ECS, IRSA or Pod Identity on EKS) only delivers isolation if pods are also prevented from reaching the node's metadata credentials, via metadata hop limits, network policy, or per-task restrictions. The second recurring failure is the mutable tag: deployments pin to a tag like latest or prod, someone (or something) pushes a different image under the same tag, and what runs in production no longer matches what was reviewed and scanned; ECR tag immutability exists to make that class of swap impossible. The third is scan theater: scan-on-push is enabled, findings accumulate, and nothing gates deployment on the results, so critically vulnerable images ship on schedule. A scan that cannot fail a pipeline is documentation, not a control.

Practical Check: Read Your Scan Findings

Pull the findings for the image you are about to deploy:

aws ecr describe-image-scan-findings --repository-name my-app --image-id imageTag=1.4.2

You can also address the image by digest with imageDigest=sha256:..., which is the right habit once tag immutability or signing is in play. Note that current ECR basic scanning returns results through this DescribeImageScanFindings API rather than through the scan summary attributes on DescribeImages, so this command is the reliable path for automation. Wire it into your pipeline: fetch findings after push, fail the build above your severity threshold, and route exceptions through an explicit allowlist with expiry dates.

Frequently Asked Questions

What is the difference between ECR basic and enhanced scanning?
Basic scanning uses AWS native technology with the CVE database, covers operating system packages, and runs on push or on demand. Enhanced scanning hands the job to Amazon Inspector, which scans both OS and programming language packages, rescans continuously as new CVEs are published, and emits EventBridge events when findings change. If your dependencies live in npm, pip, or Maven rather than apt, basic scanning is not seeing most of your real attack surface. One operational caveat: switching between scanning types makes previously established scan results unavailable until you scan again.

Does Fargate make container security AWS's problem?
It moves the host OS, kernel patching, and infrastructure isolation to AWS's side of the shared responsibility model, which removes a real class of risk. Everything inside the task definition remains yours: the image and its vulnerabilities, the task role's permissions, secrets handling, and network exposure. Fargate shrinks the problem; it does not delete it.

Why do task and pod roles matter so much?
Because they are the container equivalent of least privilege. A task or pod role scopes AWS permissions to one workload, so a compromise is bounded by what that workload legitimately needs. Relying on the node role instead gives every container on the host the union of all permissions, which is exactly the blast radius amplification the metadata attack above exploits.