Securing S3 bucket configuration and access with Snyk & Solvo

Solvo is empowering developers and DevOps engineers by enabling them to run their cloud infrastructure with least privilege access, at speed and scale. In this article, we’ll go through a workflow combining Solvo's automatic platform with Snyk Infrastructure as Code (Snyk IaC) to create customized and secured access from a Lambda function to an AWS S3 bucket. This blog was originally posted on the Solvo website.

More and more, organizations are shifting over to using the infrastructure as code model for managing their cloud resource configurations.

Configuring your infrastructure through code allows you to have better version and source control, making it easier to track and replicate conditions from one environment to another. This approach is particularly useful for spinning up AWS S3 buckets that can come in handy for storing your code or other useful bits of data. As a cloud resource, these S3’s are easily shareable with the rest of their team.

But sometimes, these S3’s become a little _too_shareable. When working quickly, writing a secure IAM policy for a cloud asset (S3, Lambda, EC2 or any other asset) is the last thing that developers think about. In the interest of speed and convenience, it is far from uncommon for a developer to misconfigure the bucket with overly permissive security policies that may put the contents of the bucket at risk of exposure.

Let’s take a look at some policy-based security risks and how we can avoid them.

An improperly configured Lambda example

Below we have a Terraform configuration that sets up an AWS Lambda which puts an image into an S3 bucket. You can also see here the code for the IAM role and security policy.

Which details can we glean from this configuration that should tell us a bit about its contents and level of security?

1```
2# create function 
3resource "aws_lambda_function" "Lambda_function" { 
4    s3_bucket = "my-bucket" 
5    s3_key = "my-key.zip" 
6    function_name = "my-test-function" 
7    role = aws_iam_role.lambda_iam_role.arn 
8    handler = "index.handler" 
9    runtime = "nodejs12.x" 
10    memory_size = 1024 
11    timeout = 900
12}
13
14# create role 
15resource "aws_iam_role" "Lambda_iam_role" {
16    name = "my-lambda-role" 
17    assume_role_policy = <<EOF
18{
19    "Version": "2012-10-17", 
20    "Statement": [
21        {
22            "Action": "sts:AssumeRole", 
23            "Principal": {
24                "Service": "lambda.amazonaws.com" 
25            }, 
26            "Effect": "Allow", 
27            "Sid": ""
28        }
29    ]
30}
31EOF
32}
33
34# create policy 
35resource "aws_iam_role_policy" "Lambda_iam_policy" { 
36    name = "my-lambda-policy" 
37    role = aws_iam_role.Lambda_iam_role.id
38    policy = <<EOF
39{
40    "Version": "2012-10-17", 
41    "Statement": [
42        {
43            "Effect": "Allow", 
44            "Action": [
45                "logs:CreateLogGroup",
46                "logs:CreateLogStream", 
47                "logs:PutLogEvents"
48            ],
49            "Resource": "*"
50        },
51        {
52            "Effect": "Allow", 
53            "Action": "*",
54            "Resource": "*"
55        }
56    ]
57}
58EOF

In our application, the Lambda is currently written to put images of dogs in an S3 bucket. This Lambda has a permission to do that, along with other actions like Put, Get, Delete, Create and List. And many more actions if we consider all the other services in addition to S3.

This happened because of what’s written in lines 52-54. We’re effectively ALLOWing all actions on all resources. These mean admin permissions.

This is far too permissive. The only type of action that should be permitted here is “put”, since anything else is excessive and could lead to data leakage, data corruption, or be used for recon on our assets.

If you know both Terraform and AWS IAM fairly well and you only had to review this one configuration, it might be easy to spot the problem. But, generally there is far more Terraform configuration and the knowledge of configuration details is tough to keep up with, making it unlikely that a developer or security team member will stumble across this risky policy buried deep inside a set of Terraform modules.  

Thankfully, there are new tools available that are making the task of finding and fixing these issues a much more manageable lift and helping scale security responsibilities out to all the engineering teams using IaC.

Scanning for insecure configurations

Snyk Infrastructure as Code (IaC) is an IaC testing tool that is capable of scanning Terraform, Kubernetes, and AWS CloudFormation configurations and identifying risky policies across services in AWS, Azure and GCP. This might be something as simple as an asterisk that makes the policy way too permissive, as in our example above. Or possibly a “write” where there should only be a “read”, for example.

By utilizing continuous, automated static testing, Snyk IaC is able to scan Terraform at a scale that makes it effective for organizations for managing their infrastructure as code. If the scan turns up a risky configuration, then Snyk will guide the engineer to a fix, but even better, Solvo can be used with Snyk IaC to automatically generate a secure policy that will mitigate the potential exposure.

Let’s see how it works in practice.

To run the scan, we can use the Snyk CLI to run a snyk iac test on our configuration:

The scan has turned up a misconfiguration in the policy that uses an “*” that is way too permissive since it allows for everything.

Snyk IaC provides information about the potential risk from this configuration and general advice for how to fix the problem, and Solvo takes this further by automatically generating the least privileged IAM configuration specific to your environment. Used together, you find and fix issues as you code them, to quickly make the necessary corrections and ensure that it is secure before deploying.

Now we see that our policy only allows for “PutObject”, so our dog pics are safe from harm

Once Solvo enforced the policy, we scan the Terraform file again and Snyk IaC shows us that the administrative permissions are all gone:

Combining integrations for wider coverage

Leveraging Snyk IaC scans, organizations can proactively identify and fix risky policies in their infrastructure as code, be it Terraform, Kubernetes, or CloudFormation. When used in combination with Solvo, Solvo can generate secure policies in place of the risky ones and help organizations quickly fix misconfigurations and improve security without needing to bring on additional resources or expertise. 

For more information about how Solvo can help to automatically reduce your cloud infrastructure risk, visit the Solvo website and get started or request a free demo. If you haven’t tried Snyk IaC, you can start using it for free.

David Hendri is the Solvo Co-Founder & CTO

Lauren Place is a Snyk Product Marketing Manager