🎯 Terraform Configuration Drift: Detección, Remedación y Mejores Prácticas

El Configuration Drift (desvío o desfase de configuración) ocurre cuando el estado real de los recursos desplegados en la nube diverge del estado deseado definido en tus archivos de código HCL de Terraform o en el archivo de estado (terraform.tfstate).

1. ¿Qué es el Configuration Drift?

Terraform opera bajo un modelo declarativo. El ciclo de vida ideal de Terraform presupone una coincidencia entre 3 entidades clave:

• Código HCL (Desired State): Lo que declaras en tu repositorio Git.
• Terraform State (Known State): El mapa de metadatos en .tfstate que relaciona tus recursos HCL con las APIs del proveedor.
• Infraestructura Real (Actual State): Lo que verdaderamente está corriendo en AWS, Azure, GCP o Kubernetes.

El Drift se manifiesta cuando la Infraestructura Real es modificada directamente o cuando cambios externos rompen el equilibrio entre estas 3 capas.

2. Causas Principales del Configuration Drift

1. Intervenciones Manuales (Hotfixes): Ingenieros haciendo clic en la consola web de AWS/Azure para solucionar una emergencia de medianoche y olvidando plasmarlo en código HCL.
2. Servicios Automatizados / Auto-scaling: Herramientas externas (Karpenter, AWS Autoscaling, políticas de parches) modificando parámetros como recuento de instancias o tamaños de volumen sin conocimiento de Terraform.
3. Actualizaciones del Proveedor Cloud: Cambios automáticos aplicados por el proveedor de nube en configuraciones por defecto, versiones de motor de base de datos o rotación de certificados.
4. Múltiples Backends / Conflictos de Equipos: Cambios realizados desde máquinas locales con versiones viejas de código o estados no sincronizados.

3. Cómo Detectar Configuration Drift en Terraform

A. Detección con terraform plan (Modo estándar)

Por defecto, cuando ejecutas terraform plan, Terraform refresca el estado consultando la API del proveedor de nube y calcula las diferencias respecto a tu código local HCL.

# Refresca el estado y muestra las desviaciones respecto al código HCL
terraform plan

B. Detección sin modificar código (-refresh-only)

Introducido en Terraform 0.15+, el flag -refresh-only permite inspeccionar la infraestructura real y actualizar el archivo de estado tfstate con los cambios externos sin forzar la modificación o destrucción de la infraestructura real inmediatamente.

# Crea un plan enfocado únicamente en actualizar el state para reflejar la realidad
terraform plan -refresh-only

# Aplica la actualización del archivo state si las desviaciones externas son aceptadas
terraform apply -refresh-only -auto-approve

C. Drift Detection Automático en CI/CD (Scheduled Pipelines)

Configura un Job de GitHub Actions, GitLab CI o Cron en Terraform Cloud que ejecute terraform plan -detailed-exitcode periódicamente (ejemplo: todas las noches a las 02:00 AM).

# Exit code 0 = Sin cambios (Sincronizado)
# Exit code 1 = Error de ejecución/API
# Exit code 2 = Drift detectado (Hay diferencias)
terraform plan -detailed-exitcode -no-color

if [ $? -eq 2 ]; then
  echo "🚨 CRITICAL: Configuration Drift detectado en la infraestructura!"
  # Enviar alerta a Slack / PagerDuty
fi

4. Estrategias de Remedación

Una vez detectado un desvío de configuración, existen dos caminos según la legitimidad del cambio:

Opción A: Revertir el Drift (Restaurar el estado deseado HCL)

Si la modificación manual realizada en la consola fue un error o un cambio no autorizado, simplemente ejecuta un plan y apply normal. Terraform sobrescribirá el cambio manual para alinear la nube con el código HCL.

terraform apply

Opción B: Aceptar e Importar el Cambio al Código (Alinear HCL)

Si el cambio manual hecho en la nube durante la emergencia era necesario y debe conservarse:

1. Ejecuta terraform plan -refresh-only para actualizar el tfstate.
2. Modifica tu código .tf en HCL para incorporar los nuevos parámetros.
3. Ejecuta terraform plan para confirmar que ya no existen diferencias acumuladas ("No changes. Infrastructure is up-to-date.").

Opción C: Ignorar Cambios Dinámicos Legítimos (ignore_changes)

Para campos gestionados externamente por Auto Scaling, etiquetas de auditoría o parches automatizados, utiliza el meta-argumento lifecycle:

resource "aws_autoscaling_group" "app" {
  name                 = "app-asg"
  min_size             = 2
  max_size             = 10
  desired_capacity     = 4 # Este valor cambia dinámicamente según la carga

  lifecycle {
    # Evita que Terraform sobrescriba la capacidad deseada calculada por AWS Autoscaler
    ignore_changes = [
      desired_capacity,
      tags["LastScanned"],
    ]
  }
}

5. Cómo Prevenir el Drift (Mejores Prácticas)

• 1. Restringir Permisos de IAM (Read-Only Console): Aplica el principio de mínimo privilegio. Los ingenieros deben tener acceso de solo lectura en la consola web y canalizar cualquier cambio mediante Pull Requests en Git.
• 2. Implementar GitOps & CI/CD Estricto: Ningún miembro del equipo debe ejecutar terraform apply desde su terminal local. Toda modificación debe pasar por revisión de código (Peer Code Review) y ejecutarse mediante runners automatizados.
• 3. Bloqueo de Estado Remoto (State Locking): Utiliza siempre backends remotos con soporte de lock (AWS S3 + DynamoDB, Azure Blob Storage, HCP Terraform) para impedir ejecuciones concurrentes que corrompan el estado.
• 4. Scheduled Drift Scans: Automatiza trabajos nocturnos de escaneo de drift que generen alertas en Slack, Teams o PagerDuty cuando se detecte una discrepancia.
• 5. Uso de SCPs (Service Control Policies): En AWS Organizations o Azure Management Groups, bloquea la capacidad de modificar recursos clave fuera de los roles asignados a los pipelines de CI/CD.

6. Herramientas Especializadas para Gestión de Drift