Módulo 8: Capstone The Andes Cargo Security Gate
6. Lo que esta guía dejó representativo, honestidad final
Descripción
Siete módulos, cada uno con su propia sección de honestidad, en el momento exacto en que un límite apareció. Esta lección no agrega ningún límite nuevo — reúne los que ya viste, dispersos en siete módulos distintos, en un solo lugar, con la misma razón técnica exacta que cada uno tuvo cuando apareció por primera vez. Es la lección que le permite a cualquiera —tú, dentro de seis meses, o un entrevistador técnico revisando este proyecto— responder "¿qué de esto es real y qué no?" sin tener que releer ocho módulos completos.
Conexión con el módulo
Esta guía completa se construyó bajo una regla dura, citada desde el DISEÑO.md: "nada se simula en prosa; si un comando de conftest/Trivy/Checkov/cosign aparece en una lección, corrió para escribirla". Los cuatro casos representativos que esta lección resume no son una excepción a esa regla — son la aplicación honesta de la misma regla al único tipo de comando que, por diseño de LocalStack Hobby/Community, no puede correr de verdad en este laboratorio $0: cualquiera que dependa de enforcement real de identidad o de una API de detección continua a escala.
Analogía: el plano completo del edificio, con las zonas en construcción marcadas
Un arquitecto que entrega los planos de un edificio no dice simplemente "está terminado" — marca, con precisión, qué pisos están habitables hoy y cuáles siguen en obra gris, y por qué. Esta lección es ese plano final: no una lista de disculpas, sino un mapa preciso de qué parte de la seguridad de Andes Cargo está construida y verificada hoy, y qué parte necesita una cuenta AWS real (o un plan de LocalStack de pago) para terminar de construirse — con la razón técnica exacta de cada una, nunca "por falta de tiempo" ni "queda para después" sin más.
La columna vertebral que sí corrió de verdad
Antes de la lista de límites, vale la pena decir con números exactos qué no es representativo en esta guía — la mayoría de su contenido:
| Herramienta | Versión confirmada | Qué evaluó, de verdad, en esta guía |
|---|---|---|
conftest/OPA | 0.69.0 | Cuatro reglas Rego, contra el plan real de andes-cargo-infra/, en cada uno de los Módulos 4 y 8 |
| Trivy | 0.74.0 | Configuración de IaC (trivy config), SBOM (trivy fs --format cyclonedx), y escaneo de secretos filtrados, en los Módulos 3, 5 y 6 |
| Checkov | 3.2.529 | Segundo escáner independiente, contrastado con Trivy, en el Módulo 5 |
cosign | v3.1.3 | Firma y verificación 100% offline de lambda/function.zip, incluida la detección real de manipulación, en el Módulo 6 |
act | corrido en cada módulo con CI | Los tres jobs del security gate encadenados, en los Módulos 5, 6 y 8 |
terraform plan/show -json | 1.15.8 | El plan completo de Andes Cargo, sin necesidad de LocalStack, en los Módulos 4 y 8 |
Ninguna de estas seis filas necesitó, en ningún momento, un LOCALSTACK_AUTH_TOKEN — es la razón técnica exacta por la que corrieron de verdad en este entorno de escritura, y por la que corren de verdad en el tuyo también, sin ninguna cuenta de pago.
Los cuatro límites, uno por uno, con su razón exacta
1. Validación real de un token OIDC de GitHub Actions contra AWS (Módulo 2, lección 6)
Lo que sí corrió de verdad: el Módulo 2 aplicó aws_iam_openid_connect_provider y el aws_iam_role con su trust policy condicionada, contra LocalStack, y los verificó con awslocal iam list-open-id-connect-providers/get-role. La lección 6 de ese módulo construyó un JWT de prueba a mano (PyJWT, clave simétrica de prueba) y llamó awslocal sts assume-role-with-web-identity de verdad.
Lo que queda representativo, y por qué: la operación existe en LocalStack a nivel de API, pero la evaluación real de la firma, el emisor (iss), y las condiciones de la trust policy —el mecanismo que decidiría si un JWT falso tiene permiso para asumir el rol— vive en la funcionalidad IAM Policy Enforcement, confirmada como "Included in Plans: Base, Ultimate", no en el plan gratuito Hobby/Community. Sin ese enforcement, LocalStack Hobby acepta la llamada sin verificar de verdad nada de eso — el Módulo 2, lección 6, convirtió esa misma ausencia en el experimento pedagógico central del módulo, en vez de escondérsela al lector.
2. Enforcement de IAM en general (Módulos 2 y 7)
Lo que sí corrió de verdad: el Módulo 2 recortó LambdaManifestProcessorRole/AppServerRole a mínimo privilegio, aplicado y verificado con awslocal iam get-role-policy. El Módulo 7, lección 3, declaró una permission boundary completa para AppServerRole, validada con terraform validate/plan reales.
Lo que queda representativo, y por qué: la misma funcionalidad de pago del punto anterior —IAM Policy Enforcement— es la que decidiría si una llamada real, hecha con credenciales de ese rol, queda efectivamente bloqueada por la política o el boundary. Esta guía construye y lee ambos (get-role-policy confirma que el HCL correcto llegó a LocalStack), pero no puede probar el bloqueo contra una llamada real que exceda esos permisos.
3. Guardrails detectivos a escala (Módulo 7, lecciones 4 y 5)
Lo que sí corrió de verdad: el Módulo 7, lección 5, declaró el trail real de CloudTrail (aws_cloudtrail + bucket dedicado con política de dos statements), validado con terraform validate/plan, e intentó de verdad generar un evento de prueba y leerlo con awslocal cloudtrail lookup-events — sin red de seguridad, documentando el resultado real tal cual salió.
Lo que queda representativo, y por qué: GuardDuty y AWS Config no están confirmados en el plan gratuito Hobby/Community de LocalStack (frente a IAM, Secrets Manager y SSM, que sí lo están) — se nombran, con lo que harían y por qué importan, sin ejecutarse. El intento real de lookup-events falló con un error de conexión —el mismo límite de ausencia de token del Módulo 1, no una limitación distinta de CloudTrail en sí—, documentado como "Error común" honesto en esa misma lección, en vez de omitido.
4. Organizations, Control Tower, SCPs a escala multi-cuenta (Módulo 7, lección 6)
Lo que sí corrió de verdad: nada de HCL — este es el único de los cuatro límites que nunca tuvo un intento de construcción, por una razón estructural, no de herramienta.
Lo que queda representativo, y por qué: fuera del alcance $0 (LocalStack Hobby/Community no los sostiene) y fuera del caso Andes Cargo, que es y sigue siendo una sola cuenta a lo largo de todo el ecosistema. Es, textualmente, un faltante de nivel ecosistema documentado en VALIDACION.md como ALTA sin guía asignada todavía — no una omisión escondida de esta guía específica.
La tabla resumen, en un solo lugar
| # | Límite | Módulo donde aparece | Causa técnica exacta |
|---|---|---|---|
| 1 | Validación real de un JWT de GitHub Actions | M2.6 | IAM Policy Enforcement: LocalStack Base/Ultimate, no Hobby |
| 2 | Enforcement de IAM general (política, boundary) | M2.7, M7.3 | Misma causa que la fila 1 |
| 3 | GuardDuty, AWS Config | M7.4 | No confirmados en el plan gratuito Hobby/Community |
| 4 | Organizations, Control Tower, SCP multi-cuenta | M7.6 | Fuera de alcance $0 + Andes Cargo es una sola cuenta (faltante de ecosistema) |
Tres causas distintas, nunca una sola etiqueta genérica de "no se pudo". Las filas 1 y 2 comparten la misma causa exacta (IAM Policy Enforcement). La fila 3 es una causa de cobertura no confirmada, distinta de la anterior. La fila 4 es una decisión de alcance de ecosistema, distinta de las dos anteriores — la misma disciplina de tres causas separadas que GUARDRAILS-MAP.md (Módulo 7, lección 8) ya aplicó a su propia matriz de ocho piezas.
Lo que esto significa para el gate de este módulo, específicamente
El security gate de las lecciones 3 a 5 —policy-check, iac-scan, verify-artifact— no depende de ninguno de los cuatro límites de arriba. Los tres controles evalúan un plan calculado localmente, HCL crudo, y un artefacto committeado — ninguno necesita IAM Policy Enforcement, ninguno necesita GuardDuty ni Config, ninguno necesita Organizations. Es, precisamente, la razón de diseño por la que este capstone pudo construirse con evidencia 100% ejecutada, sin ningún caso representativo propio: los tres controles nuevos de M8 viven completamente dentro de la columna vertebral que sí corre gratis, en cualquier máquina, sin ninguna cuenta.
Lo único representativo de este módulo específico es lo que ya viste en las lecciones 4 y 5: el punto donde apply.yml tomaría el relevo contra una infraestructura real —no porque el gate en sí sea representativo, sino porque el apply que vendría después de un gate en verde siempre necesitó, desde el Módulo 1, una cuenta AWS real o un token de LocalStack de pago.
Errores comunes
Tratar los cuatro límites de esta lección como si fueran fallas de la guía, en vez de fronteras documentadas de un laboratorio $0. Qué pasa: alguien, leyendo esta lección aislada, concluye que "la mitad de esta guía no funciona de verdad". Cómo detectarlo: si tu resumen mental de esta guía, después de leerla completa, es "mucho quedó sin probar". Cómo corregirlo: la sección "La columna vertebral que sí corrió de verdad" de esta lección lista seis herramientas —conftest, Trivy, Checkov, cosign, act, terraform plan— que corrieron de verdad en todos los módulos que no son estos cuatro casos puntuales. Los cuatro límites son específicos, acotados, y cada uno tiene una razón exacta citada contra documentación oficial — no una vaguedad genérica sobre "las limitaciones del laboratorio".
Asumir que los cuatro límites desaparecerían simplemente instalando LocalStack Pro. Qué pasa: alguien concluye que pagar por LocalStack Base o Ultimate resolvería, automáticamente, los cuatro puntos de esta lección. Cómo detectarlo: si tu plan de "arreglar" estos límites es solo "pagar la suscripción". Cómo corregirlo: IAM Policy Enforcement (filas 1 y 2) sí es, específicamente, una funcionalidad de LocalStack Base/Ultimate — pagar la resolvería. Pero la fila 4 (Organizations/Control Tower/SCP) es, además, una decisión de alcance de esta guía y este caso (Andes Cargo es una sola cuenta) — ni siquiera con LocalStack Pro tendría sentido construirla sin que el caso de negocio la necesitara. Cada límite tiene su propia vía de resolución, no una sola solución universal.
Citar el límite equivocado al explicar por qué CloudTrail (fila 3) no se pudo confirmar del todo. Qué pasa: alguien atribuye el fallo de lookup-events (Módulo 7, lección 5) a la misma causa que GuardDuty/Config (cobertura no confirmada en el plan gratuito). Cómo detectarlo: si tu explicación de por qué lookup-events falló menciona "el plan Hobby no incluye esto". Cómo corregirlo: CloudTrail sí tiene cobertura de API demostrada en LocalStack Hobby (create-trail, el intento de lookup-events) — el fallo real que esa lección documentó fue un error de conexión (el mismo límite de ausencia de token de este entorno de escritura, desde el Módulo 1), no una limitación de funcionalidad de pago. Son dos causas técnicamente distintas, aunque ambas terminen en "no se pudo confirmar en vivo".
Ejercicios
Ejercicio 1 — Clasifica los cuatro límites de esta lección según si un LOCALSTACK_AUTH_TOKEN (sin cambiar de plan) los resolvería. Para cada uno de los cuatro, decide: ¿un token gratuito de LocalStack Hobby, simplemente presente en el entorno, habría cambiado el resultado?
Ver solución
Ninguno de los cuatro se resolvería solo con un token Hobby presente —tres de los cuatro (filas 1, 2, 4) dependen de funcionalidad que ni siquiera el plan Hobby incluye (IAM Policy Enforcement es Base/Ultimate; Organizations es una decisión de alcance, no de plan)—. La fila 3 (GuardDuty/Config) tampoco está confirmada en Hobby. Sin embargo, un detalle real: el intento de lookup-events de CloudTrail (parte de la fila 3, pero con causa distinta a GuardDuty/Config dentro de esa misma fila) sí habría funcionado con solo un token Hobby presente —esa parte específica falló por ausencia de contenedor corriendo en este entorno de escritura, no por una limitación de plan—. El punto del ejercicio es notar que "representativo" en esta guía nunca es una etiqueta uniforme: cada caso, incluso dentro de la misma fila, puede tener una causa distinta.
Ejercicio 2 — Explica por qué el security gate de este módulo (M8) no aparece en la tabla resumen de esta lección. Un compañero pregunta por qué, si M8 corrió tres jobs completos de un pipeline real, no tiene su propia fila entre los cuatro límites.
Ver solución
Porque no tiene ningún límite que documentar — la sección "Lo que esto significa para el gate de este módulo" ya lo explica: los tres controles de M8 (conftest, Trivy, cosign) operan sobre datos calculados localmente (plan, HCL, un artefacto committeado), ninguno de los cuales depende de IAM Policy Enforcement, GuardDuty, Config, ni Organizations. M8 es, precisamente, la demostración de que la mayoría de la seguridad real de un pipeline —policy-as-code, escaneo, integridad de artefactos— no necesita ninguna de las cuatro piezas de pago que esta lección documenta. Los cuatro límites viven en la capa de identidad y detección a escala, no en la capa de gate preventivo de pipeline, que es exactamente la capa que este módulo capstone construyó de punta a punta.
Ejercicio 3 — Si Andes Cargo migrara este proyecto contra una cuenta AWS real mañana, ordena los cuatro límites de esta lección por cuál dejaría de ser representativo primero, con el menor esfuerzo adicional. Sin escribir HCL nuevo, ordena las cuatro filas de la tabla resumen de "más fácil de resolver contra AWS real" a "más esfuerzo adicional necesario".
Ver solución
Un orden razonable: (1) Validación real de OIDC y (2) enforcement de IAM se resolverían automáticamente, sin ningún cambio de HCL —contra una cuenta AWS real, el enforcement de IAM siempre está activo, no es una funcionalidad opcional de pago como en LocalStack—; de hecho, ambas dejarían de ser un límite el mismo día que el pipeline apuntara a una cuenta real en vez de LocalStack. (3) GuardDuty y Config requerirían activarlos explícitamente (aws_guardduty_detector, aws_config_configuration_recorder) — HCL nuevo, pero conceptualmente simple, sin ningún rediseño. (4) Organizations/Control Tower/SCP multi-cuenta requeriría el esfuerzo más grande: no es solo HCL nuevo, es una decisión organizacional completa —crear cuentas adicionales, definir una jerarquía, decidir qué SCPs aplicar a qué unidad organizacional— que ninguna cantidad de Terraform, por sí sola, resuelve sin ese trabajo previo de diseño.
Resumen y siguiente paso
Esta lección reunió, en un solo lugar, los cuatro límites reales de todo el ecosistema de esta guía —validación de OIDC, enforcement de IAM, guardrails detectivos a escala, multi-cuenta—, cada uno con la misma razón técnica exacta que tuvo la primera vez que apareció, nunca genérica. Confirmaste, con una tabla de seis herramientas, que la columna vertebral de esta guía —conftest, Trivy, Checkov, cosign, act, terraform plan— corrió de verdad en todos los módulos que no son estos cuatro casos puntuales, y que el security gate de este módulo capstone específicamente no hereda ninguno de los cuatro límites.
La lección 7 mira hacia afuera de esta guía: qué necesita Andes Cargo que ninguna guía de este ecosistema, todavía, ha construido.
Recursos
DISENO.mdde esta guía, sección "Enfoque de costo y ejecución" — la fuente completa de los cuatro límites resumidos aquí, con las citas textuales de documentación oficial.- LocalStack Docs — IAM Policy Enforcement — la fuente exacta detrás de las filas 1 y 2.
- LocalStack — Pricing — la confirmación de cobertura de servicios por plan, base de la fila 3.
- Este curso, Módulo 7, lección 8 (
GUARDRAILS-MAP.md) — la matriz de ocho piezas que aplicó, por primera vez, el mismo principio de "tres causas distintas, nunca una etiqueta genérica" que esta lección extiende a la guía completa.