Overmind Introduces Terraform Plan Support

You can now easily view Terraform diffs in Overmind. In version 0.19.3 of ovm-cli, users can now capture planned before and after attributes from Terraform changes.

Example usage

Firstly you’ll want to make sure you have the latest version of ovm-cli installed and up-to-date. Once installed run the following command to ensure it is working correctly:

ovm-cli help

‍

Can can upload a terraform plan to overmind for Blast Radius Analysis by using the following commands:

terraform show -json ./tfplan > ./tfplan.json
ovm-cli submit-plan --title "example change" ./tfplan1.json ./tfplan2.json ./tfplan3.json

‍

If you have the Overmind Github action {Link} configured you’ll now be able to view a parsed Terraform plan output showing you the expected changes.

You’ll also be able to see any unmapped changes along with the calculated number of affected items and edges in the Blast Radius. If you are not familiar with a Blast Radius, it is any item/ resource downstream of the change that could logically be impacted by the change/s being made.

By clicking the link you can view the 103 items that could be impacted by the change in more detail. From within the console you’ll be able to see all the links and dependencies of the potentially impacted items. From here you’ll be able to decide if you want to go ahead with the change or make some changes and re-generate a new Blast Radius.

Under the hood

In order to calculate the blast radius from a Terraform plan, it uses mappings provided by the sources (AWS, K8s) to map a Terraform resource change to an Overmind item. In many cases this is simple, however in some instances, the plan doesn't have enough information for us to determine which resource the change is referring to.

A good example is a Terraform environment that manages 2x Kubernetes deployments in 2x clusters which both have the same name. By default we'll add both deployments to the blast radius since we can't tell them apart. However to improve the results, you can add the overmind_mappings output to your plan:

output "overmind_mappings" {
  value = {
    # The key here should be the name of the provider. Resources that use this
    # provider will be mapped to a cluster with the below name. If you had
    # another provider with an alias such as "prod" the name would be
    # "kubernetes.prod"
    kubernetes = {
      cluster_name = var.terraform_env_name
    }
  }
}

‍

Valid mapping values are:

• cluster_name: The name of the cluster that was provided to the kubernetes source using the source.clusterName option

Whats next… risks

With Overmind's risks you can surface incident-causing config changes as part of your pull request. It acts as a second pair of eyes, analysing your Terraform plan along with the current state of your infrastructure to calculate any dependencies and determine the potential impact or the blast radius of a change. From the blast radius 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.

Interested in learning more, join our Discord or check out our Terraform example repository.