Seguridad y fronteras de confianza¶
El diseño combina controles concretos en contenedores, redes y CI con simplificaciones de demostración. Esta página describe qué controla cada capa y qué requiere una decisión adicional antes de utilizar el patrón en un entorno con datos reales.
Identidades distintas¶
| Identidad | Responsabilidad | No confundir con |
|---|---|---|
| Usuario de GitLab | Cambios, revisión y aprobación de applies | Cuenta cloud o identidad del pod |
| Credencial cloud del pipeline | Crear y administrar recursos | Permisos del agente para desplegar aplicaciones |
CI_JOB_TOKEN |
Autenticación temporal de jobs/estado según configuración | Credencial permanente para image pulls |
TF_STATE_TOKEN |
Lectura de estados de capas previas | Variables de salida no sensibles por definición |
| Credencial CD | Push al repositorio de manifiestos | Deploy Token de sólo lectura del código |
| Token de agente | Conectar el agente con GitLab | Autorizaciones RBAC del usuario/CI |
| Secret de registro | Leer imágenes desde los pods | Permiso para modificar repositorios Git |
| Usuario MySQL | Acceso a la base de aplicación | Identidad de administración cloud |
La separación conceptual permite revisar cada permiso, pero el repositorio no contiene todas las políticas IAM ni los roles privados de GitLab. No se afirma que exista mínimo privilegio completo en las cuentas originales.
Controles declarados¶
Los contenedores ejecutan con UID/GID explícitos sin root; no permiten escalado de privilegios; eliminan capacidades; usan seccomp y raíz de sólo lectura. Las ServiceAccounts rest y web desactivan el montaje automático del token Kubernetes. El backend se expone internamente con ClusterIP. Las bases de datos usan red privada y AWS restringe el acceso RDS desde el grupo de seguridad de nodos EKS.
Los agentes y la fase platform tienen otras necesidades de permisos. El hecho de que los pods de aplicación no monten un token no significa que el agente tenga permisos limitados al mismo nivel. Revisar agentes y acceso.
Límites concretos¶
Aplicación: las peticiones se permiten sin una autenticación de negocio configurada. TLS está desactivado dentro de los servidores Spring; en AWS se termina en el ALB configurado. La exposición TLS de GKE requiere una configuración adicional o la aclaración del procedimiento original.
Red: los nodos privados conviven con endpoints de control Kubernetes públicos en los valores por defecto. No hay NetworkPolicies de aplicación versionadas. Los servicios internos y los Secrets son controles diferentes y no sustituyen el aislamiento de tráfico ni el control de acceso a la API.
Datos: RDS/Cloud SQL tienen parámetros de demostración y la protección contra borrado está desactivada. En AWS se omite la instantánea final. Los backups existentes deben verificarse y ensayarse; su declaración no constituye una prueba de restauración.
CI: los analizadores/resultados permiten fallos. Las plantillas se consumen desde main, varias imágenes/charts son flotantes y el cliente kubectl se descarga sin fijar versión. Registrar la configuración expandida y fijar dependencias mejora la trazabilidad.
Estados, planes e informes¶
Los estados pueden contener contraseñas y valores de Secrets; los planes JSON también pueden revelar datos sensibles. sensitive = true limita ciertas presentaciones, pero no elimina el valor del estado. Restringir acceso al proyecto, estados y artefactos y conservar los backups por un canal adecuado. No publicar esos archivos en este sitio documental.
Los artefactos IaC se conservan una semana en el YAML, y no se declara un control artifacts:access específico. Comprobar la visibilidad real del proyecto y del backend administrado por GitLab. La revisión no inspeccionó valores de variables privadas ni descargó estados cloud.
Evolución priorizada¶
- Completar el contrato de bootstrap: credenciales, permisos, Secret de registro y exposición por proveedor.
- Definir aislamiento real por entorno, política de destrucción y recuperación de datos.
- Acordar qué análisis bloquean entregas y añadir pruebas/rollout verificable.
- Fijar versiones y propagar la revisión exacta de manifiestos entre jobs.
- Revisar identidad de aplicación, endpoints de control, RBAC y segmentación de red.
Estas tareas son un plan de evolución del demostrador. Cada una tiene un hallazgo o requisito concreto en el registro técnico, sin atribuir decisiones históricas no confirmadas.