Detect infrastructure drift and unmanaged resources with Snyk IaC

As a developer, you're probably using some infrastructure cloud provider. And chances are, you automate parts of your infrastructure using infrastructure as code (IaC), so deployments are repeatable, consistent, easily deployable, and overall, more secure because code makes parameters more visible.

In the end, we all end up with live resources on our cloud provider, but we may or may not know of the current state of all of them. Did anyone manually change an S3 bucket setting? Did a colleague create a new path in our API Gateway deployment? How do we know if some default resources are not misconfigured? And eventually you end up with resources living on the cloud provider account that are either not found at all in any Terraform deployment, have been modified, or deleted completely. This gap between how we think cloud resources are configured and how they’re actually configured is known as infrastructure drift.

Snyk Infrastructure as Code (Snyk IaC) now detects all types of infrastructure drift and reports them as Terraform resources, so developers gain complete visibility and remediate early.This includes changes or deletions of "managed" (resources actually deployed from IaC) and "unmanaged" resources (those are the ones not yet under IaC control).  The reports the Snyk CLI produces can then be read directly from the terminal, integrated in a pipeline or recurring check, or exported as HTML for sharing with others.

Snyk supports all Terraform states and stores these files locally on all blob storage such as Amazon S3, GCS, Azure, HTTPS, Terraform Cloud, and more. Storage can be combined to reflect the structure of your IaC whether you have multiple Terraform repositories across multiple teams or a more centralized model.  Lastly, it works across all major cloud providers — AWS, GCP, and Azure — and requires as little access rights as possible.

In this blog, we’ll walk through some of the issues drift management Snyk IaC can address including:

• Increasing IaC coverage in your cloud environments

• Informing infrastructure drift within a feature or application

• Detecting drift within a specific cloud service

Benefits of drift management

This is a tale of one service and many resources. Let's take an API Gateway deployment as an easy example. In AWS, the experience is beautifully integrated within the web console. In Terraform, it's split into 10 to 25 resources depending on the API Gateway version. Your methods, your responses, the models, the routes, the stages… all of them are different resources.

It means that if you are getting started writing Terraform code from existing services, having a  complete list of unmanaged Terraform resources categorized by cloud service and resource type will make them very visible and save you a ton of time versus looking at how every single cloud service functionality is structured in Terraform.

If we already have our API Gateway under control in Terraform, nothing prevents anyone from adding a route or an HTTP response manually — and no one might ever know about it! Drift detection ensures these changes are detected and reported to mitigate any potential inconsistencies or configuration issues.

In short, we want to make drifts visible to:

• Improve our code coverage so that code can be analyzed for misconfigurations pre-deployment.

• Take immediate action, like delete the resource or revert the change before damage can be done.

Increasing your IaC coverage

If you're like many teams out there, you probably don't have everything covered yet in the many Terraform repositories you use and share across teams. So how does unmanaged resource detection work in Snyk IaC?

Snyk IaC will combine all the Terraform states you feed it into one big aggregated map, and compare it to what it finds on your AWS account. The difference are drifts, reported as Terraform resources.

Using Snyk IaC describe with the --only-unmanaged option will help us achieve exactly this:

1$ snyk iac describe --only-unmanaged
2[...]
3Snyk Scanning Infrastructure As Code Discrepancies...
4
5  Info:    Resources under IaC, but different to terraform states.
6  Resolve: Reapply IaC resources or update into terraform.
7
8Unmanaged resources: 5
9
10Service: aws_iam [ Unmanaged Resources: 3 ]
11
12  Resource Type: aws_iam_policy_attachment
13    ID: user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
14
15  Resource Type: aws_iam_user
16    ID: labs
17
18  Resource Type: aws_iam_user_policy
19    ID: dat-user:manuals3policy
20
21Service: aws_s3 [ Unmanaged Resources: 2 ]
22
23  Resource Type: aws_s3_bucket
24    ID: manual-bucket-2022
25    ID: test-resource-exposure-caxyxllsajfrzbwe
26
27Test Summary
28
29  Managed Resources: 4
30  Unmanaged Resources: 5
31
32  IaC Coverage: 44%

As developers, we can easily take advantage of this output:

• We start by knowing that our code coverage is 44%, making it easier to track progress on the journey to IaC.

• There are two S3 buckets (type: aws_s3_bucket) that are not in Terraform, and we are given their names. We can easily choose to import them or delete them.

• There are a few inconsistencies in our IAM setup: 

  • A "labs" IAM user was manually created (type: aws_iam_user_policy).- What is this user doing?

  • An "Administrator" access policy was manually attached to a managed IAM user named "user1-84i30k" (type:aws_iam_policy_attachment). Are the consequences of this understood by our teams?

  • A full IAM policy was manually added (type aws_iam_user_policy). Who's controlling its content if someone changes it?

Informing what’s changed since your last deployment

Another common use case for developers is management of drift in a specific scope. Often, developers are responsible for a given feature with a very defined scope of infrastructure. We need to detect what changed in the scope of what we defined, not get feedback for their entire cloud account.

A first opportunity here is to simply input all the Terraform states to Snyk IaC, and simply discover which resources are missing, and for some of them, changed:

1$ snyk iac describe --only-managed
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Changed resources: 1
8
9State: tfstate://terraform.tfstate [ Changed Resources: 1 ]
10
11  Resource Type: aws_s3_bucket
12    ID: somebucket-84i30k
13    ~ versioning.0.enabled: false => true
14
15Missing resources: 1
16
17State: Generated [ Missing Resources: 1 ]
18
19  Resource Type: aws_iam_policy_attachment
20    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
21
22Test Summary
23
24  Managed Resources: 3
25  Changed Resources: 1
26  Missing Resources: 1
27
28  IaC Coverage: 75%

This report brings us some interesting information:

• We can aggregate all the Terraform states we use, but get drift information only for that perimeter.

• The report shows which Terraform state  each drift or change is found in.

• This feature is lightweight as it requires only the most minimal access rights on the cloud account. Definitely don't use the CI/CD Terraform deployment credentials anymore!

Detecting missing resources within a cloud service

As developers, we might only have a single cloud service that we want to check into more precisely, let's say "S3" or "IAM". We can use Snyk IaC resource filters for this (--filter="aws_resource_name"), but that would require us to know and list them all, and then keep the list updated. Tedious! That's when we use the --service option to include a whole service without the need to know how many resources are concerned.

1$ snyk iac describe --only-managed --service=aws_iam
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Missing resources: 1
8
9State: Generated [ Missing Resources: 1 ]
10
11  Resource Type: aws_iam_policy_attachment
12    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
13
14Test Summary
15
16  Managed Resources: 2
17  Missing Resources: 1
18
19  IaC Coverage: 66%
20  Info: To reach full coverage, remove resources or move it to Terraform.

In this use case, we'll get a report for anything found under the AWS IAM service. That's dozens of Terraform resources easily covered all at once (access keys, groups, attachments, policies, roles, etc.).

Drift management now available in Snyk IaC

Whether we are developers getting started with IaC, or part of a seasoned team with established and sophisticated IaC workflows, drift management in Snyk IaC can help you increase the visibility of what's actually running in your cloud accounts, and help you take action quickly, leveraging the lowest access rights possible.

Snyk IaC drift management can run locally on developers laptops on-demand using the CLI, on CI/CD pipelines, or as scheduled cron jobs to get focused reports (starting with v1.918.0).

Drift management is available on all Snyk plans, including our Free plan, so start securing your infrastructure as code today.