Take control of infrastructure drift

Infrastructure as code is awesome, but there are so many moving parts: codebase, *.tfstate , actual cloud resources. Things tend to drift.
Drift happens 
when team members update infrastructure through the web console without telling anyone
with uncontrolled updates on the provider side
when "terraform plan" fails to catch some of your changes
with unchecked scripts calling APIs to update your infrastructure

driftctl is a free and open-source CLI that tracks, analyzes, prioritizes, and warns of infrastructure drift

How it works

Track coverage
Run ./driftctl to scan the tfstate, and compare it to the actual infrastructure state on the provider side. Get a report on infrastructure as code coverage metric.
Check consistency
Make sure that your code base matches your actual cloud resources even after manual changes.
Prioritize and sort drift events
driftctl sorts and prioritizes events by impact. Drift events can be ignored if they are noise, or flagged if they are important. (roadmap)
Get alerts
driftctl alerts users when critical drift happens. It can run at scheduled intervals, or it can be integrated in your CI.

FAQS

Infrastructure drift happens when the state of your actual infrastructure (for instance services deployed on AWS) becomes different from the expected state (services created in code+manually managed and known)

Infrastructure as Code is a never-ending process and changes are very frequent. Uncontrolled drifts are devops nightmare because drift causes security issues, additional cost, and toil.

You are still managing manually-created resources, while most new resources might end up under source control.
In this case, the easy to use code coverage tool, will help you know exactly what’s the proportion of manual resources and IaC managed resources.

If you are still on the path towards a full automation of your cloud resources, chances are that you have an increased risk of manual interactions as you are still used to utilizing the cloud provider console to manage existing resources. Mistakes can happen: a resource managed by some IaC can end up being manually modified, and next time Terraform is applied, there’s a drift to manage (imagine that situation during an emergency terraform apply…)

Another complexity you are facing is the visibility of manually created resources. When most of the team’s IaaS users’ identities are automated, how do you realize another one was just created manually, therefore out of control? driftctl will alert you that a new resource was manually created, also lowering the code coverage score, so you can improve your IaC codebase promptly.

While advanced teams with full infrastructure automation are still an exception today, they often interact with lesser skilled members, or in large companies, teams. driftctl will help you guarantee everything stays well under control, with immediate feedback.

You will also be interested in changes made inadvertently not by humans but by IaaS-authenticated applications or microservices (a developer can do a lot with IAM keys and a SDK!).

The more advanced teams with the most coverage are bound to handle multiple generations of tools: maybe one product is managed with CloudFormation, the second one with Terraform, and the last one with Pulumi. ‘driftctl’ unifies the visibility of all changes across all the IaC tools you deployed.

(See also how is it different from other tools)

driftctl will support AWS and Terraform on its first release. The project roadmap includes Pulumi, Cloud Formation support as well and additional clouds like Azure (with ARM) and GCP. 

driftctl is a simple but powerful tool to control infrastructure drift in order to improve DevOps productivity and to avoid security/compliance issues introduced by unknown configurations. 

  1. Define your coverage : driftctl scans your IaC codebase, and compares it to the actual infrastructure state on the provider side. It then reports an infrastructure as code coverage metric.
  2. Detect : driftctl scans periodically your cloud provider and detect drift
  3. Sort : driftctl sorts and prioritizes events by impact. Drift events can be ignored if they are noise, ignored as a known drift, or flagged it they are important
  4. Alert : driftctl alerts users when critical drift happens. It can run at scheduled intervals, or it can be integrated in your CI
  5. Remediate (roadmap) : driftctl submits PR to reintroduce unmanaged resources in the code and erase unwanted ressource.

How is it different from terrafom plan, terraform refresh or Cloud Formation’s drift detection?

While IaC tools are only able to detect drifts within their scope, they are blind to all other resources you may have in within your environments. driftctl works in and out of the IaC scoped resources.

Terraform refresh only grabs a delta from the IaaS to the Terraform state, for a resource already managed by Terraform. It doesn’t handle drifts per se, but simply acknowledges a remote change not seen in the local state.

Terraform plan is the opposite: it wants to apply the local code and solve the delta between the intention, local state, and IaaS reality. Even for you resources defined by Infrastructure as Code, Terraform Plan does not provide a complete change coverage and lets some critical changes go undetected with potential security threats wide open.

In both cases, whatever exists out of Terraform is not seen. There’s a huge visibility issue here (and through that: security).

driftctl is also tightly integrated with the IaaS provider and offers a lot more context than the simple configuration drift. It will (roadmap) provide historical data : “it already happened 5 times in the last 5 weeks”, pattern detection : “this S3 bucket appears every day at 05:00:00”, and enhanced drift data: “this change was made by IAM #12345 on 2020/9/8 at 11:04 AM”.

driftctl is a free and open-source CLI that will be published under the Apache 2.0 license. It is not released yet, so just click on the links below to join the alpha list and get updates on the project.

JOIN ALPHA LIST

Joining the alpha list implies receiving occasional updates about the project status and generic information about drift detection.