What’s the difference between Driftctl and Overmind?

What is drift?

‍

In the context of Terraform, drift represents discrepancies between your actual cloud setup and your IaC design. This typically results from changes that aren't tracked post-deployment. As companies grow, manual adjustments in cloud providers such as AWS can cause this gap to widen further.

‍

What is Driftctl?

‍

Managed by Snyk, Driftctl is an open-source tool designed specifically for cloud and Terraform deployments. Driftctl scans your infrastructure and compares your Terraform state files against the cloud provider APIs for unexpected modifications. Any drift will be highlighted and then it will be up to you to decide what to do about it. Driftctl is unable to make these updates itself as it only requires read-only access.

Driftctl features :

• Scan cloud provider (supports AWS, GCP & Azure) and map resources with IaC code.
• Analyse the diff, and warn users about drift and unwanted, unmanaged resources.
• Allow users to ignore resources using .driftignore.

‍

Usage

‍

Driftctl is available on Linux, macOS and Windows. Further detailed info on installation can be found here.

‍

Configuring credentials

‍

You will need to assign proper permissions to allow driftctl to scan your account. Below is an example of configured AWS credentials.

    
# To specify AWS credentials
$ AWS_ACCESS_KEY_ID=XXX AWS_SECRET_ACCESS_KEY=XXX driftctl scan
# or using a named profile
$ AWS_PROFILE=profile_name driftctl scan  
  

Further instructions for the different providers can be found in the docs.

‍

Scan

The scan command scans resources from the input Terraform statefile and compare it to your current profile infrastructure.

    
# With a local state$ driftctl scan
# Same as
$ driftctl scan --from tfstate://terraform.tfstate
# To specify AWS credentials
$ AWS_ACCESS_KEY_ID=XXX AWS_SECRET_ACCESS_KEY=XXX driftctl scan
# or using a named profile
$ AWS_PROFILE=profile_name driftctl scan
# With state stored on a s3 backend
$ driftctl scan --from tfstate+s3://my-bucket/path/to/state.tfstate    
    

‍

.driftignore

‍

For people that do not have the goal of achieving 100% IAC coverage with their infrastructure they can configure .driftignore to ensure Driftctl does not become counter productive to them.

    
# Append all current drift to .driftignore
$ driftctl scan -o json://stdout | driftctl gen-driftignore

# Print proposed driftignore based on all current drift to stdout
$ driftctl scan -o json://stdout | driftctl gen-driftignore -o -

# Changed resources will be excluded
$ driftctl scan --from tfstate://state1.tfstate -o json://stdout | driftctl gen-driftignore --exclude-changed

# Unmanaged resources will be excluded
# In this example, we use a file as an intermediate step instead of piping into
# gen-driftignore
$ driftctl scan --from tfstate://state1.tfstate -o json://result.json
$ driftctl gen-driftignore -i result.json --exclude-unmanaged    
    

‍

What is Overmind?

‍

Overmind is a SaaS Terraform impact analysis tool. It acts as a second pair of eyes, taking the output of Terraform plan to tell you along with the current state of your infrastructure to calculate any dependencies and determine the potential impact or the blast radius of a change. It works by querying your AWS infrastructure via their API in real-time using a read-only role.

Using the blast radius, its real-time dependency map and a LLM it can provide a list of human readable risks that can be reviewed prior to running Terraform apply. These risks can either be commented back as part of your CI / CD pipeline or viewed in the app.

Overmind supports >100 different AWS resources and >300 possible relationships, including those that span AWS Accounts and services, whether they be created by Terraform, manual intervention, or any other process. It currently has two plans (free & pay-as-you-go.) The free plan offers unlimited users 150 free changes per month with any extra changes $0.45 each after.

‍

Usage

‍

Get started by creating a free account.

Next you will need to create a change. This can be done by:

• Get started quickly using the Overmind Github action. The action will automatically create a new change with the resources and items parsed from your Terraform plan output.
• Integrate Overmind into any CI /CD tool using the CLI.
• Coming soon or by using the Overmind CLI to run a plan and apply locally.

‍

Overmind Plan

‍

Let's look at an example using the Github action. Based on the planned changes and the relationships that we have discovered, Overmind discovers the blast radius of what might be affected by this change including resources not in terraform.

‍

‍

The Github action can be set up as part of you CI/CD pipeline to notify you of the affected items/ apps of your change automatically. However any CI /CD tool can be supported using the CLI.

‍

‍

You will then receive a set of human-readable risks that you are able to see if there is anything unexpected or of concern. If you notice that the change might affect more than you thought, you can modify either your code, or the way you plan to roll out and monitor the change to account for it. These risks can either be commented back as part of your CI / CD pipeline or viewed in the app.

‍

‍

By understanding which services would potentially by affected by the planned change, you'll have a full picture and will be able to fix any issues before it effects production.

‍

Overmind apply (diffs)

‍

When you're ready to start the change, Overmind will take a snapshot before and after to validate that the change went through as intended. Allowing you to view the health status of resources and config diffs in detail within the app.

• Differentiate between “intentional” changes made as part of a deployment, and “unintentional” changes that may indicate that the deployment has caused problems and needs to be rolled back.
• Have a record of which Terraform deployments caused which infrastructure changes means that the causes of problems can be more quickly discovered, reducing Mean Time To Identification
• Store infrastructure state before a failed deployment, means that rollbacks can be done easily, with a guaranteed reference to the previous working configuration

‍

‍

Exploring you infra

‍

Overmind also lets you discover dependencies in real-time using the “Explore” functionality, allowing them to plan the rollout of changes more easily and avoid risky changes to core components. Understand an application starting with just a AWS resource name or public data point and expanding outwards without significant knowledge of AWS or the application itself.

‍

If you want to just try this out on public data (HTTP, DNS etc), you can use the new Playground without needing to sign up.

‍

Driftctl vs Overmind

‍

To compare the two, Driftctl does a great job at managing the challenge of drift when working with IaC in the cloud. Whereas Overmind can show you the impact of your IaC changes before you make them. As they both fall into different stages of a CI/CD pipeline you many find yourself wanting to integrate both as part of jobs rather than choosing one or the other.

‍

Using Driftctl and Overmind together?

‍

Using a Github action you would be able to run both Driftctl and Overmind as part of a CI/CD run. In the example below Driftctl would run as part of the validate stage to ensure that drift has not occurred. Whereas Overmind would run after the plan stage to provide you with a blast radius report outlining any potential config changes.

Combining both these tools would ensure that you’ve covered yourself from any drift or config related issues that could lead to outages.

‍

‍

Get started today

Both tools are freely available:

Driftctl -  Download and installation docs here.

Overmind - Sign up and create an account here.