Getting started on driftctl: AWS authentication

Your first step towards using driftctl in a secure way.

The examples here are based on AWS.

Please follow our documentation to authenticate on Microsoft Azure or Google Cloud Platform.

Welcome to this walkthrough that will get you started on driftctl in a couple of steps. In this blog post, we’ll show the simplest but secure way we can use authentication with AWS and driftctl: a read-only IAM dedicated user and an optional separate IAM profile to access the S3 bucket that contains the Terraform states.

Back to the basics

Driftctl needs the lowest read-only access rights possible and uses the standard AWS CLI environment variables like AWS_PROFILE.

So, for example, if you already have an AWS profile configured in ~/.aws/credentials, to use with Terraform, you can use it directly with driftctl:

An alternative, depending on your use case, is to export the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, and then use driftctl that will automatically pick them up to authenticate on AWS. Remember to also export a default AWS region AWS_REGION

More information on basic AWS authentication can be found in the AWS CLI User Guide.

It can be as simple as that!

See below if you have to authenticate separately to access the Terraform states inside your S3 bucket.

Setup a dedicated IAM user for driftctl

Though using an already existing AWS profile can be easy to get started, you probably want to choose a more secure option. To begin with, driftctl doesn’t need “write” access to anything! So if you use the same AWS profile as for Terraform, it’s giving too many access rights.

The quick’n’simple path: a Read-Only Policy

Here’s a simple and secure read-only option to get you securely started in less than 2 minutes.

Go to the AWS IAM Users page

Click on “Add User”
Give the user a name (“driftctl-readonly” is a good default)
Select “Programmatic Access” because we’ll need keys (keep unchecked “AWS Management Console access” because humans aren’t required here.

Click “Next: Permissions”.
Click on the “Attach existing policies directly”
Search for the “ReadOnlyAccess” AWS-managed policy and select it

Click on “Next: Tags”
Optionally add a tag like “Manual: true” or “Terraform: false”
Click on “Next: Review”
Review one last time the user details
Validate the user creation by clicking on “Create user”

Securely store the Access key ID and the corresponding Secret access key (or keep the tab open)
Now switch to the AWS CLI in your terminal to configure a new profile named “driftctl-ro”:

You’re now ready to use driftctl with a dedicated and more secure, read-only, AWS profile:

A separate authentication for S3

It’s a common pattern among teams to use a different authentication for the Terraform state files. Sometimes it’s to share a single S3 bucket with different teams, sometimes it’s for fine-grained access control, sometimes it’s just for pure isolation in a different AWS account. You know you’re probably in this case if you have a specially crafted configuration for your S3 backend in Terraform.

Whatever reason you have to need a different user profile, you can use it with driftctl with the DCTL_S3_PROFILE (for the profile) and DCTL_S3_REGION (for the S3 bucket region) environment variables.

So, if your AWS profile to access the “mycompany-s3-terraform” S3 bucket is named “s3-terraform” and the different region is “us-west-2”, then the full setup for the environment would look like this:

Next Steps

if you’re interested in discovering more precise authentication options or access policies (like a least-privileged policy), CloudFormation templates, Terraform examples, and more, please consult the driftctl documentation!

Now that you are ready to use driftctl securely, your next step will be to configure your Terraform provider version before you can scan your account for resources not managed by Infrastructure as Code.

Stay in touch

Get product updates and occasional news.