Detalles encontrados y límites conocidos¶
Este registro concentra diferencias, contratos implícitos y aspectos que condicionan la reproducción del proyecto. Se basa en los commits del inventario de fuentes. Una ausencia en los repositorios públicos no demuestra que nunca existiera configuración manual; indica que esa parte no puede reproducirse sólo con el contenido versionado revisado.
Los hallazgos describen la implementación. Las acciones de la cuarta columna son propuestas y no se han aplicado a los seis repositorios originales. Tampoco son resultados de pruebas de intrusión ni una medición del entorno activo.
Registro técnico¶
| ID | Área | Evidencia observada | Tratamiento | Fuente |
|---|---|---|---|---|
| F01 | Defaults de retirada | PIPELINE_ACTION=destroy, ENVIRONMENT=pro; los applies son manuales. |
Confirmar intención y seleccionar explícitamente acción/proveedor/entorno. | CI |
| F02 | Aislamiento de entornos | El entorno cambia estado y resource_group; nombres/etiquetas cloud conservan valores fijos. | Parametrizar identidad y red antes de crear varios entornos. | Variables |
| F03 | Exposición GKE | El único Ingress versionado usa clase ALB y certificado ACM. | Confirmar configuración externa o diseñar una variante GKE. | Ingress |
| F04 | Credencial del registro | Los pods exigen Secret registry; no hay creación en los seis repositorios. | Añadir bootstrap y rotación con credenciales de lectura. | Deployment |
| F05 | Identidad para push | CD_DEPLOY_TOKEN se usa para escribir Git; el tipo de token no consta. | Documentar identidad con write_repository y permisos de rama. | Deploy |
| F06 | Controles no bloqueantes | Analizadores/resultados observados permiten fallos; HIGH no es una barrera de entrega. | Acordar política de bloqueo/excepciones y verificarla. | Test |
| F07 | Pruebas de aplicación | No hay src/test; el empaquetado usa -DskipTests. | Añadir pruebas de contrato/funcionales según el alcance deseado. | Build |
| F08 | Reglas de rama | Deploy es automático sobre main protegida; la memoria también describe una variante manual. | Tomar el commit revisado como comportamiento vigente; conservar cronología. | Deploy |
| F09 | Revisión y concurrencia | El job deploy vuelve a clonar main; no se serializan entregas de aplicación. | Propagar SHA de manifiestos y serializar por destino/servicio. | Deploy |
| F10 | Verificación de salud | El job aplica YAML y lista recursos; no espera rollout ni hace smoke test. | Esperar disponibilidad y verificar interfaz/API por destino. | Deploy |
| F11 | Soporte Helm | La rama Chart.yaml del deploy imprime una indicación y termina con error. | Documentar sólo manifiestos YAML como camino implementado. | Deploy |
| F12 | Versiones móviles | Plantillas main, varios latest, kubectl stable, charts sin versión y sin lockfiles IaC. | Fijar dependencias y registrar la configuración efectiva. | Versiones IaC |
| F13 | Runtime IaC | HCL de Terraform ejecutado por OpenTofu 1.12.1; ya mencionado en memoria. | Usar terminología exacta y confirmar motivo histórico. | CI |
| F14 | Escalado EKS | Límites del node group 1/3/1 sin Autoscaler/Karpenter declarado. | No atribuir escalado por carga hasta configurar el controlador. | EKS |
| F15 | Topología GCP | Se usan primeros CIDR de listas; GKE tiene dos zonas explícitas. | Documentar recursos creados y conteos por zona. | GCP |
| F16 | API Kubernetes pública | Los valores por defecto permiten endpoints de control públicos. | Definir acceso del runner y restricciones de origen por entorno. | Acceso / Access |
| F17 | Identidad de workloads GKE | Pool habilitado, binding de ejemplo comentado, cuenta app distinta de rest/web. | No anunciar WI de aplicación completa; configurar sólo si se necesita. | GCP |
| F18 | Recuperación PSA | force_unlock… hace state rm, usa resource_group dev fijo y altera estado. | Confirmar fallo original; backup y reconciliación antes de uso excepcional. | CI |
| F19 | DAG fuera de main | Needs de creación dependen de applies excluidos por rama. | Validar en CI Lint; posible DAG inválido inferido por análisis estático. | CI |
| F20 | Informe y artefactos de plan | Se publica show -json completo como informe Terraform; puede contener valores sensibles. | Generar resumen create/update/delete para widget y restringir artefactos. | Estado / State |
| F21 | Conservación de datos | Protección de borrado desactivada; RDS omite snapshot final y no define su identificador. | Decidir conservación, completar configuración y ensayar restauración. | AWS |
| F22 | Puerto frontend | Dockerfile EXPOSE 8081; runtime, probes y Service usan 8080. | Normalizar la declaración del Dockerfile. | Dockerfile |
| F23 | Autenticación demostradora | Configuración permite peticiones; dependencias OAuth no prueban identidad activa. | Definir autenticación y autorización para uso con datos reales. | Seguridad / Security |
| F24 | Observabilidad | La memoria muestra ingestión OTLP de ejemplo; no hay integración completa versionada. | Distinguir demostración de instrumentación, alertas y SLO operativos. | Observabilidad / Observability |
| F25 | Planificación histórica | Una issue abierta menciona Azure; sólo hay raíces AWS y GCP. | Reconciliar backlog sin anunciar soporte Azure. | Issue |
| F26 | Esquema de datos | Hibernate ddl-auto=update; no migraciones versionadas ni rollback de datos. | Separar recuperación de imagen y de base de datos. | Runtime |
Orden de trabajo recomendado¶
Para reproducir la demostración: resolver F01–F05, confirmar el destino y los nombres reales, preparar el registro y la exposición, y revisar los requisitos de acceso. No iniciar la creación de recursos tomando los defaults de retirada como si fueran los de bootstrap.
Para confiar en una entrega: tratar F06–F12 y F26. Definir las comprobaciones funcionales, la política de seguridad y la recuperación de versiones y datos. Conservar el SHA exacto de manifiestos y la imagen disponible.
Para ampliar entornos o proveedores: tratar F02 y F14–F21. Las variables y las listas del código no garantizan por sí solas el aislamiento, el número de recursos ni todos los controladores necesarios.
Preguntas al autor¶
- ¿Qué motivó ejecutar OpenTofu en el pipeline? La memoria sí menciona su uso, pero falta la razón de elección.
- ¿
destroyyprocorresponden a las últimas pruebas o a la política de uso prevista? ¿Cómo se diferenciaban los entornos fuera del repositorio? - ¿Qué mecanismo se utilizó para exponer HTTP/TLS en GKE?
- ¿Qué error de Private Service Access motivó el job de retirada del estado y qué reconciliación se hizo después?
- ¿Los análisis no bloqueantes y la telemetría de ejemplo se eligieron por alcance didáctico, limitaciones del entorno u otra razón?
Las tres primeras preguntas se trasladaron durante la preparación. Las restantes se conservan como decisiones por completar. No se asigna una justificación hasta tener confirmación; ver decisiones.
Cómo cerrar un hallazgo¶
Relacionar la issue/MR, el commit que cambia la configuración, la evidencia de validación y las páginas afectadas en ambos idiomas. Marcar el cambio como resuelto sólo después de revisar esos elementos. Al actualizar este registro, conservar la fecha y los SHA de la edición previa para explicar la evolución del proyecto.