Introduction

Container security does not begin when a container starts running. It begins when an image is built, continues while that image is stored and deployed, and remains important throughout the life of the running workload.

AWS provides several services and controls for these different stages. Amazon Elastic Container Registry (Amazon ECR) protects stored images. Amazon Inspector detects known software vulnerabilities in eligible ECR images. AWS Signer helps establish image authenticity. Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS) provide identity, network, secret management, and workload controls. Amazon GuardDuty monitors supported running workloads for suspicious behavior.

These features work together, but they perform different jobs. An image scanner cannot detect every attack against a running container, and runtime monitoring cannot make an unsafe image trustworthy. A secure design therefore needs multiple layers.

Start with the AWS shared-responsibility model

AWS secures the infrastructure that operates services such as ECR, ECS, and EKS. The customer remains responsible for configuring access, choosing and maintaining images, patching software, protecting secrets, restricting networks, and monitoring workloads appropriately.

The exact division changes with the service. For example, AWS manages the EKS control plane, while the customer remains responsible for the worker nodes, Pods, container images, workload permissions, and most network configuration. On ECS with Fargate, AWS manages more of the underlying compute infrastructure, but the customer still controls the task definition, application image, IAM roles, secrets, and network rules.

This distinction matters because enabling one AWS security product does not transfer responsibility for the entire container environment to AWS.

1. Protect images stored in Amazon ECR

Amazon ECR is AWS's managed container registry. It stores container images and related artifacts, but secure storage requires several controls.

Control access with IAM and repository policies

AWS Identity and Access Management (IAM) policies determine which ECR actions an identity can perform. ECR repository policies provide resource-level control over a specific repository. Together, they can control who may push, pull, delete, scan, or administer images. Use separate, least-privilege roles for different purposes. A CI/CD pipeline that pushes images should not automatically receive permission to delete repositories. A production workload that only pulls an image should not receive push permissions. Prefer temporary role credentials over long-lived IAM user access keys.

Basic setup:

1. Identify who needs to push, pull, scan, or administer images.

2. Create IAM roles for those functions.

3. Grant only the required ECR actions and repository resources.

4. Add a repository policy when cross-account or resource-level access is needed.

5. Test that every role can perform its intended task and that unwanted actions are denied.

Encrypt images at rest

ECR encrypts images at rest by default using server-side encryption with Amazon S3-managed keys. When more control over keys is required, a repository can instead use an AWS-managed or customer-managed AWS Key Management Service (AWS KMS) key.

The encryption configuration is selected when the repository is created and cannot later be changed for that repository. A customer-managed KMS key also requires a suitable key policy and IAM permissions. This option is useful when an organization needs direct control over key access, auditing, or rotation policy.

Prevent image tags from being replaced

Tags such as v1.4.0 or production are human-readable pointers to image digests. If a tag is mutable, a different image can later be pushed under the same tag. This can make deployments difficult to reproduce and can allow an approved image to be silently replaced.

ECR image-tag immutability prevents existing tags from being overwritten. It can be enabled when creating a repository or by editing an existing repository:

1. Open Amazon ECR → Private registry → Repositories.

2. Select the repository.

3. Choose Actions → Edit repository.

4. Select the required image-tag immutability setting and save it.

After immutability is enabled, an attempt to reuse an existing protected tag is rejected. Deployments should also use image digests when strict reproducibility is required.

Sign and verify images

Vulnerability scanning asks whether an image contains known vulnerable software. Image signing answers a different question: did this image come from an approved source, and has it changed since it was signed?

Amazon ECR integrates with AWS Signer. ECR supports managed signing, which automatically signs matching images when they are pushed, and manual signing through the Notation CLI and AWS Signer plugin. Signatures are stored alongside the image in ECR. Verification can then be performed before deployment; EKS supports managed verification, while ECS can incorporate verification into a deployment lifecycle hook.

A typical signing flow is:

1. Create an AWS Signer signing profile.

2. Configure ECR managed signing or install Notation and the AWS Signer plugin for manual signing.

3. Sign images using their immutable digest.

4. Configure deployment-time verification with an approved trust policy.

5. Reject an image when its signature is missing, invalid, revoked, or issued by an untrusted signer.

Signing does not prove that an image is vulnerability-free. It proves origin and integrity, so it should be combined with scanning and secure build practices.

2. Scan ECR images for known vulnerabilities

Container images may include vulnerable operating-system packages or application libraries even when the application code itself is secure. ECR provides basic and enhanced image scanning.

Configure basic scanning

Basic scanning is the simpler option. AWS enables the basic-scanning mode by default for private registries, but repositories use manual scanning unless scan-on-push filters are configured.

To configure it in the console:

1. Open Amazon ECR and select the required AWS Region.

2. Choose Private registry → Scanning.

3. Select Basic scanning.

4. Add scan-on-push filters for all repositories or only selected repository names.

5. Save the configuration.

Basic scanning is useful when a team needs a direct operating-system package check at push time or on demand.

Configure enhanced scanning with Amazon Inspector

Enhanced scanning connects the ECR private registry to Amazon Inspector. Inspector generates package-vulnerability findings and can continuously update eligible images when a relevant new Common Vulnerabilities and Exposures (CVE) record appears.

To configure enhanced scanning:

1. Confirm that the administrator has the required ECR, Inspector, and service-linked-role permissions.

2. Open Amazon ECR and select the required Region.

3. Choose Private registry → Settings.

4. In the Scanning configuration, select Enhanced scanning.

5. Choose continuous scanning for all repositories or define repository-name filters.

6. Choose whether remaining repositories should be scanned when images are pushed.

7. Save the configuration and repeat it in every required Region.

Amazon Inspector automatically creates its required service-linked IAM role when enhanced scanning is activated. Repositories that do not match an enhanced-scanning filter are not scanned. Enhanced scanning also introduces Amazon Inspector charges, so teams should review current regional availability and pricing before enabling it broadly.

Review and act on findings

In ECR, open the repository, select an image, and review the findings by severity. Selecting a vulnerability opens its detailed Inspector record. Findings can include the CVE, vulnerable package, installed and fixed versions, severity, and remediation information.

A practical response process is:

1. Prioritize critical and high-severity findings, considering whether the image is actually deployed.

2. Update the affected package or move to a patched image source.

3. Rebuild the image rather than changing a running container manually.

4. Push the replacement under a new immutable tag or digest.

5. Scan again and redeploy the fixed image.

6. Remove outdated images according to a documented retention policy.

Amazon Inspector scans supported images stored in ECR. It does not inspect the live behavior of a running container. Inspector can map image findings to running ECS tasks and EKS Pods, which helps teams identify where a vulnerable image is in use. GuardDuty performs the runtime threat-detection role described later in this article.

3. Harden ECS tasks and containers

A secure registry cannot compensate for an unsafe task definition. AWS recommends reducing the contents and privileges of containers, scanning dependencies, and limiting each task to the access it requires.

Important controls include:

• Build minimal images and remove unnecessary shells, package managers, tools, and special-permission binaries.

• Run the application as a non-root user.

• Use a read-only root filesystem when the application supports it.

• Avoid privileged containers and access to host namespaces or devices.

• Drop unnecessary Linux capabilities.

• Set suitable CPU and memory limits.

• Do not store secrets in the image, source repository, or Dockerfile.

Separate the ECS task role from the execution role

The task IAM role supplies AWS permissions to application code inside a task. The task execution role allows the ECS or Fargate agent to perform launch-time work such as pulling an ECR image, publishing logs, or retrieving a secret referenced by the task definition.

Create separate least-privilege task roles for applications with different needs. Reference the application role through taskRoleArn and the launch-time role through executionRoleArn. This separation prevents an application from inheriting every permission required by the deployment agent.

Store secrets outside the image

ECS can inject values from AWS Secrets Manager or encrypted Systems Manager Parameter Store parameters. Restrict retrieval permission to the appropriate role. If an injected secret changes, start a new task or force a new service deployment because an existing task does not automatically receive the new value.

Environment variables can leak through logs, debugging, or inspection. For higher-sensitivity cases, the application can retrieve a secret directly or a sidecar can write it to a task-scoped shared volume. Never print a real secret merely to confirm that injection worked.

4. Protect identities and networks in Amazon EKS

EKS security has both AWS and Kubernetes layers. Pods require controlled access to AWS APIs, while network rules must limit unnecessary communication.

Use EKS Pod Identity

EKS Pod Identity associates an IAM role with a Kubernetes service account. Pods using that service account receive temporary credentials for the specific AWS permissions assigned to the role. This is safer than embedding AWS keys in a container or allowing applications to rely broadly on a node's IAM role.

The setup flow is:

1. Install the EKS Pod Identity Agent unless EKS Auto Mode already provides it.

2. Create a least-privilege IAM role trusted by the EKS Pod Identity service.

3. Associate that role with a Kubernetes service account in the required namespace and cluster.

4. Configure the Pod to use that service account.

5. Confirm that a supported AWS SDK uses the default credential chain.

Apply security groups for Pods

Security groups for Pods apply AWS security-group rules to supported EKS Pods. They can control access between a Pod and VPC resources, AWS services, or external endpoints. Support depends on the cluster, node, networking, and VPC CNI configuration, so teams must check the current limitations before enabling the feature.

Restrict Pod traffic with network policies

Kubernetes allows unrestricted Pod communication by default unless network policies are enforced. Standard NetworkPolicy resources can restrict traffic by IP address and port within namespaces. Supported Amazon VPC CNI versions can enforce these policies, including cluster-level administrative policies in supported configurations.

Security groups for Pods and Kubernetes network policies are complementary. Network policies primarily segment in-cluster traffic; security groups connect Pod access control to VPC and AWS network rules. Calico remains an optional implementation, but it is not the only network-policy approach for EKS.

5. Detect threats in running containers with GuardDuty

Image scanning finds known vulnerable components before or after deployment. It does not observe what processes and users actually do at runtime. GuardDuty Runtime Monitoring analyzes operating-system, process, file, command-line, and network events from supported workloads to identify suspicious activity.

Runtime Monitoring supports EKS, ECS on Fargate, and EC2 resources, subject to platform requirements. It does not support EKS workloads running on Fargate.

For a standalone account, the basic setup is:

1. Check the prerequisites for the required resource type.

2. Open the GuardDuty console and choose Runtime Monitoring.

3. Enable Runtime Monitoring.

4. Configure automatic or supported manual agent management for EKS, or automatic agent management for ECS on Fargate.

5. Restart or force a new deployment of existing ECS services when required so new tasks receive the GuardDuty sidecar.

6. Check the coverage page and confirm that the protected resources report Healthy.

The GuardDuty agent can detect indicators such as suspicious process execution, unexpected network connections, credential misuse, or privilege-escalation behavior. A healthy coverage status is essential: if telemetry cannot reach GuardDuty, the service cannot create runtime findings for that workload.

6. Centralize findings, audit activity, and monitor operations

Three supporting services improve visibility but should not be confused with scanners or runtime agents:

• AWS Security Hub CSPM aggregates findings from services such as Inspector and GuardDuty and evaluates supported security controls. It gives security teams a central view but does not scan an image itself.

• AWS CloudTrail records AWS API activity. A trail can retain events in Amazon S3 and send them to CloudWatch Logs for auditing and investigation.

• Amazon CloudWatch Container Insights collects container metrics and logs for supported ECS and EKS environments. It helps identify operational problems and unusual resource behavior but does not replace GuardDuty threat detection.

These services can be connected to alerting and response workflows. For example, Inspector can send finding events through EventBridge, Security Hub can centralize findings, and CloudTrail can help determine who changed a security setting.

A practical implementation order

AWS offers many security controls, but they are easier to deploy when introduced in a clear sequence:

1. Store private images in ECR and define least-privilege push, pull, and administration roles.

2. Select the required encryption configuration when creating each repository.

3. Enable tag immutability.

4. Configure managed image signing and deployment-time signature verification.

5. Enable ECR scan-on-push or enhanced continuous scanning with Inspector.

6. Define a process for rebuilding and redeploying images when serious findings appear.

7. Harden ECS task definitions and EKS workload specifications.

8. Move secrets to Secrets Manager or Parameter Store.

9. Give ECS tasks and EKS Pods workload-specific IAM roles.

10. Restrict network communication with security groups and network policies.

11. Enable GuardDuty Runtime Monitoring on supported production workloads and verify healthy coverage.

12. Centralize findings in Security Hub and retain audit and operational evidence with CloudTrail and CloudWatch.

Conclusion

AWS container security is a collection of connected controls rather than a single scanner. ECR protects and scans stored images. Inspector manages image-vulnerability findings. AWS Signer establishes image trust. ECS and EKS provide controls for workload identities, privileges, secrets, and networks. GuardDuty detects suspicious behavior after supported workloads begin running. Security Hub, CloudTrail, and CloudWatch then provide central visibility and evidence.

Using these layers together reduces the chance that an untrusted or vulnerable image reaches production, limits the damage a compromised workload can cause, and gives teams the information needed to investigate and respond.