How Configuration Drift Management Tools Have Evolved Over Time
For as long as developers have been writing software, they have typically allowed the user to customize configuration. Often, these configuration settings are located in a human readable text file format. A .bash_profile containing settings for your bash shell, older Windows programs using an .ini file with application settings, or an Apache web server’s httpd.conf file for web server settings are a few common examples.
In the old days (way back before Y2K) prior to everything being version controlled, often when changes were made to these configuration files (by running an upgrade process, or when using some text editors) a backup copy using the .bak extension was created. Later, if something wasn’t working quite right, you could completely revert back to the previous version, or run a diff to see the revisions and cherry pick the individual changed lines. Conceptually, this was an early version of configuration drift.
Changing focus from an individual application to the entirety of an operating system, a new set of tools helped users to better understand the configuration state of their system as a whole. Tools like Chef or PowerShell DSC were built on the concept of “desired state configurations” where the target configuration was defined “as code”. Running these the tools would set both your OS and its applications to a target state. If something changed in the system, outside the control of these tools , running the tool again would return things to the target state, in effect restoring any configuration drift. These code-based, source configuration files are kept in version control and their history can be considered a text representation of the state of the system over time. A corresponding server-based system is normally in place to monitor version control and through automation, and to orchestrate configuration changes across the entirety of an infrastructure environment.
As cloud infrastructure shifted from IaaS focused workloads to a dependence on PaaS, the ability to install an agent that could execute arbitrary code started to dwindle. As PaaS services needed to be configured using the cloud provider’s control plane APIs, a new class of infrastructure-as-code provisioning tools were developed. Examples include cloud-native tools like AWS CloudFormation and Azure Resource Manager (ARM) Templates, and open source tools like HashiCorp Terraform.
However, these tools have some limitations. According to the blog Detecting and Managing Drift with Terraform, it “cannot detect drift of resources and their associated attributes that are not managed using Terraform”. The AWS CloudFormation Detecting unmanaged configuration changes to stacks and resources documentation states that it only “detects drift on those resources that support drift detection”. At some point, an outside change will happen, potentially on a resource not yet supported by these tools. Now you need to decide how to manage the drift – do you “accept changes” and update your local state to the current configuration of resources, or “reject changes” and roll back to your original deployment?
With the next generation of tools, like OpsCompass, you can manage configuration drift for all workloads, in all cloud accounts, and across multiple cloud providers. They don’t assume that you just have one homogenous system controlling everything. More than likely, your organization has many teams, each choosing their own pipeline and their own toolchain. So, you need a workflow that helps you understand a variety of drift scenarios. If the drift results in a security misconfiguration, then an immediate operational change may be warranted. Rather, if it is just non-compliant with some internal standards, then it can be routed back to the appropriate team and the change can occur within their CI/CD pipeline.
Are you concerned about configuration drift? OpsCompass can help. OpsCompass continuously monitors each cloud resource for configuration drift and against compliance frameworks . A standardized score and consolidated dashboard are provided across multiple cloud platforms including Microsoft Azure, Amazon Web Services (AWS), Microsoft 365, and Google Cloud Platform enabling real-time visibility and drift management for your entire cloud environment.
