Keeping containers secure in Amazon Web Services (AWS) poses intriguing issues and questions about impact and lateral movement. It’s tempting to off-load the entire responsibility of securing the architecture to AWS, but it is always wise to implement best practices and consider potential vulnerabilities. It is also critical to remember what tools AWS already provides to accomplish this before examining service offerings you may not require.

But first, what is Fargate? It is a popular solution in the AWS ecosystem that provides serverless computing for containers while also providing secure application isolation and observability via current AWS services such as CloudWatch Container Insights.

Securing Containers

Due to the highly transitory and short-lived nature of Fargate workloads, as well as the lack of host-level access, Red Canary Linux EDR does not currently support Fargate. Instead, consider the following recommendations when bolstering your Fargate security posture.

• Network Security
• Container Secret Injection
• Fargate Agent Deployment
• Authentication and Authorization Management
• Resource Limits (ulimits)
• Reduce or Remove Linux Capabilities
• Read-Only Containers

Let’s take a look at the options for each.

Network Security

Make use of Task Networking and ensure traffic is routed through an Elastic Network Interface (ENI) to the task. This gives the benefit of isolating a network namespace per task.

Security groups can also be isolated to each task. Task-level specification is a great tool in providing additional security.

Lastly, you can use PrivateLink to ensure images are pulled from Elastic Container Registry (ECR) only within the Virtual Private Cloud (VPC).

Container Secret Injection

By referencing values saved in AWS Parameter Store and Secrets Manager, you can expose them as environment variables for use by containers. More details here.

Fargate Agent Deployment

If you have a security monitoring agent, you can deploy it within a sidecar container alongside another container running application code. This would allow you to implement an agent for runtime security monitoring.

Note: Red Canary Linux EDR Sensor or similar EDR sensors could be used in this situation, but it is not recommended as host-level access is not possible.

Authentication and Authorization Management

By assigning an IAM role to each task, you can isolate permissions enabled for each task and prevent unauthorized tasks from accessing AWS services unnecessarily. Ensure that tasks only see the services to which they require access.

Resource Limits (ulimits)

Make use of resource limits to proactively cap resources and prevent attack techniques like denial of service using fork bombs. Resource limits allow you to set soft and hard quotas on resources like core, cpu, data, nproc, etc.

Reduce or Remove Linux Capabilities

Most containers and commands do not need root privileges so it is a good practice to drop Linux capabilities from containers. This allows you to reduce the fallout from potential damage an adversary may cause by compromising containers. Please reference `linuxParameters` in this list and note the syntax for dropping Linux capabilities.

Read-Only Containers

In workloads that don’t require you to write to the container filesystem, secure them by configuring containers to be read-only. This sets the filesystem to read-only and prevents adversaries from adding unwanted code or changing configuration. Note that this is most suitable for immutable workloads.