Infrastructure as code (IaC) templates simplify the provisioning of cloud infrastructure. In combination with a version control system (VCS), IaC enables key operational and security capabilities of GitOps, such as versioning, collaboration, auditing, repeatability, and templatizing.
However, those benefits are lost if updates and modifications are made in the cloud directly when fixing misconfigurations, during “break glass” moments when an incident occurs, or due to permissions issues where Ops teams don’t have access to the code, or when a cloud provider changes the API for services you use.
Drift can happen in many scenarios and for various reasons. For example, Operations teams may be trying to fix a customer-impacting issue and, in a panic, drop security standards like requiring HTTPS. When the incident passes, they may forget to go back and fix it, leaving traffic open to man-in-the-middle attacks.
However, drift is often introduced with good intentions. An SRE notices an S3 bucket is unencrypted, doesn’t have permission to edit the code, and doesn’t know the code owner. So, they encrypt the bucket from the cloud console but not in the IaC template that provisioned the bucket. This action introduces drift.