Take control of infrastructure drift

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.

• By testing the tool and opening issues 
• By providing us with feedback and proposing new features
• By spreading the word and following the project 
• By starring the project 

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 published under the Apache 2.0 license.