Módulo 6: Rollback And Safety Nets

6. Guardrails de `apply`, nombrados

Siguiente →

Descripción

La lección anterior dejó una pieza pendiente: un guardrail automatizado que bloquea una acción peligrosa específica, sin depender de que un humano la note. La lección 7 construye una versión mínima y real de esa pieza. Antes de llegar ahí, esta lección nombra —sin construir— la herramienta que la industria usa para hacer esto a escala: conftest, y el lenguaje de políticas sobre el que se apoya, Rego, el mismo lenguaje de Open Policy Agent (OPA).

Conexión con el módulo

Esta lección es deliberadamente corta y conceptual, con un único propósito: que entiendas la diferencia exacta entre lo que construyes en la lección 7 (un grep artesanal, escrito a mano, para un solo caso concreto) y lo que un sistema de políticas real haría (reglas declarativas, evaluadas contra el plan completo, mantenibles por un equipo entero). Sin esta lección, sería fácil terminar la lección 7 pensando que un grep es "la forma en que se hacen los guardrails" — no lo es, es el primer escalón, honesto sobre sus propios límites.

Qué es conftest, en una frase

conftest es una herramienta de línea de comandos que evalúa un archivo estructurado —en este caso, la salida JSON de terraform show -json que ya conoces desde la lección 5— contra un conjunto de reglas declarativas, escritas en Rego, el lenguaje de políticas de Open Policy Agent. Si alguna regla se viola, conftest falla con un código de salida distinto de cero — exactamente la señal que un step de CI necesita para detener un job, el mismo principio detrás del guardrail que construyes en la lección 7, pero con una maquinaria de evaluación muchísimo más capaz detrás.

   EL GUARDRAIL DE LA LECCIÓN 7                  UN SISTEMA REAL CON conftest

   terraform show -json > plan.json               terraform show -json > plan.json
        │                                               │
        ▼                                               ▼
   grep -oE 'patrón de texto'                      conftest test plan.json
   (escrito a mano, un solo caso)                  (evalúa contra archivos .rego,
        │                                            reglas declarativas, tantas
        ▼                                            como el equipo necesite)
   exit 1 si encuentra "delete"                          │
   sobre Shipments                                       ▼
                                                     exit 1 si CUALQUIER regla
                                                     se viola — extensible sin
                                                     tocar el mecanismo de evaluación

Una regla real, del tipo que un equipo escribiría para el stack de Andes Cargo, podría decir algo tan simple —en Rego, no en un grep— como: "ningún plan puede incluir una acción delete sobre aws_dynamodb_table.shipments, sin importar qué otro cambio la acompañe." Suena parecida al guardrail de la lección 7 porque, en efecto, resuelve el mismo problema — la diferencia está en cómo se expresa esa regla, y en qué tan lejos se puede llevar antes de que el mecanismo se vuelva insostenible.

Por qué un grep no escala, y una política sí

Esta es la razón técnica exacta por la que un sistema real de policy-as-code existe, más allá de "porque suena más profesional":

  • Un grep conoce exactamente un patrón. El de la lección 7 busca, específicamente, "address":"aws_dynamodb_table.shipments" seguido de "actions":[...] con "delete" adentro. Si mañana Andes Cargo quisiera proteger también el bucket contra destrucción, o bloquear cualquier cambio que reduzca permisos de un rol IAM, cada caso nuevo necesitaría su propio patrón de texto, escrito y mantenido a mano.
  • Rego evalúa estructura, no texto. Una política de Rego no busca una cadena de caracteres en un archivo plano — recorre el JSON como una estructura de datos real, con acceso completo a cualquier campo, cualquier condición, cualquier combinación de reglas ("bloquea si se destruye A, salvo que también se esté creando B en el mismo plan", por ejemplo) — expresividad que un grep de texto no puede alcanzar sin volverse frágil.
  • Un conjunto de políticas es código versionado, propio del equipo de seguridad. En un sistema maduro, las reglas de Rego viven en su propio repositorio (o directorio), revisadas, probadas, con su propia disciplina de cambio — no un script suelto dentro de un step de ci.yml, mantenido por quien haya tenido tiempo de tocarlo por última vez.

Dónde se construye esto de verdad: cloud-security-and-guardrails-guide

Esta guía nombra conftest y policy-as-code aquí, deliberadamente, sin construir ningún sistema de políticas. Escribir reglas de Rego, integrarlas a un pipeline de CI/CD, decidir qué políticas bloquean el apply y cuáles solo advierten, y diseñar la gobernanza de quién puede aprobar una excepción, es una disciplina completa por derecho propio — exactamente el terreno de cloud-security-and-guardrails-guide, la guía hermana que retoma este punto exacto y lo desarrolla de punta a punta, con el mismo plan de Terraform de Andes Cargo como entrada.

Lo que esta guía te deja, en cambio, es la pregunta correcta y el mecanismo mínimo que la responde: si ya sabes leer un plan en JSON lo suficientemente bien como para escribir un grep que detecte una acción peligrosa concreta —lo que haces en la lección 7—, ya tienes la mitad del trabajo hecho para entender qué evalúa una política de Rego cuando la escribas de verdad.

Errores comunes

Buscar un archivo .rego dentro de andes-cargo-infra/ después de esta lección (de expectativa). Qué pasa: alguien, después de leer sobre conftest, busca un directorio policy/ o algún archivo de reglas dentro del proyecto de esta guía. Cómo detectarlo: si buscas sintaxis de Rego en cualquier archivo de este repositorio. Cómo corregirlo: esta guía, por diseño, nombra conftest sin construir ningún sistema de políticas — el mecanismo real que sí construyes está en la lección 7, y es deliberadamente más simple (un grep, no una política declarativa).

Pensar que el grep de la lección 7 es "una versión mala de conftest" que hay que evitar (conceptual). Qué pasa: alguien concluye que, como conftest es superior en capacidad, el grep de la lección 7 es un error de diseño de esta guía. Cómo corregirlo: el grep no es un intento fallido de construir conftest — es, a propósito, el escalón anterior: el patrón mínimo real, honesto sobre su propio límite, que te deja exactamente en el punto de partida correcto para entender por qué la industria construyó algo más capaz después. Ambas cosas son legítimas en su lugar: un grep artesanal para un caso puntual, aprendido aquí; una política declarativa para un sistema completo, aprendida en cloud-security-and-guardrails-guide.

Ejercicios

Ejercicio 1 — Escribe, en prosa, la regla de Rego que protegería el bucket de Andes Cargo. Sin escribir código Rego real —esa disciplina completa vive en la guía hermana—, describe en una frase la condición exacta que un equipo de seguridad querría automatizar para el bucket andes-cargo-shipment-docs.

Ver solución

Una regla razonable, en prosa: "Si el plan incluye una acción delete sobre module.shipment_docs_bucket.aws_s3_bucket.this, o cualquier cambio que desactive enable_versioning, el pipeline falla y el Pull Request no puede fusionarse sin una aprobación explícita adicional de alguien fuera del equipo que propuso el cambio." El punto del ejercicio no es la sintaxis exacta de Rego, es confirmar que ya sabes identificar, en prosa, la condición precisa que una política automática debería vigilar — el mismo tipo de razonamiento que ya practicaste en terraform-and-iac-guide, Módulo 8.

Ejercicio 2 — Explica, sin usar la palabra "mejor", por qué Rego resuelve un problema que un grep no puede resolver bien. A un colega que pregunta "¿para qué complicarse con un lenguaje nuevo si el grep ya funciona?".

Ver solución

Una respuesta completa suena, más o menos, así: "El grep funciona perfectamente para exactamente un patrón, escrito a mano — el problema aparece cuando el equipo necesita más de una regla, o reglas que dependen de combinaciones de condiciones (por ejemplo, 'bloquea esta destrucción, salvo que el mismo plan también esté creando un reemplazo válido'). Escribir eso como texto plano con grep se vuelve fragil rápido — cualquier cambio en el formato del JSON, o cualquier condición nueva, obliga a reescribir el patrón desde cero. Rego evalúa el JSON como una estructura de datos real, no como texto, así que puede expresar condiciones arbitrariamente complejas sin que el mecanismo de evaluación en sí cambie — cada regla nueva es un archivo .rego más, no una reescritura del motor completo."

Ejercicio 3 — Ubica la frontera exacta entre este módulo y cloud-security-and-guardrails-guide, en tus propias palabras. Sin volver a leer esta lección, describe en dos frases qué sí construyó este módulo sobre guardrails, y qué queda explícitamente para la guía hermana.

Ver solución

Este módulo construye un guardrail mínimo, real y ejecutado (lección 7): un grep artesanal sobre el plan en JSON, que bloquea un caso concreto y bien definido (destruir la tabla Shipments), demostrado con act de punta a punta. Lo que queda para cloud-security-and-guardrails-guide es el sistema completo de policy-as-code: reglas declarativas en Rego, evaluadas con conftest, con su propia disciplina de gobernanza sobre qué falla el build, qué solo advierte, y quién puede aprobar una excepción — la capacidad de expresar cualquier política, no solo el único caso que esta guía nombra por su nombre.

Resumen y siguiente paso

En esta lección nombraste conftest y Rego/Open Policy Agent como el mecanismo real de la industria para evaluar un plan de Terraform contra políticas declarativas, y entendiste la diferencia exacta entre eso y el grep artesanal que construyes en la lección siguiente: expresividad, estructura versus texto, y una disciplina de gobernanza completa que esta guía no construye. cloud-security-and-guardrails-guide es donde ese sistema completo se construye de punta a punta.

Antes de avanzar deberías poder: explicar qué es conftest y qué evalúa; nombrar al menos dos razones concretas por las que una política declarativa escala mejor que un grep; y ubicar con precisión la frontera entre este módulo y la guía hermana.

La lección 7 —manos a la obra— construye el guardrail real de esta guía: un chequeo mínimo, honesto sobre su propio límite, que bloquea de verdad un intento de destruir la tabla Shipments.

Recursos

  1. Open Policy Agent — Documentación oficial — el motor de políticas (Rego) sobre el que se construye conftest.
  2. Conftest — Documentación oficial — la herramienta nombrada en esta lección, incluidos ejemplos de políticas sobre terraform plan.
  3. Terraform Docs — Command: show — el comando que produce la salida JSON que tanto conftest como el guardrail de la lección 7 evalúan.
  4. terraform-and-iac-guide, Módulo 8, lección 4 — la primera mención de conftest en esta familia de guías, con el mismo patrón de "nombrar sin construir".
← Anterior5. ¿Un pipeline hubiera detenido el incidente de Claude Code?Siguiente →7. Manos a la obra: un guardrail mínimo, real y ejecutado