Módulo 8: Capstone The Andes Cargo Security Gate
7. Lo que Andes Cargo todavía necesita
Descripción
El security gate de este módulo cierra el trabajo que le correspondía a esta guía, no el trabajo que le falta a Andes Cargo como empresa. Esta lección traza el mapa hacia afuera: cuatro guías hermanas del mismo ecosistema, cada una con una frontera exacta y ya declarada desde el DISEÑO.md de esta guía, que retoman exactamente donde esta se detiene, sin repetir ni un módulo de lo que ya construiste.
Conexión con el módulo
No es la primera vez que esta guía nombra estas cuatro fronteras — cada una apareció, una sola vez, en el momento exacto en que un tema las rozó (el Módulo 7 nombró FinOps por contraste con "guardrail de seguridad"; el Módulo 6 aclaró que el escaneo de esta guía es de artefacto de despliegue, no de imagen de contenedor). Esta lección las reúne, con precisión adicional que ninguna lección anterior tenía todavía: una de las cuatro —FinOps— ya tiene su propio DISEÑO.md escrito, y ese documento cita el ci.yml exacto que este módulo capstone acaba de construir como su punto de partida literal.
Analogía: el edificio terminado, y el barrio que lo rodea
Terminar de construir un edificio con todos sus controles de seguridad —cerraduras, cámaras, control de acceso— no significa que el barrio entero esté resuelto. El edificio de al lado todavía necesita su propia obra; la red eléctrica del barrio todavía necesita su propio mantenimiento; el sistema de transporte que trae a la gente hasta la puerta es un proyecto completamente distinto, con su propio equipo. Andes Cargo, con el gate de este módulo terminado, tiene un edificio seguro — pero sigue siendo una empresa con costos que vigilar, incidentes que operar, y (si algún día lo necesita) contenedores e IA que asegurar de formas que este edificio específico no cubre.
El mapa de las cuatro fronteras
cloud-security-and-guardrails-guide (esta guía)
│
┌────────────┬──────────┼──────────┬────────────────┐
│ │ │ │ │
▼ ▼ │ ▼ ▼
finops-and-cost- sre-and- │ kubernetes-and- genai-on-aws-
guardrails-guide incident- │ eks-in-production- production-guide
response- │ guide
guide │
│
(esta guía termina aquí:
seguridad de infraestructura,
no de costo, no de incidentes,
no de contenedores, no de modelos)
1. FinOps y guardrails de costo — finops-and-cost-guardrails-guide
La frontera, tal como esta guía la nombró desde su propio DISEÑO.md: "Un guardrail de esta guía nunca es 'esto es caro', es 'esto es inseguro'". Las tres políticas de policy/ (Módulo 4) evalúan seguridad — nunca evaluaron, ni evaluarán, si un cambio va a costar más dinero.
Lo que esa guía construye, retomando literalmente el ci.yml de este módulo: un cost gate, en paralelo al security gate de este módulo, nunca fusionado con él. Dos piezas concretas:
- Un job nuevo,
cost-tags, que correconftest test tfplan.json -p cost-policy/— el mismo motorconftestque ya conoces, pero contra un directorio hermano depolicy/, nunca anidado dentro. La razón, citada textualmente de esa guía: "para queconftest test tfplan.json -p policy/(el jobpolicy-checkde seguridad, ya escrito) nunca recoja por accidente las reglas de costo de esta guía, y viceversa". - Un gate de costo artesanal en el Pull Request —dos corridas de
infracost scan --json(antes/después del cambio), comparadas conjq—, deliberadamente sin la versión comercial de pago de Infracost (Infracost Cloud, $1.000/mes), por el mismo criterio de honestidad $0 que gobierna toda esta guía.
Un servicio de AWS específico, ausente incluso de LocalStack Ultimate (no es un límite de plan, es un servicio no emulado por completo), obliga a esa guía a documentar un intento honesto de aws_budgets_budget — el mismo patrón exacto que el Módulo 7 de esta guía ya usó con CloudTrail.
2. SRE e incident response — sre-and-incident-response-guide
La frontera: "Un hallazgo de Trivy/conftest que se ignora y termina en producción es exactamente el tipo de incidente que esa guía enseña a operar — aquí se detiene antes de que exista".
Esta guía construyó la prevención: el gate que detiene un cambio inseguro antes de que llegue a producción, con evidencia ejecutada en las lecciones 4 y 5 de este módulo. Lo que ninguna lección de esta guía enseñó es qué pasa cuando la prevención falla de todos modos —un policy-check que alguien fuerza a pasar con --policy /dev/null por error, un hallazgo de Trivy suprimido sin razón real, una firma de cosign verificada contra la llave equivocada por un cosign.pub mal actualizado—. Ese es el dominio de sre-and-incident-response-guide: SLI/SLO, guardias de turno (on-call), postmortems sin culpa, runbooks de incidente. El vínculo es directo y concreto: cada control de este módulo, si algún día falla en silencio, se convierte en material de estudio de esa guía hermana.
3. EKS y runtime de contenedores — kubernetes-and-eks-in-production-guide
La frontera: "El handler Lambda de Andes Cargo se empaqueta en .zip, no en imagen de contenedor; el escaneo y la firma de esta guía son de artefacto de despliegue y de IaC, no de imagen. El único componente contenerizado del caso —andes-cargo-status-api, la imagen que aws-serverless-and-containers-guide construyó pero nunca llegó a orquestar— recibe su runtime y su seguridad de runtime (admission control, escaneo de imagen, NetworkPolicy) en kubernetes-and-eks-in-production-guide".
El Módulo 6 de esta guía firmó y verificó lambda/function.zip —un .zip de 890 bytes, no una imagen OCI—. Si Andes Cargo alguna vez migrara process-shipment-manifest de Lambda a un contenedor corriendo en EKS, tres piezas específicas de este ecosistema de seguridad necesitarían un equivalente que esta guía nunca construyó: admission controllers dentro del propio clúster (OPA Gatekeeper o Kyverno, el equivalente de conftest/policy-check pero evaluando manifiestos de Kubernetes en el momento de aplicarlos, no un plan de Terraform), escaneo de imágenes Docker (Trivy sí escanea imágenes, con un comando distinto a trivy config — pero esta guía nunca lo usó, porque nunca hubo una imagen que escanear), y NetworkPolicy (control de tráfico entre pods, sin ningún equivalente en un mundo serverless de un solo handler Lambda).
4. Seguridad de GenAI — genai-on-aws-production-guide
La frontera: "Esta guía asegura la infraestructura que correría una carga de IA, no el modelo ni el prompt".
Es la frontera más fácil de mal-entender de las cuatro, así que vale la pena decirla con precisión: si Andes Cargo desplegara un modelo de lenguaje mañana para clasificar manifiestos automáticamente, este ecosistema de seguridad seguiría aplicando sin cambios —el .zip (o la imagen) que empaquetara ese código todavía necesitaría firma y verificación con cosign; el rol IAM que ese servicio asumiera todavía necesitaría mínimo privilegio; el plan de Terraform que lo desplegara todavía pasaría por policy-check—. Lo que esta guía nunca cubrió, porque nunca fue su capa, es la seguridad del contenido: inyección de prompts, guardrails de Bedrock, información personal identificable filtrada dentro de un prompt o una respuesta. Esa es la capa completa de genai-on-aws-production-guide — una capa encima de la infraestructura que este ecosistema asegura, no un reemplazo de ella.
La tabla resumen
| Guía hermana | Qué asegura | Relación con esta guía |
|---|---|---|
finops-and-cost-guardrails-guide | Que un cambio no cueste de más | Cost gate en paralelo al security gate, mismo ci.yml, mismo conftest, directorio hermano cost-policy/ |
sre-and-incident-response-guide | Qué pasa cuando un control de esta guía falla en producción | Retoma el "después" de cada control preventivo de esta guía |
kubernetes-and-eks-in-production-guide | Contenedores y clústeres, si Andes Cargo migrara a ellos | El equivalente de conftest/Trivy/cosign, pero para imágenes OCI y manifiestos K8s |
genai-on-aws-production-guide | El modelo y el prompt, no la infraestructura que los corre | Una capa por encima de todo lo que esta guía aseguró |
Errores comunes
Pensar que Andes Cargo "necesita" las cuatro guías con la misma urgencia, sin priorizar según lo que la empresa realmente tiene hoy. Qué pasa: alguien, al terminar esta lección, trata las cuatro fronteras como una lista de tareas pendientes de igual peso. Cómo detectarlo: si tu plan de "seguir aprendiendo" no distingue entre lo que Andes Cargo ya usa (Lambda, S3, DynamoDB, un pipeline con costo real) y lo que podría usar algún día (contenedores, un modelo de IA). Cómo corregirlo: finops-and-cost-guardrails-guide aplica hoy, sin ninguna condición —Andes Cargo ya gasta dinero en lo que este ecosistema construyó—. kubernetes-and-eks-in-production-guide y genai-on-aws-production-guide aplican si y cuando la empresa migre a esas tecnologías, no antes. Priorizar según el estado real del negocio, no según el orden en que esta lección las presentó, es la lectura correcta.
Asumir que el "cost gate" de FinOps reemplaza o compite con el security gate de este módulo. Qué pasa: alguien, leyendo que ambos gates corren en el mismo ci.yml, asume que hay una relación de sustitución o de prioridad entre ellos. Cómo detectarlo: si tu pregunta es "¿cuál gate corre primero, el de seguridad o el de costo?". Cómo corregirlo: la cita textual de finops-and-cost-guardrails-guide ya lo resuelve — el cost gate corre en paralelo, nunca fusionado, con directorios de reglas que nunca se superponen (policy/ vs. cost-policy/). Son dos preguntas independientes sobre el mismo cambio ("¿es seguro?" y "¿es barato?"), evaluadas por separado, con el mismo motor pero bibliotecas de reglas completamente distintas.
Buscar "seguridad de EKS" o "seguridad de GenAI" dentro de esta guía, pensando que quedó incompleta. Qué pasa: alguien, después de leer el Módulo 6 (SBOM y firma), busca cómo aplicar cosign a una imagen Docker dentro de esta misma guía, sin encontrarlo. Cómo detectarlo: si tu búsqueda de "cómo firmar una imagen de contenedor" te lleva de vuelta a los mismos ocho módulos de esta guía, sin resultado. Cómo corregirlo: esta guía nunca tuvo una imagen de contenedor que firmar —Andes Cargo empaqueta su Lambda en .zip, una decisión ya tomada por terraform-and-iac-guide, heredada sin cambios—. cosign sí firma imágenes OCI, con un comando distinto (cosign sign, no cosign sign-blob), pero ese es exactamente el contenido que le corresponde a kubernetes-and-eks-in-production-guide, no a esta.
Ejercicios
Ejercicio 1 — Para cada una de las cuatro guías hermanas, identifica qué pieza específica de andes-cargo-infra/ (construida en M1-M8 de esta guía) reutilizaría sin cambios. Sin leer ninguna de las cuatro guías completas, predice: ¿qué archivo o recurso de este proyecto usaría cada una como punto de partida?
Ver solución
finops-and-cost-guardrails-guide reutiliza ci.yml/apply.yml extendidos (ya confirmado, textualmente, en su propio DISEÑO.md) y el proyecto Terraform completo, para calcular costo sobre los mismos recursos. sre-and-incident-response-guide reutilizaría, como material de estudio, cualquier control de esta guía que alguna vez falle en producción —no un archivo específico, sino el comportamiento de los tres jobs del gate como fuente de incidentes hipotéticos—. kubernetes-and-eks-in-production-guide reutilizaría el patrón de cosign sign-blob/verify-blob (Módulo 6), adaptado a cosign sign/verify para imágenes, y el patrón de policy-check con conftest, adaptado a Rego evaluando manifiestos K8s en vez de un plan de Terraform. genai-on-aws-production-guide reutilizaría modules/oidc-provider/ y secrets.tf sin ningún cambio —cualquier servicio nuevo que Andes Cargo desplegara, incluido uno de IA, seguiría necesitando identidad federada y secretos gestionados exactamente como los construyó el Módulo 2 y el Módulo 3.
Ejercicio 2 — Explica por qué finops-and-cost-guardrails-guide es la única de las cuatro que ya tiene su propio DISEÑO.md escrito, mientras las otras tres todavía no. Basándote en el orden de lectura del ecosistema que el DISEÑO.md de esta guía menciona, ¿qué tendría sentido en el orden de diseño de las guías hermanas?
Ver solución
No hay una única razón correcta verificable desde esta lección —es una decisión editorial del equipo que diseña el ecosistema completo, no un hecho técnico derivable—, pero una hipótesis razonable, consistente con lo que sí es verificable: FinOps es la frontera que esta guía nombró con más frecuencia y más precisión a lo largo de sus ocho módulos (el Módulo 7 la nombró explícitamente por contraste), lo que sugiere que fue la siguiente prioridad natural de diseño una vez que esta guía se dio por completa. Las otras tres (SRE, EKS, GenAI) dependen de que Andes Cargo adopte tecnologías que, dentro de este ecosistema, todavía no existen (contenedores, un modelo de IA desplegado) — diseñarlas requeriría, primero, decidir cómo y cuándo esas tecnologías entran al caso de negocio, una decisión de mayor alcance que "cuánto cuesta lo que ya existe".
Ejercicio 3 — Diseña, en prosa, el nombre y el propósito de un job cost-tags hipotético dentro de ci.yml, sin leer finops-and-cost-guardrails-guide. Usando solo lo que sabes de policy-check (este módulo) y la cita textual de esa guía sobre cost-policy/, describe qué política Rego mínima escribirías para exigir que todo recurso facturable tenga una etiqueta CostCenter.
Ver solución
Una política razonable, siguiendo el mismo patrón que least-privilege-iam.rego (Módulo 4) ya estableció: iterar sobre input.resource_changes, filtrar por los tipos de recurso que facturan (aws_s3_bucket, aws_dynamodb_table, aws_lambda_function — no aws_iam_role, que es global y no factura, la misma distinción que aws-core-services-guide ya hizo), y para cada uno, verificar que rc.change.after.tags incluya la clave CostCenter con algún valor no vacío — un deny con un mensaje señalando el address exacto del recurso sin esa etiqueta, exactamente el mismo patrón de mensaje que ya viste en las lecciones 4 y 5 de este módulo. El punto del ejercicio no es escribir Rego perfecto —es confirmar que el patrón de política que aprendiste en esta guía se generaliza, sin esfuerzo conceptual adicional, a un dominio de reglas completamente distinto (costo, no seguridad).
Resumen y siguiente paso
Esta lección trazó el mapa completo hacia afuera de esta guía: cuatro guías hermanas, cada una con una frontera exacta y ya declarada, retomando el trabajo terminado de esta guía sin repetir un solo módulo. finops-and-cost-guardrails-guide ya cita, textualmente, el ci.yml que este módulo capstone acaba de construir como su punto de partida. Las otras tres —SRE, EKS, GenAI— aplican cuando el negocio de Andes Cargo las necesite, no antes, y cada una reutiliza una pieza específica y reconocible de lo que M1-M8 ya construyeron.
La lección 8, la última de esta guía, integra el repositorio completo —THREAT-MODEL.md, modules/oidc-provider/, secrets.tf, policy/, sbom.cyclonedx.json, cosign.pub, los workflows extendidos— en una sola pieza de portfolio, defendible en una entrevista técnica de principio a fin.
Recursos
DISENO.mdde esta guía, sección "NO entra en" — la fuente original de las cuatro fronteras que esta lección desarrolla en detalle.finops-and-cost-guardrails-guide/DISENO.md— la única de las cuatro guías hermanas con diseño completo escrito, citada textualmente en esta lección.src/paths/aws-cloud-ecosystem/VALIDACION.md— la auditoría de mercado que fijó el rol de cada guía dentro del ecosistema completo.