AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.
In short, users offload the virtual machines management to AWS while focusing on task management. It reduces a lot of complexity from the resource management perspective.
From a security perspective, what benefit does it bring to customers?
Shared responsibility
Security and Compliance is a shared responsibility between AWS and the customer.
This shared model can help relieve the customer’s operational burden as AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates.
The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software, as well as the configuration of the AWS provided security group firewall.
Customers should carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations.
The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment.
As shown in the chart below, this differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.
Regarding Fargate, from a security standpoint, users push more security responsibility to AWS.
This brings a lot of benefits to small businesses which rely on the cloud vendor to host their web service.
Vulnerabilities like Meltdown and Spectre, are not easy to mitigate without a dedicated security team’s effort. If you switch to ECS Fargate, it becomes AWS’s responsibility to patch all the vulnerabilities up to the container runtime level. Customers may then focus on hardening container image, application security, and cloud configurations.
This offloading of some security responsibilities also changes the threat modeling.
Dive into the ECS Fargate threat modeling
Preliminary
It’s good to start with some basic understanding of EC2 Fargate, especially what components are involved:
- Cluster: An Amazon ECS cluster is a logical grouping of tasks or services.
- Task: With a list of attributes to set in order to run a container:
- Container image:
- Environment variables
- Labels
- Readonly Filesystem
- CPU/Memory
- Network mode
- Entrypoint command
- Logging configuration
- Data volume
- IAM role
- Container image:
For more details, please refer to task parameters.
- Service: An Amazon ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. Within the service definition, users also need to select the VPC, the security group for the service, as well as configure the load balancing mechanism.
Threat actors and assets
A threat actor is an entity or code executing in the system that the asset should be protected from. From a defense standpoint, you first need to understand who your potential enemies are or your defense strategy will be too vague.
With some understanding of how Fargate works, we may define a few threat actors as following:
- End user: An entity that can connect to the application. The entry point for this actor is usually the load balancer or the public IP address and port assigned to the application.
- Internal attacker: An entity that has limited access inside the AWS assets. Application developers and compromised containers are good examples of internal attackers.
- Privileged attacker: An entity that has administrator access inside the ECS cluster, or even the entire AWS organization. Examples of privileged attackers are infrastructure administrators or compromised containers with administrator privileges.
We may derive the following threat actors as shown the diagram:
When an infrastructure administrator account is compromised, the attacker gains full access to the company’s AWS environment.
This is game over.
When an attacker tampers the container image with malicious code (i.e., spinning a reverse shell to an attacker’s machine after the container starts) or gains access to the container through an application vulnerability, the impact of the damage depends on the privilege (or the IAM role) assigned to the task, or what other AWS assets the task is allowed to access.
Through the compromised container, the attacker may gain access to sensitive information in S3 or RDS, as well as extra privileges via other AWS products like Lambda.
It’s worth mentioning that through the compromised container, the attacker may also try to jailbreak the Linux namespace isolation to gain access to the host machine.
However, in Fargate, it is AWS’s responsibility to prevent container jailbreak from happening.
One example of the steps AWS takes to secure Fargate is that Fargate containers will never run as privileged mode, neither using host level namespaces nor allowing to add any new capabilities. Such settings reduce the possibility of attackers gaining access to the host.
Still, there are some other parts of the security best practice a user needs to follow, like enabling a read only filesystem.
Defend strategies in ECS Fargate
Below are some examples that describe the defensive strategies in ECS Fargate. Based on the threat modeling above, all of them should fall under the user responsibility:
| Assets | Threat | Security Control | Mitigation Strategy |
| AWS account | Weak password | Strong password policy | Cloudtrail |
| Phishing email | MFA | ||
| Over granted privileges | IAM permission boundary & SCPs | IAM access analyzer | |
| Fargate Container | Vulnerable application code | Web application firewall | Cloudwatch, application log |
| Vulnerable libraries | N/A | Image scanning | |
| Weak Auth | SAST in CI | Application log | |
| Weak communication encryption | App Mesh | SAST | |
| Tampered image | Private registry authentication | Image scanning | |
| S3 | Misconfiguration | S3 bucket policies | Cloudtrail |
| RDS | Misconfiguration | Encryption
VPC IAM policies | Cloudtrail |
The defensive strategies for other AWS assets should be similar to the specified for S3 and RDS. It’s the user responsibility to configure IAM policies properly, in a way that follows the principle of least privileges.
Conclusion
Fargate helps users offload more security responsibilities to AWS.
However, user account security and application security remain crucial. Once an attacker has successfully compromised the Fargate container, it can be used as a base for lateral movement to gain more privileges or access sensitive information.
While following the image scanning best practices is a must to reduce the attack surface of Fargate containers, the cloud security posture management helps set up layers to mitigate the blast radius of an attack.
Last but not least, detecting the anomalous activities through cloudtrail boosts your response speed to security incidents.
Leverage Sysdig Secure by deploying Sysdig Cloud Connector for CloudTrail and obtaining the runtime visibility you need to implement AWS threat detection. Its out-of-the-box set of Falco rules for CloudTrail minimizes the setup effort, response time, and resources needed for investigating security events.
If you do not have a Sysdig account, you can register today for a free trial! Deploy Sysdig Cloud Connector in less than 10 minutes by following instructions in this article, and start having a secured AWS account today.
You can also find Sysdig on the AWS Marketplace.