Making sure containers are secured in AWS poses interesting challenges and questions surrounding 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 key to remember what tools AWS already provides to accomplish this prior to exploring service offerings you may not need.

But first, what is Fargate? It is a popular solution that provides serverless compute for containers in the AWS ecosystem, offering secure application isolation and observability through existing AWS services like CloudWatch Container Insights.

Securing Containers

Owing to the highly ephemeral and short-lived nature of the workloads commonly seen in Fargate, alongside the lack of host-level access, Red Canary Cloud Workload Protection does not offer support for Fargate at this time. Instead, we recommend considering the following points in strengthening your security posture in Fargate.

• 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 ECR only within the VPC.

Container Secret Injection

Leverage AWS Parameter Store and Secrets Manager by referencing values stored therein then expose them as environment variables for use by the 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 CWP 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

Isolate permissions enabled for each task and prevent unauthorized tasks from unnecessarily accessing AWS services by assigning an IAM role to each task. Ensure tasks only see the services they need access to.

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.