Security | Feb 05, 2021

AWS Cloud Security for Launch Configurations with Policy as Code

AWS Cloud Security for Launch Configurations with Policy as Code banner

AWS Cloud Security

The AWS Well-Architected Framework provides guidance to help AWS users apply best practices in the design, delivery, and maintenance of AWS environments.  The framework is built on 5 pillars, one of which is security.  The security pillar identifies 7 principles for AWS cloud security, including an emphasis on automating security best practices.

Cloud native organizations adopt Infrastructure as Code (IaC) to help them programmatically build cloud architectures and manage these architectures in version controlled templates.  Policy as Code can be used in IaC pipelines to automate enforcement of security best practices and act as a guardrail to identify and fix threats related to cloud architecture.

This blog post explains how our open source Policy as Code tool Terrascan can be used to enforce security best practices in AWS Launch Configuration resources.  Terrascan is easy to incorporate into automated processes and pipelines, and includes more than 500 security best practice policies which identify violations in Infrastructure as Code targeting AWS and other major cloud providers.

AWS Launch Configuration Risks

Scalability is one of the primary drivers increasing demand and adoption of cloud computing. With cloud computing costs typically based directly on the amount of resources used, organizations can manage costs by scaling resource usage up and down according to needs and demand.

AWS Auto Scaling groups are often at the center of these efforts, enabling teams to grow and shrink usage in response to changing conditions while also making use of the most economical combination of EC2 instance types and pricing models.

The very first step to create an Auto Scaling group is to associate either a launch configuration or a launch template. A launch configuration is an instance configuration template that an Auto Scaling group uses to launch EC2 instances.  Each launch configuration consists of attributes which define the configuration to be used for the instances.

Let’s say you are using Terraform as your Infrastructure as Code tool to provision a launch configuration on AWS. As with any cloud resource, it is possible to accidentally misconfigure the attributes and introduce security risks into the environment. The following table lists how launch configuration attributes can be misconfigured:

Attribute

Misconfiguration

IAM Instance Profile

Overly Permissive Instance Profile

Monitoring

CloudWatch monitoring is disabled

Instance Metadata Options

Use of IMDSv1

User data

Hard coded secret keys, urls and shell scripts

Storage ( Root / EBS )

Encryption is disabled

Security groups

Security Groups are wide open to internet

We can leverage Policy as Code to automate the detection of these misconfigurations to eliminate those risks.

The below Terraform configuration is vulnerable by design and includes all of the misconfigured attributes mentioned above

resource "aws_launch_configuration" "mis-configured-launch-config" {
 name             = "mis-configured-config"
 image_id         = data.aws_ami.ubuntu.id
 instance_type    = "t2.micro"
 user_data_base64 = "TFMwdExTMUNSTU9WS1BZUkNGVUxSWTU0NFJUTTk3RUNLVjFRWlA2UjVDNExPNE0yRU9IMjdUVjhGUTUwUzdCM0MyUlhE"
 
 iam_instance_profile = aws_iam_instance_profile.web-app-instance-profile.name # this iam instance profile has admin permissions
 
 enable_monitoring = false #cloudWatch Monitoring is disabled
 
 #the below configuration contributes to IMDSv1
 metadata_options {
   http_endpoint = "enabled"
   http_tokens   = "optional"
 }
 # this  security group has ingress block wide open to internet
 security_groups = [aws_security_group.web-app-security-group.id] 
 root_block_device {
   volume_type           = "standard"
   volume_size           = 100
   delete_on_termination = true
   encrypted             = false #block is not encrypted
 }
 
 ebs_block_device {
   device_name = "ebs-device"
   encrypted   = false #block is not encrypted
 }
}
 

Threat Modeling with Policy as Code

I was recently reading an AWS blog about How to approach threat modelling. The core steps addressed in the blog are:

  1. Identify the assets
  2. List the threats
  3. Per threat, identify mitigations

In the above section, we have already completed the first two steps.  In the cloud, resources are our assets; in the example above, the primary asset is the AWS launch configuration and the attributes are secondary assets.  The threats are misconfiguration of the assets, as these act as an attack vector for a particular threat.

For step 3, we just need to identify mitigations for each threat, which may include security control implementations.  Since we’re using Policy as Code as a mitigation, the following table lists the policies available in Terrascan’s repository and the misconfigurations each policy identifies:

Attributes

Misconfigurations

Policies

IAM Instance Profile

Overly Permissive Instance Profile

AC-AW-IA-LC-H-0441

Monitoring

CloudWatch monitoring is disabled

AC-AW-LM-LC-M-0440

Instance Metadata Options

Use of IMDSv1

AC-AW-CA-LC-H-0439

User data

Hard coded secret keys, and urls 

AC-AW-DP-LC-H-0102

Storage ( Root / EBS )

Encryption is disabled

AC-AW-DP-LC-H-0413

Security groups

Security Groups are wide open to internet

AC-AW-IS-LC-H-0438

With our threat model defined, it is time to test our security controls.

Terrascan as a Security Control

Terrascan can be either configured locally or integrated into your CI/CD pipeline, and helps you to automate the implementation of security controls in the form of policies. Below is the result for the vulnerable Terraform file introduced in the previous section, when scanned using Terrascan with the command: terrascan scan -t aws -f <path-to-the-terraform-file>.

AWS cloud security: Terrascan detecting AWS Launch Configuration problems
Screenshot of Terrascan results which identify problems in AWS Launch Configuration resources.

By integrating Terrascan into your automated pipelines, you can adhere to the security principles of the AWS Well Architected Framework by automating security best practices with Policy as Code.

We’re adding new policies to Terrascan all the time, to improve AWS cloud security as well as the security of other cloud provider environments.  If you have a new policy that you would like to see, please open an issue in our GitHub repo.  We also welcome pull requests if you prefer to implement policies yourself.  Terrascan uses the Open Policy Agent, so it’s probably easier than you think!

Codifying Kubernetes Security Without PodSecurityPolicy

Evolving Risks, Insecure Defaults, Watering Hole Threats in the Cloud

Kubernetes Security: Stop Blind SSRF with Policy as Code (CVE-2020-8555)

We use cookies to ensure you get the best experience on our website. By continuing to browse this site, you acknowledge the use of cookies.