Políticas en la canalización y excepciones

Un analizador de políticas puede mirar el código HCL, el plan en JSON o los dos. Mirar el plan tiene una ventaja: ve valores ya resueltos —variables, módulos, expresiones— que en el código son solo referencias. Para que sea un control y no un aviso, el escaneo va antes de aplicar y su resultado condiciona el paso siguiente: un fallo detiene el cambio hasta que se corrige o se aprueba una excepción documentada. La aprobación humana va después del escaneo, para que la persona decida con el informe en la mano.

Un escaneo que corre pero no puede detener nada documenta los fallos; no los previene.

Abre pipeline.yml. Las etapas están en un orden razonable: formato, validación, plan, escaneo, aprobación y aplicación. Pero una de las claves de la etapa de escaneo cambia lo que significa: dice si la canalización continúa aunque el escaneo falle. Con ese valor, la aprobación humana pasa a ser la única barrera, y la persona que aprueba suele fiarse de que el escaneo ya filtró. El nombre exacto de esa clave es lo que va al informe.

Los analizadores de políticas de código abierto, como Checkov, imprimen un bloque por cada regla: un identificador, el nombre de la regla, el resultado y el recurso afectado, y arriba un resumen con aprobadas, falladas y omitidas. Cada identificador se mantiene estable y permite buscar en la documentación del analizador qué comprueba y cómo se corrige. El informe del PR-215 tiene cuatro reglas falladas; una de ellas habla de que los datos de una base de datos relacional no deberían ser accesibles públicamente.

Una excepción es una decisión consciente de aceptar un fallo, y solo vale si tiene tres cosas: un dueño que responde, un motivo y una fecha de vencimiento. Sin la fecha, la excepción se vuelve permanente y el control, decorativo. El registro de excepciones de Alisio tiene tres filas; la fecha de referencia es la del escaneo, el 2 de octubre de 2026. Una excepción cuya fecha es anterior a esa ya no ampara nada, y quien la pidió debe renovarla o corregir el recurso.

Las políticas propias de una empresa se escriben como código, y Rego —el lenguaje del proyecto Open Policy Agent— es una de las formas habituales de evaluar el plan en JSON. Una regla deny se activa cuando todas sus condiciones se cumplen sobre las entradas del plan, y devuelve un mensaje; si hay mensajes, el cambio se bloquea. Leer la regla de politica.rego dice qué protege realmente: qué tipo de recurso mira, qué valor busca y a qué lo compara.