Configuring Drift Detection

Configuration drifts are a horrible experience for everyone involved in detecting, analyzing, and reconciling these drifts, especially if they happen in Production. Cloudrail’s Drift Detection makes that experience a lot simpler with auto-detection and ticketing integration.

Using Cloudrail’s unique approach of scanning your Infrastructure-as-Code with the context of your existing live state, Cloudrail has the ability to transparently identify configuration drifts on your behalf.

We’ll first describe how it works, then proceed with how to review drifts in the UI.

How it works

Cloudrail’s Drift Detection feature works simply by running a Static + Dynamic assessment as you normally would. You will just need to include the flag “–drift-track”. This is because the Static + Dynamic assessment has all the information necessary to determine a configuration baseline. However, it is important to understand how a configuration baseline is determined, which we will expand in the following example:

  1. A team wants to deploy an RDS instance in their AWS environment. Before deploying, they will run Cloudrail in Static + Dynamic mode.
  2. Upon running an assessment, Cloudrail will identify that the RDS has not been deployed yet. According to Terraform Plan, Terraform has not determined that the RDS instance has been deployed, so it is not included in the Terraform state file.
  3. The team fixes all security violations found by Cloudrail and proceeds to deploy the RDS instance (using “apply”).

At this point, Cloudrail will not consider the RDS instance as part of its configuration baseline. Why? Because the Terraform plan file Cloudrail received indicates that the RDS instance has not been deployed (remember, Cloudrail got the plan before apply). So at this point, Cloudrail will not consider the deployed RDS instance as part of its configuration baseline.

In order for Cloudrail to factor the RDS instance into its configuration baseline, there are two approaches: Running another assessment post-deployment or waiting for the next deployment.

Post-Deployment method

In the above scenario, if the user runs another Static + Dynamic assessment immediately after deployment, the user’s Terraform statefile will reconcile that the RDS instance is now managed as part of the Terraform environment. The Terraform plan will now show the RDS instance as being deployed, with its ARN. By doing so, Cloudrail can factor the RDS instance as part of its configuration baseline for the user and track the RDS instance for configuration drifts.

So to explain, this would be the series of steps:

  • Run “terraform plan -out=plan.out” on the new code.
  • Pass the plan.out to cloudrail, resolve any issues found (and generate a new plan).
  • Pass the plan.out to “terraform apply” for the resource to be deployed.
  • Run another “terraform plan -out=plan.out”, and pass it to Cloudrail again for analysis.

Note: this method can be scheduled as a nightly scan or as a step in the user’s CI pipeline immediately after running “terraform apply”.

Pro’s:

  1. Immediate configuration baseline at the time of deployment.
  2. Works well for organizations that do not deploy frequently.

Con’s:

  1. Requires 1 additional Cloudrail assessment per scan to factor configuration base-lining.

Waiting for the Next Deployment method

This method is rather simpler. In the above scenario, let us assume that the team follows a GitOps model and deploys multiple times to their live environment daily. With increased frequency, Cloudrail will likely factor the RDS instance as part of its configuration baseline within hours of the initial RDS deployment.

Pro’s:

  1. No new configuration is needed for Cloudrail to properly handle configuration baselining.
  2. Works very well for teams that follow GitOps, deploy multiple times daily (or even weekly), and therefore run Cloudrail Static + Dynamic assessments often.

Con’s:

  1. If the team does not deploy regularly, Cloudrail’s configuration baseline will lag behind the latest state of your IaC resources. This can result in missed configuration drifts.

Summarizing the two methods

We have found that many organizations are using Terraform with differing deployment models. Ultimately, one method will better fit one deployment model over another for users. The main deciding factor is the frequency in which the team anticipates that they would run multiple Cloudrail assessments daily.

Once the user determines the right method, Drift Detection is automatically handled on the user’s behalf and can be reviewed through Cloudrail’s web app.

Exploring Drifts in the UI

  1. Login to the Cloudrail web app at https://web.cloudrail.app
  2. Select the “Drift Detection” tab next to “Cloud Management

3. Review all your cloud accounts to see if any of them have drifted. You can also use the search to look for a specific cloud account:

4. You can drill down into a specific drift by selecting an account and reviewing the drift details. In the following configuration drift example, it appears that additional roles were granted access to an AWS Secrets Manager in a dev environment and was not handled in Terraform:

5. You can use Cloudrail’s native Jira Ticket integration to open a ticket and assign to the developer responsible for this environment:

This image has an empty alt attribute; its file name is image-6-1080x990.png