Módulo 5: Securing The Ai Workload

1. Introducción: el gate ya existe, esta carga entra a él

Descripción

ADR-001-llm-as-escalation-path.md (Módulo 1) tiene una fila con el nombre exacto de este módulo: "M5 — Securing the AI workload | Extends the inherited security gate to the escalation path's new Terraform, least privilege scoped to one model ARN". Fíjate en el verbo: extends, no builds. Este módulo no construye ningún mecanismo de seguridad nuevo — toma el security gate completo que cloud-security-and-guardrails-guide ya diseñó, probó y dejó corriendo en verde (policy-check, iac-scan, verify-artifact, encadenados en ci.yml con act pull_request), y confirma que ese mismo gate, sin ningún cambio a su propia maquinaria, evalúa correctamente el Terraform y el artefacto que este módulo específico agrega: bedrock.tf, modules/bedrock-guardrail/, y el .zip de extract-shipment-manifest-fields.

Conexión con el módulo

Los Módulos 3 y 4 de esta guía construyeron dos piezas de infraestructura de IA reales: BedrockManifestExtractorRole (Módulo 3, lección 4), con bedrock:InvokeModel acotado al ARN de un único modelo; y el guardrail gestionado completo de Bedrock (Módulo 4), con sus seis mecanismos declarados en HCL. Ninguna de las dos piezas, hasta este punto, había pasado por ningún control automático — se verificaron a mano, leyendo la salida de terraform plan. Este módulo cierra esa brecha: el mismo rol y el mismo Terraform entran, por primera vez, al gate que cloud-security-and-guardrails-guide ya construyó para todo el proyecto andes-cargo-infra/.

Analogía: un paquete nuevo por el mismo escáner del aeropuerto

Un aeropuerto no construye un escáner de rayos X distinto para cada tipo de equipaje nuevo que empieza a circular por sus cintas. El mismo escáner, con las mismas reglas —¿hay algo metálico donde no debería?, ¿la forma de este objeto coincide con algo prohibido?—, revisa una maleta de ropa, una caja de electrónica, o un paquete que nadie había visto pasar por ahí antes. Lo que cambia no es el escáner: es el contenido que entra a revisión. Si el escáner está bien calibrado, detecta un problema real sin que nadie tenga que reconfigurar la máquina para "el tipo de paquete de hoy".

El security gate de cloud-security-and-guardrails-guide es ese escáner. policy-check evalúa cualquier plan de Terraform contra la biblioteca policy/, sin que le importe si el recurso nuevo es un bucket S3, una tabla DynamoDB, o —como en este módulo— un rol IAM que invoca un modelo de Bedrock. iac-scan corre trivy config contra cualquier archivo .tf del proyecto, sin una lista de excepciones para "archivos de IA". verify-artifact verifica cualquier .zip contra su firma, sea el de process-shipment-manifest o el de extract-shipment-manifest-fields. Construir un escáner nuevo para el equipaje de IA —un cuarto job, una herramienta distinta— sería repetir trabajo que ya funciona, y peor: crearía dos estándares de seguridad donde debería haber uno solo.

Qué hereda este módulo, sin reinstalar nada

Antes de la primera línea de código nueva, vale la pena decir con precisión exacta qué existe ya, corrido y verificado por cloud-security-and-guardrails-guide, y que este módulo usa tal cual:

   LO QUE YA EXISTE (cloud-security-and-guardrails-guide)          LO QUE ESTE MÓDULO AGREGA

   policy/
   ├── no-destroy-shipments.rego        (M4.6)          →    policy/bedrock-least-privilege.rego
   ├── least-privilege-iam.rego         (M4.7)                (lección 3 -- un archivo más,
   └── no-public-buckets.rego           (M4.7)                 mismo directorio, mismo package main)

   conftest 0.69.0 / OPA 1.19.0         (M4.3)          →    sin cambios -- se reusa el binario
   Trivy 0.74.0                         (M5.3)          →    sin cambios -- se reusa el binario
   cosign v3.1.3, cosign.key/cosign.pub (M6.5)          →    sin cambios -- se reusa el keypair

   .github/workflows/ci.yml
   ├── policy-check   (M8.3)                            →    sin job nuevo -- bedrock.tf entra
   ├── iac-scan       (M8.3)                                  al mismo plan/scan que ya corre
   └── verify-artifact (M8.3)                           →    un step más, mismo job, verifica
                                                                el .zip del extractor también

Ni un binario nuevo que instalar, ni una versión distinta que fijar, ni un job nuevo que agregar al pipeline. conftest --version sigue reportando Conftest: 0.69.0 / OPA: 1.19.0 — la misma versión que cloud-security-and-guardrails-guide, Módulo 4, lección 3 ya confirmó. trivy --version sigue en 0.74.0. cosign version sigue en v3.1.3, con el mismo cosign.key/cosign.pub generado en esa guía, Módulo 6, lección 5 — nunca un keypair nuevo para esta guía. Si en algún punto de este módulo ves un comando de instalación, es una señal de que algo salió mal: la disciplina dura de este módulo es que cero herramientas se instalan de nuevo.

El mapa de este módulo: las 8 lecciones

   M5 -- SECURING THE AI WORKLOAD

   1  Introducción                        el gate ya existe, esta carga entra a él (esta lección)
   2  Mínimo privilegio para un modelo     retoma el rol del M3.4, bedrock:* como antipatrón
   3  Manos a la obra: la política nueva   bedrock-least-privilege.rego, PASS/FAIL reales
   4  Por qué Bedrock no necesita API key  contraste con la mayoría de las APIs de LLM
   5  Manos a la obra: Trivy               trivy config sobre bedrock.tf + el módulo nuevo
   6  Manos a la obra: firmando con cosign el .zip del extractor, firmado y verificado
   7  STRIDE revisitado                    dos filas nuevas en THREAT-MODEL.md
   8  Proyecto: el gate extendido          los 3 jobs, con lo nuevo incluido, verde de punta a punta

#	Lección	Qué se ejecuta/practica
1	Introducción (esta)	Qué hereda este módulo de `cloud-security-and-guardrails-guide`, sin reinstalar nada
2	Mínimo privilegio para un modelo, no para un servicio	Retoma `BedrockManifestExtractorRole` (M3.4); `bedrock:*` como antipatrón nombrado
3	Manos a la obra: `bedrock-least-privilege.rego`, agregada a `policy/`	Ejecutado: `conftest test tfplan.json -p policy/bedrock-least-privilege.rego` — `PASS` real sobre el rol correcto, `FAIL` real sobre `bedrock:*`
4	Por qué Bedrock no necesita una API key	Conceptual — IAM firma la llamada, ninguna gestión de secreto nueva en esta guía
5	Manos a la obra: Trivy sobre el Terraform nuevo	Ejecutado: `trivy config` sobre `bedrock.tf` + `modules/bedrock-guardrail/`
6	Manos a la obra: firmando el artefacto del extractor con `cosign`	Ejecutado: `sign-blob`/`verify-blob` reales, mismo keypair, cero reinstalación
7	STRIDE, revisitado	Dos filas nuevas en `THREAT-MODEL.md`: `TM-08` (tampering del prompt), `TM-09` (fuga de PII)
8	Proyecto: el security gate de Andes Cargo, extendido	Ejecutado: los 3 jobs existentes, `act pull_request`, verde de punta a punta, sin job nuevo

Por qué "extender", no "reconstruir", es la disciplina de este módulo

Hay una tentación real, y vale la pena nombrarla antes de que aparezca: alguien que llega a este módulo, viendo que Bedrock es "distinto" —un modelo no determinista, una API nueva, un dominio que se siente especial— podría pensar que necesita su propio job de CI, su propia herramienta de escaneo, su propio flujo de firma. Ninguna de las tres cosas es cierta. policy-check no le importa si el recurso que evalúa es un bucket o un rol de Bedrock: lee resource_changes del plan, y aplica reglas contra la estructura JSON, sea cual sea el type del recurso. iac-scan no distingue "Terraform de IA" de "Terraform de negocio": escanea cualquier archivo .tf que encuentre en el proyecto. verify-artifact no verifica "artefactos normales" de forma distinta a "artefactos de IA": cosign verify-blob firma y verifica bytes, sin ningún conocimiento de qué hace el código adentro del .zip.

Esta es, en los hechos, la prueba más fuerte de que un security gate está bien diseñado: generaliza a un dominio que nadie tenía en mente cuando se construyó. cloud-security-and-guardrails-guide nunca mencionó Bedrock, IA generativa, ni modelos de lenguaje en ninguna de sus ocho lecciones — y sin embargo, su gate evalúa correctamente la infraestructura de IA de este módulo sin necesitar ni una línea de código nueva en su propia maquinaria. Todo lo nuevo de este módulo vive en el contenido que pasa por el gate (bedrock.tf, la política bedrock-least-privilege.rego, el .zip del extractor), nunca en el gate mismo.

Errores comunes

Proponer un cuarto job (bedrock-scan, ai-security-check) "porque Bedrock es especial" (de sobre-ingeniería, el error central que este módulo previene). Qué pasa: alguien, acostumbrado a que cada módulo nuevo de esta guía agregue una pieza nueva de infraestructura, asume que este módulo también debería agregar una pieza nueva de CI. Cómo detectarlo: si tu plan para este módulo incluye un job nuevo en ci.yml, en vez de un step nuevo dentro de un job ya existente, o ningún cambio al ci.yml en absoluto. Cómo corregirlo: la lección 8 de este módulo confirma, con una corrida real de act pull_request, que los tres jobs existentes —sin ningún cuarto job— bastan para evaluar el Terraform y el artefacto nuevos. Si sientes la tentación de un job nuevo, vuelve a esta lección: el punto entero del módulo es que el gate ya generaliza.

Asumir que "reusar el gate" significa que este módulo no escribe ningún código nuevo (de subestimar el trabajo real). Qué pasa: alguien lee "no reconstruyas nada" y concluye que este módulo es puro repaso, sin ningún artefacto nuevo que producir. Cómo detectarlo: si terminas este módulo sin haber escrito policy/bedrock-least-privilege.rego. Cómo corregirlo: "reusar el gate" significa reusar la maquinaria —conftest, Trivy, cosign, los tres jobs de ci.yml—, no significa que no haya nada nuevo que ese gate evalúe. La lección 3 escribe una política Rego real, nueva, específica de Bedrock; la lección 6 firma un artefacto real, nuevo, que nunca existió en las guías anteriores. Lo que no se reconstruye es el motor; lo que sí se construye es lo que ese motor examina.

Pensar que, porque conftest/Trivy/cosign ya estaban instalados por otra guía, no hace falta confirmar que siguen funcionando aquí (de asumir sin verificar). Qué pasa: alguien, confiando en que "ya se instalaron en cloud-security-and-guardrails-guide", no vuelve a correr conftest --version/trivy --version/cosign version en este entorno específico. Cómo detectarlo: si tu primera corrida real de conftest test en la lección 3 es también la primera vez que confirmas que el binario existe en tu PATH. Cómo corregirlo: "reusado, no reinstalado" significa que no vas a descargar un binario nuevo ni fijar una versión distinta — no significa que saltes la verificación. Cada lección "manos a la obra" de este módulo confirma, con el comando real, que la herramienta responde antes de usarla para algo nuevo.

Ejercicios

Ejercicio 1 — Sin mirar el resto de este módulo, enumera los tres jobs del security gate heredado, en el orden exacto en que needs: los encadena. Después, verifica tu respuesta contra el diagrama de arriba.

Ver solución

policy-check (sin needs:, corre primero) → iac-scan (needs: policy-check) → verify-artifact (needs: iac-scan). El orden no es arbitrario: sigue el criterio de costo creciente que cloud-security-and-guardrails-guide, Módulo 8, lección 2 ya estableció — evaluar la política más barata primero, la firma criptográfica al final, para fallar rápido cuando el problema es el más común y barato de detectar.

Ejercicio 2 — Explica, en una frase, por qué iac-scan (Trivy) no necesita saber que aws_bedrock_guardrail es un tipo de recurso nuevo para poder escanearlo. Piensa en cómo funciona un escáner de configuración en general, no en Bedrock específicamente.

Ver solución

Porque Trivy no mantiene una lista cerrada de "tipos de recurso que sabe escanear" antes de intentarlo — parsea cualquier archivo .tf como HCL válido, y aplica cada regla de su checks bundle (AWS-0086, AWS-0132, etc.) contra los recursos que encuentra, sin importar si esa regla existía cuando el archivo se escribió. Si ninguna regla del bundle actual conoce aws_bedrock_guardrail específicamente, el resultado simplemente no incluye ningún hallazgo para ese tipo de recurso —no porque Trivy lo haya ignorado, sino porque nadie ha escrito todavía una regla que aplique—. La lección 5 de este módulo confirma esto con una corrida real.

Ejercicio 3 — Predice qué pasaría si bedrock.tf tuviera un error de sintaxis HCL (una llave sin cerrar, por ejemplo) al llegar al job policy-check. ¿En qué paso exacto del job fallaría, y qué le pasaría a iac-scan y verify-artifact?

Ver solución

Fallaría en el paso Terraform plan (o incluso antes, en Terraform init, según la naturaleza exacta del error) — antes de que conftest llegara a evaluar nada, porque terraform show -json tfplan > tfplan.json nunca produciría un tfplan.json válido si el plan mismo nunca se generó. Con policy-check en rojo, iac-scan y verify-artifact nunca arrancarían, porque ambos tienen needs: apuntando, directa o transitivamente, a policy-check — la misma disciplina de "el gate corta antes, no después" que las guías anteriores ya establecieron. Un error de sintaxis en el Terraform nuevo de este módulo se detendría en el primer segundo del gate, no en el tercero.

Resumen y siguiente paso

Esta lección estableció la tesis completa de este módulo: el security gate de cloud-security-and-guardrails-guide —tres jobs (policy-check, iac-scan, verify-artifact), tres herramientas ($0, ya instaladas), una biblioteca de políticas (policy/)— no necesita ningún cambio a su propia maquinaria para evaluar correctamente la infraestructura de IA de Andes Cargo. Viste el mapa completo de las 8 lecciones, y la razón exacta por la que "extender" y no "reconstruir" es la disciplina dura de todo el módulo: un buen gate generaliza a dominios que nadie tenía en mente cuando se diseñó.

Antes de avanzar deberías poder: nombrar las tres herramientas heredadas sin reinstalar y sus versiones exactas; explicar por qué este módulo no agrega ningún job nuevo a ci.yml; y anticipar qué es lo genuinamente nuevo que sí vas a construir (una política, un artefacto firmado, dos filas de un documento).

La lección 2 retoma BedrockManifestExtractorRole del Módulo 3 y nombra, con precisión, el antipatrón exacto que la política de la lección 3 va a bloquear de forma automática.

Recursos

ADR-001-llm-as-escalation-path.md (Módulo 1, lección 8 de esta guía) — la fila que asigna a este módulo su responsabilidad exacta dentro del arco completo de la guía.
cloud-security-and-guardrails-guide, Módulo 8 — el capstone donde policy-check/iac-scan/verify-artifact se encadenaron por primera vez en ci.yml, el mismo archivo que este módulo extiende.
Conftest — Documentación oficial — referencia de la herramienta central del gate, reusada sin cambios en este módulo.
Sigstore — cosign Documentación — referencia de la herramienta de firma reusada en la lección 6.

← Anterior8. Proyecto: la capa de guardrails de Andes Cargo Siguiente →2. Mínimo privilegio para un modelo, no para un servicio