With ECS on Fargate, you can offload the security patching work to AWS and the cloud provider takes responsibility for dynamically patching your instances for any newly identified Common Vulnerabilities and Exposures (CVEs). However, if you are running ECS on EC2, you have to be aware of the Shared Responsibility Model from AWS (https://aws.amazon.com/compliance/ shared-responsibility-model/) . The most important thing to remember is that AWS isresponsible for the security of the cloud, and the customer is responsible for security in the cloud. This applies not only to containers but also the entire AWS ecosystem in general. So, regularly patching the EC2 instances is the customer’s responsibility and can be easily managed by dynamically updating the affected libraries or adopting the idea of infrastructure immutability, as discussed in Chapter 3, Leveraging Immutable Infrastructure in the Cloud . This essentially means that you can replace thewhole AMI with a new official artifact from ECS as soon as it is available. However, thisrequires a solid software delivery and test process that is automated.

Network isolation using the task-level ENI

ECS is quite flexible when it comes to networking the properties of the tasks in your cluster. There are three modes: host, vpc, and bridge. From a security standpoint, this capability allows you to manage the network traffic for this container, just like you would do it for an EC2 instance. Depending on what networking mode you use, you can either isolate the container within the boundaries of the underlying host with a bridge network, use the VPC constructs to assign ENIs directly to the containers, or completely abstract the containers behind the host IP using the host mode.

Tasks that solely focus on some sort of batch processing can be run in isolation by leveraging the Docker-managed bridge network. For others, where you would like to expose the workloads outside the host, you could use the other two modes.

Container secrets and kernel capabilities

Injecting secrets into the container environment can be achieved by defining the relevant keys, and respective values, in your container definitions. However, when dealing with secure parameters, you can make use of the Secrets Manager integration to avoid leaking any confidential data as part of the code, or related configurations.

All applications running inside containers need system call capabilities to perform some functions. ECS makes it possible to granularly assign the exact system calls that should be allowed by the particular task. Unless you are running container workloads that need to make some changes directly on the underlying host, you should try and avoid privileged mode. This essentially makes the container behave like a root user on the underlying host.