With dozens of key security configurations possible for EC2 alone, the number of configuration options in AWS can be overwhelming at times. While the complexity is rising, properly – and securely - configured cloud accounts are critical to keeping pace with dynamic infrastructure requirements for a cloud native deployment. The challenge of ensuring services are properly configured is compounded by the sheer number of AWS services available, each with its own requirements.
AWS cloud services are constantly in flux, with new offerings and regular updates, making it difficult to keep up, even with the help of a CSPM (Cloud Security Posture Management) solution.
The cloud configurations demonstrate many of the interplays in configurations across different AWS services, some with the capability to override, or impact, others. It would be an understatement to say it is confusing to figure out how to prioritize efforts, or to know where to begin.
In this context, knowing the riskiest configurations can guide teams to understanding how to identify the potential risks of their own environments and choice of AWS services. The following include the top 3 riskiest cloud AWS configurations across the most popular cloud native AWS services:
Amazon EKS
Running Kubernetes on AWS is possible with Amazon EKS. It integrates with other Amazon services like IAM and VPC, which is helpful to keeping configurations consistent.
- Access Control: Block pod access to IMDS
- It is possible that user roles might be overridden by the credentials assigned to the node IAM role by EC2’s instance metadata service (IMDS), through inheritance of the default setting. Blocking pod access to IMDS is recommended to minimize this risk as well as overall container permissions, in keeping with the concept of least privilege.
AWS Fargate
This serverless offering allows customers to let Amazon handle the provisioning, managing and configuring of servers – generally EC2 servers - for a cloud native environment.
- Access Control: Assigning a Task Execution Role
- Task Execution roles are used by Fargate to accomplish two critical tasks: pull images from private registries (which is recommended over public registries) or publish container logs to Cloudwatch. The goal of task execution roles is to isolate permissions for each task based on an IAM role, such that each task is also prevented from seeing all the other AWS services in the account. The task execution role would be the same as the EC2 role, but the trust relationship needs to be changed such that the CNI (container networking interface) is allowed to assume the IAM role.
AWS Fargate
- Policy and Config: Read-only container
- To support the concept of immutability, in the task definition, the configuration must define a ‘read only container.’ This is accomplished by configuring the ‘read only root system’ property to ‘true.’
To get the full list of the 10 riskiest configurations across all of AWS’s most common offerings, plus more that are relevant to their cloud native services, you can download the entire whitepaper The 10 Riskiest AWS Misconfigurations.
