Snyk Lab with Terraform
This lab uses Snyk, a cloud native application security solution, to discover vulnerabilities in Terraform.
Technologies used:
For this lab, we will be using AWS Cloud9 as the IDE. You can use any IDE you prefer as well. If you are using Cloud9, you will have to create an environment. Cloud9 will spin up an EC2 instance as its backend.
There needs to be an IAM role created for the Cloud9 instance. Select AWS Service and EC2.
The role will need the AdministratorAccess IAM policy attached.
Name the policy and create the role.
Once the role is created, select Actions > Security > Modify IAM role.
Under IAM role, select the role and update.
Navigate to the Cloud9 environment and go to the terminal.
To ensure the version of the AWS CLI is up to date, run sudo pip install --upgrade awscli && hash -r
Next, an EC2 key pair will need to be created. Under EC2, navigate to Network & Security > Key Pairs.
Select Create Key Pair in the top right corner. Create a name for the key pair, and select RSA and .pem. After doing so, hit Create Key Pair again.
Installing Terraform CLI
Install yum-config-manager to manage repositories.
Using the yum-config-manager, install the Hashicorp Linux repository.
Install the Terraform repository from the Hashicorp repository.
After installing Terraform, use terraform -version to ensure Terraform was installed correctly.
Installing Snyk CLI
Download the Linux binary and then move it to the bin folder.
If you do not have a Snyk account, you can register for a free one here.
After logging into Synk, navigate to the Auth Token page. (Account Settings > General > Auth Token).
The KEY field will contain the token. You will have to click on the field to view it. This token will be used to authenticate from the command line to Synk.
Note: this is a sensitive value and should not be shared with unauthorized parties.
Using the auth token from Snyk, authenticate from the Cloud9 CLI. If successful, you should see a message saying : “Your account has been authenticated. Snyk is now ready to be used.”
This lab will use a GitHub repository that contains a misconfigured EC2 instance. To begin, clone the repository.
At the base of the directory, run the Snyk scan.
Once the scan is completed, Snyk will display the results. Snky provides different types of information:
Severity as Low, Medium, High, or Critical.
Title, Info, Path, File - details for you to locate the issue within your code, plus some context.
Rule - A link to the publicly available description.
Resolve - mitigation on how to address the issue
A summary plus a count of files and severities by issues.
Let’s look at one of the Medium-rated vulnerabilities. Within Cloud9, navigate to vulnerabile_ec2 > main.tf. This is the main Terraform file for the lab.
This issue we will look at is related to the medium findings. The AWS Security Group is configured to allow access from anywhere on the internet (0.0.0.0/0). Depending on the design, this might not be something that you want. To address this, the CIDR block should be more restrictive.
Create a new file under vulnerable ec-2 called secrets.auto.tfvars. This is where the AWS Keys that were configured earlier in the lab will be stored. Make sure to save the file after creating it.
Run terraform init to initialize the providers
After initialization, run terraform plan to provide an output of what is being compiled and deployed. Terraform plan also provides information on changes.
Once the plan is complete, run terraform apply to provision the infrastructure.
At the end of the output, take note of the IP address. This is the IP for the instance that was just provisioned.
SSH into the instance. We get a “Permission denied” because we do not have the SSH key. Although we cannot successfully access the instance, this is still publicly available to anyone on the internet. Some systems may be purposely configured like this, but it is not typically a best practice.
Instructions on how to SSH into AWS instance.
Similarly, we can run a curl command and also access the application.
Now, let’s visit the instance via browser.
For the purpose of this lab, we want to limit access. As we can see, there are issues with how this is currently configured. Let’s revisit the Terraform code and make some changes to accomplish this.
First, deprovision the resources that were created using terraform destroy
Navigate back to vulnerable-ec2 > main.tf. Within the main.tf file, go to the “allow_ssh_from_anywhere” section. There is a block commented out with “# WORKSHOP” and details about changing the CIDR block to one that is specific to the user.
You can find your IP address using a Google search or a site like whatismyipaddress.com.
Once you have your IP address, modify the code block to specify your IP (e.g., 175.45.45.89/32).
Ensure that the original CIDR block for 0.0.0.0/0 is commented out or deleted.
Next, find the section that allows port 80 from anywhere. Make similar modifications here as well.
At the end of the code block, specify the keypair that will be used to access the instance. This was created earlier in the lab.
Save the changes and run Snyk again.
Great news—the two medium vulnerabilities are now gone after limiting access. This leaves us with one last vulnerability related to a Non-encrypted root block device. Let’s address this.
Look for the “root_block_device” section and uncomment this section. Doing so enables encryption for the EC2 instance.
Save changes and then run Snyk.
After enabling encryption, there are now 0 medium vulnerabilities.
Since the vulnerabilities are fixed, redeploy the environment.
You should be able to see the changes that were made to the configuration (e.g., IP Address).
Revisit the IP to ensure that it is up and running. If you visit the site from an IP outside of your CIDR block, you should not be able to access the site.
After completing the tests, deprovision the environment
Snyk Console
Let’s send the Terraform code to Snyk and view the results in the console. We will need to undo the GitHub changes so that we have the original code with the issues.
The results show the same as the initial scan (3 medium, 5 low).
In your Snyk console, you should see the successful test.
We can see that the medium vulnerabilities are the same as what we saw in the CLI.
Select one of the findings. Snyk allows users to label the vulnerabilities as “Not Vulnerable”, “ Ignore Temporarily” or Ignore Permanently”. In this example, select Ignore temporarily.
When we review it now, the finding provides details about who addressed it, the reason, expiration, etc.
Last updated