Parte: 10 — Seguridad en la nube y contenedores · Fuente: HashiCorp Terraform docs y OWASP Infrastructure as Code Security ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Aplicar seguridad al código que define la infraestructura. El alumno aprenderá a escanear
configuraciones Terraform en busca de misconfiguraciones (tfsec/Checkov), a proteger el estado
(state) que contiene datos sensibles, a evitar secretos en el código y a integrar estos controles
en el pipeline para detectar problemas antes de desplegar.
Al finalizar, el alumno podrá:
state remoto (cifrado, bloqueo, acceso restringido).plan + escaneo + policy).| # | Tema | Por qué importa |
|---|---|---|
| 1 | IaC y drift | Reproducibilidad y coherencia con lo desplegado |
| 2 | Escaneo estático (tfsec/Checkov) | Detectar misconfig antes de aplicar |
| 3 | Gestión del state | Contiene secretos y estado sensible |
| 4 | Datos sensibles en configuración, plan y state | Comprender cuándo se almacenan, ocultan u omiten |
| 5 | Módulos y proveedores confiables | Cadena de suministro de IaC |
| 6 | Policy-as-code (OPA/Sentinel) | Guardarraíles automáticos |
| 7 | IaC en el pipeline CI/CD | Shift-left de la seguridad de infra |
Terraform compara configuración, state y objetos remotos para producir un plan. Seguridad debe revisar los tres: HCL expresa intención, el plan muestra cambios calculados y el state enlaza direcciones Terraform con objetos reales y atributos. Un escáner que solo lee HCL puede perder valores calculados; una policy sobre plan puede encontrar valores desconocidos hasta apply.
El diagrama incluye dependencias y credencial de ejecución porque el pipeline es parte de la superficie. El archivo .terraform.lock.hcl fija selecciones y hashes de providers, pero actualmente no fija módulos remotos de la misma manera; los módulos requieren versión o referencia inmutable y revisión de origen.
State puede contener contraseñas, claves y metadatos sensibles. Marcar una variable sensitive oculta su presentación en CLI, pero no impide necesariamente almacenarla. Terraform actual incorpora valores ephemeral y argumentos write-only en versiones y providers compatibles; antes de usarlos se comprueba soporte. El backend necesita cifrado, acceso mínimo, locking, versionado, logs y recuperación.
Leer un secreto desde Vault mediante un data source puede escribirlo igualmente en state si un recurso lo conserva. «Usar un vault» no es suficiente: se revisa el flujo completo desde obtención hasta provider, plan, state, logs y recurso final.
tfsec y Checkov aplican reglas sobre configuración; OPA o Sentinel pueden evaluar JSON del plan. Las políticas deben probarse con casos permitidos, denegados y valores desconocidos. Una regla «todo S3 debe ser privado» puede bloquear un sitio público legítimo; la excepción debe tener dueño, alcance y expiración.
terraform plan actualiza estado observado según modo y puede revelar cambios externos, pero la detección depende de credenciales, refresh y recursos gestionados. Un recurso fuera del state no aparece automáticamente como drift del módulo. El pipeline fija Terraform y providers, revisa cambios de lock, usa credenciales OIDC temporales y separa plan de apply con aprobación basada en riesgo.
plan puede revelar cambios de recursos gestionados según refresh, permisos y provider; no inventaría recursos desconocidos.sensitive que sigue en stateUn módulo recibe db_password con sensitive = true. La salida CLI la oculta, pero el provider la conserva en el atributo del recurso y aparece en el state. El equipo confirma el comportamiento sobre un laboratorio, mueve generación y consumo a un mecanismo write-only soportado o rediseña la entrega, y protege versiones previas del backend.
Checkov deja pasar el código después del cambio, pero la verificación no termina allí: se inspecciona el plan JSON, se limita el rol CI, se prueba una policy que bloquea exposición pública y se ejecuta una consulta post-apply. La lección es seguir el dato y el recurso, no confiar en una etiqueta.
Dominas la clase cuando puedes explicar HCL–plan–state–cloud, demostrar qué valor sensible persiste, fijar providers y módulos, escribir una policy con pruebas y límites, y detectar drift declarando recursos y permisos cubiertos.
# Escaneo estático de un directorio Terraform
tfsec .
checkov -d .
# Validar un plan contra políticas OPA
terraform plan -out plan.tfplan && terraform show -json plan.tfplan > plan.json
conftest test plan.json
acl = "public-read", un security group con 0.0.0.0/0 en el puerto 22 y un recurso sin cifrado.tfsec . y checkov -d .; anota los identificadores de cada hallazgo y su severidad..tf.terraform plan.fmt → validate → tfsec/checkov → plan → conftest → (aprobación) → apply. Falla el pipeline si el escaneo encuentra un hallazgo crítico.terraform plan.Toma un repositorio Terraform con misconfiguraciones y déjalo "verde": sin hallazgos críticos en tfsec/Checkov, con state remoto cifrado y bloqueado, sin secretos en el código, y con una policy OPA que bloquea recursos inseguros en el pipeline.
Criterio de aceptación: tfsec y checkov reportan 0 hallazgos críticos/altos, conftest
rechaza un plan que reintroduzca un bucket público, y no hay ningún secreto en texto plano en los
.tf ni en el backend.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
Secreto visible en terraform.tfstate |
El recurso guardó el valor en el state; usa un gestor de secretos y cifra el backend. |
| tfsec pasa pero el recurso sigue inseguro | Regla suprimida con #tfsec:ignore; revisa las supresiones injustificadas. |
Error acquiring the state lock |
Otro apply en curso o lock huérfano; espera o libera con force-unlock con cuidado. |
| Drift no detectado | Cambios fuera de Terraform; ejecuta plan periódicamente y usa detección de drift. |
| Módulo malicioso o desactualizado | Origen no verificado; fija versión y usa fuentes confiables. |
❓ ¿Por qué el state de Terraform es sensible? Porque puede contener valores en texto plano (contraseñas de bases de datos, claves) y el mapa completo de tu infraestructura. Debe cifrarse en reposo, tener acceso restringido y bloqueo para evitar corrupción.
❓ ¿tfsec o Checkov? Ambos son buenos; suelen usarse juntos porque sus reglas no coinciden al 100%. Checkov cubre más frameworks (Terraform, CloudFormation, Kubernetes) y tfsec es muy rápido para Terraform. Ejecuta los dos en CI.
❓ ¿El escaneo estático reemplaza al CSPM? No. El escaneo IaC detecta problemas antes de desplegar (shift-left); el CSPM (clase 231) evalúa lo ya desplegado en tiempo de ejecución, incluyendo cambios hechos fuera de Terraform. Se complementan.
sensitive, ephemeral y write-only, con requisitos de versión.Clase 229 — Kubernetes: hardening y ataques