Terraform en CI/CD: planes revisables y credenciales que caducan

Mover Terraform a CI no elimina riesgo; cambia quién puede iniciar una ejecución, dónde viven las credenciales y qué evidencia queda. Un pipeline útil no es un shell remoto con auto-approve. Es una máquina de estados que separa propuesta, revisión, autorización y cambio.

OpenTofu describe el plan especulativo como artefacto de colaboración antes del merge y advierte que el plan concreto posterior puede diferir por orden de merges o cambios manuales. [1]

Dos carriles, dos permisos

El job de PR necesita leer configuración y, según el entorno, quizá consultar state o APIs. No debería escribir producción. El job de apply sí escribe, por lo que exige rama protegida, entorno aprobado, exclusión mutua y una identidad distinta. Esta separación limita el daño de un pull request malicioso o de un token filtrado en logs.

Credenciales largas: el atajo que se convierte en inventario

Guardar una access key como secreto del repositorio parece práctico hasta que toca rotarla, atribuir su uso o limitarla a una ejecución. El patrón preferible es federar la identidad del runner con el proveedor mediante OIDC y emitir credenciales de corta vida con claims acotados: repositorio, branch, environment, workflow y audiencia.

En HCP Terraform, las credenciales dinámicas establecen una relación OIDC y generan credenciales únicas por run; el proveedor recibe contexto del workload y devuelve permisos temporales. [2]

La propiedad general es la federación efímera; los nombres de variables y claims concretos dependen del sistema CI y del proveedor cloud. No copies una receta de AWS en Azure ni atribuyas al CLI una capacidad que pertenece a HCP Terraform.

La matriz mínima de permisos

La decisión de autorización se toma por intención y entorno: el job de PR observa, el job de apply modifica y break-glass recupera. Se descarta una identidad compartida porque vuelve imposible acotar permisos, atribuir una ejecución y revocar solo el carril comprometido.

Concurrencia: el lock del backend no basta

El backend protege state, pero el pipeline también debe agrupar ejecuciones por stack y entorno. Si dos jobs compiten, uno puede esperar el lock durante veinte minutos y aplicar un commit que ya no es el último. Usa una clave de concurrencia estable, cancela planes obsoletos y nunca canceles a ciegas un apply que ya está hablando con el provider.

Cada ejecución debe registrar:

• commit exacto y digest del plan;
• identidad federada y claims relevantes;
• backend/workspace objetivo;
• versión del CLI y lockfile;
• aprobador y policy result;
• recursos cambiados;
• smoke check y ruta de rollback/forward fix.

Artefactos y logs también son superficie secreta

Un plan guardado, state, variables, output JSON y logs del provider pueden contener endpoints, IDs o secretos. La regla “está en CI, por tanto está seguro” no sirve. Define retención corta, cifrado, acceso por rol, redacción de logs y prohibición explícita de publicar planes completos como comentarios públicos.

Fallo realista: plan verde, apply rojo

El PR muestra cero reemplazos. Antes del merge, otro equipo cambia el mismo stack. El apply vuelve a planear y detecta un replacement, pero el job ejecuta -auto-approve porque “el PR ya fue aprobado”. El remedio es aprobar el artefacto concreto o bloquear clases de cambio de alto riesgo mediante policy. Aprobación de código y autorización de acciones no son el mismo evento.

Vincular identidad, revisión y artefacto

OIDC elimina la credencial larga, pero no corrige por sí solo una política amplia. El proveedor cloud debe validar issuer, audience, repositorio, ref y entorno esperado. Una identidad emitida para un pull request no debería asumir el rol de producción; una ejecución desde un fork tampoco. Mantén la relación entre claims y permisos en código revisable, y prueba explícitamente los casos negativos.

El plan que recibe aprobación necesita identidad propia. Guarda el hash del archivo, la versión de Terraform u OpenTofu, los providers bloqueados y el serial del state observado. Antes de aplicar, comprueba que ese conjunto sigue vigente. Si el pipeline vuelve a planear porque cambió el state, el nuevo artefacto requiere una nueva evaluación; reutilizar la aprobación anterior rompe la cadena de evidencia.

Separa además el permiso de desbloquear state, modificar políticas o leer secretos. Son capacidades de recuperación, no tareas normales de apply. El camino feliz debe funcionar sin ellas, y su uso debe dejar una señal más fuerte que un log perdido entre cientos de líneas.

Registra expiración de la sesión y correlaciona su identidad con commit, job y entorno. Esa unión permite responder quién autorizó qué artefacto sin conservar una llave permanente.

La auditoría debe conservar esa correlación más tiempo que las credenciales efímeras.

Contrato de lab

Construye un pipeline local o sandbox sin cloud real y demuestra:

• job de PR incapaz de ejecutar apply;
• claims OIDC simulados vinculados a branch/environment;
• plan y apply con identidades distintas;
• concurrencia por stack;
• artefactos con expiración y acceso restringido;
• policy que bloquea reemplazos y recursos fuera de allowlist;
• smoke check y cleanup siempre ejecutados.

Conexiones dentro de la serie

• Antes: Testing, planes y políticas.
• Después: Drift, import y recuperación.
• Base operativa: scripting defensivo y comprensión de procesos CI; la guía específica de Bash permanece en revisión.
• Lab relacionado: Terraform lab network, útil para practicar el carril de plan sin credenciales cloud.