Scan resources from the input Terraform statefile and compare it to your current profile infrastructure.
Currently, driftctl only supports reading IaC from a Terraform state. We are investigating to support the Terraform code as well, as a state does not represent an intention.
Multiple states can be read by passing
--from flags. You can also use glob patterns to match multiple state files at once.
- Terraform state
- Terraform Cloud / Terraform Enterprise:
You can use any unsupported backend by using
terraform to pipe your state in a file and then use this file with driftctl:
driftctl needs read-only access so you could use the policy below to ensure minimal access to your state file.
The HTTP backend supports the GitLab managed Terraform State using their API.
All you need is a GitLab repository that contains a Terraform state and an access token with the
Here's what the command looks like:
You can find more information about the GitLab managed Terraform State on the GitLab documentation website.
driftctl supports multiple kinds of output formats and by default uses the standard output (console).
You can now visualize your scan results in your browser with the HTML output:
From Terraform documentation, a
computed field is often used to represent values that are not user configurable or can not be known at time of
terraform plan or
Since those values are not known ahead of time from terraform point of view, it is obviously possible that the values displayed in a terraform state file are not up-to-date and may require a
Thus, it could be possible that driftctl finds drifts that are considered false positives because of those outdated values.
We decided to output computed fields and to display a message at the end of the scan to remind you of this behavior.
driftctl supports multiple providers. By default it will scan against AWS, but you can change this using
driftctl supports these providers:
This flag prevents stdout to be use for anything but the scan result.
When running driftctl against an AWS account, you may experience unnecessary noises with resources that don't belong to you. It can be the case if you have an organization account in which you will by default have a service-linked role associated to your account (e.g. AWSServiceRoleForOrganizations). For now, driftctl ignores those service-linked resources by default.
If you still want to include those resources in the report anyway, you can enable the strict mode.
For now, resources include:
- Service-linked AWS IAM roles, including their policies and policy attachments
⚠️ This is EXPERIMENTAL
Enabling deep mode while using a Terraform state as IaC source can lead to unexpected behaviors: false positive drifts, undetected drifts.
Deep mode enables resources details retrieval. It was the original driftctl behavior.
In deep mode we compare resources details to expected ones (like a terraform plan). In non-deep mode (the default one) we only enumerate resources and display which ones are out of IaC scope.
Since it overlaps the new
terraform plan behavior (as of Terraform 0.15 it shows diffs between your state and the remote) we moved the original behavior under the
--deep experimental flag.
If you use a version of driftctl prior to 0.13, the deep mode was the default behavior. If you want to keep the old behavior in a newer version you have to enable the deep mode flag.
You can specify a terraform provider version to use. If none, driftctl uses defaults from the table below:
The default name for a driftignore file is
.driftignore. If for some reason you want to use a custom filename, you can do so using the
--driftignore flag. This is especially useful when you have multiple driftignore files, where each of them represents a particular use case.
You can use only one driftignore file at once.
You can change the directory path that driftctl uses for configuration. By default, it is the
This can be useful, for example, if you want to invoke driftctl in an AWS Lambda function where you can only use the