Version: 1.2.0
Fecha: 5 de Agosto, 2026
Arquitecto: Carlos Alberto Torres Camargo
Audiencia: Desarrolladores Backend
Hasta antes de esta actualizacion, los servicios de la suite Simappe/Nebula tenian credenciales y secretos hardcodeados directamente en los archivos docker-compose.yml y en las propiedades de configuracion. Esto incluia:
DB_ENCRYPTION_KEY)CONFIG_GIT_USERNAME, CONFIG_GIT_PASSWORD)Esto representaba riesgos criticos de seguridad:
| Riesgo | Impacto |
|---|---|
| Secretos visibles en historial de Git | Cualquier persona con acceso al repositorio podia ver credenciales de produccion |
| Sin rotacion de secretos | Cambiar una credencial requeria modificar codigo y redesplegar |
| Sin separacion de ambientes | La misma credencial se usaba en dev, pre y prod |
| Violacion de OWASP A07:2021 | Security Misconfiguration — secretos en codigo fuente |
Se extrajeron todos los secretos y variables sensibles a archivos .env externos que:
.gitignore)env_file de Docker Compose.env y reiniciar el contenedor sin rebuild.env tienen permisos restrictivos (600) en el servidorEn nodo-01 (nebula.centricasoluciones.com:2202), los archivos .env se ubican junto a cada docker-compose.yml:
/home/sysadmin/docker/compose/
├── nebula/
│ ├── cross-cutting/
│ │ ├── docker-compose.yml # eureka, config-server, gateway, oauth2, monitor
│ │ └── .env # variables compartidas cross-cutting
│ └── business-domains/
│ └── finance/
│ ├── docker-compose.yml # nebula-accounting-core
│ └── .env # variables del dominio finance
├── business/
│ ├── business/
│ │ ├── docker-compose.yml
│ │ └── .env # simappe-admin, games, client, etc.
│ └── server/
│ ├── docker-compose.yml # config-server PRE
│ └── .env
└── datavault/
└── oais/
├── docker-compose.yml
└── .env # DATABASE_URL, paths de workspace
Nota: existen otros
.enven el servidor (MCP, SAR) que son de uso exclusivo de infraestructura y no se distribuyen a desarrolladores.
Estos servicios comparten el mismo conjunto base de variables:
| Variable | Descripcion | Ejemplo |
|---|---|---|
APP_PROFILE |
Perfil activo del servicio | dev |
SPRING_PROFILES_ACTIVE |
Profiles de Spring Boot | common,dev |
CONFIG_ENV |
Directorio de config en el repo Git | dev-config |
EUREKA_SERVICE_URL |
URL del service discovery | http://simappe-eureka-server:8761 |
CONFIG_GIT_URI |
Repositorio Git del config-server | https://gitlab.centricasoluciones.com/... |
CONFIG_GIT_USERNAME |
Usuario Git para config-server | (ver .env) |
CONFIG_GIT_PASSWORD |
Token Git para config-server | (ver .env) |
DB_ENCRYPTION_KEY |
Clave AES-256 base64 para cifrado de passwords en BD | (ver .env) |
DATABASE_TEMPLATE_NO_SQL |
URI MongoDB del template multitenant | (ver .env) |
JAVA_TOOL_OPTIONS |
Flags JVM que sobreescriben los de la imagen | (ver .env) |
TZ |
Zona horaria | America/Bogota |
| Variable | Descripcion |
|---|---|
DATABASE_URL |
DSN PostgreSQL del Datavault |
WATCH_INTERVAL_SECONDS |
Intervalo del watcher |
MAX_UPLOAD_SIZE_MB |
Tamano maximo de carga |
El arquitecto distribuira los archivos .env como un comprimido (.zip o .tar.gz) que contiene solo los .env relevantes para desarrollo. Los desarrolladores no tienen acceso directo al servidor.
El comprimido (environment.tar.gz) mantiene la estructura de directorios del servidor:
environment/
├── nebula/
│ ├── cross-cutting/
│ │ └── .env # eureka, config-server, gateway, oauth2
│ └── business-domains/
│ └── finance/
│ └── .env # nebula-accounting-core
├── business/
│ ├── business/
│ │ └── .env # simappe-admin, games, client
│ └── server/
│ └── .env # config-server PRE
└── datavault/
└── oais/
└── .env # datavault backend
Al recibirlo, descomprime y ubica el .env del subdirectorio que corresponda a tu microservicio en la raiz del proyecto que vayas a ejecutar.
.env que corresponde a tu servicioAlternativamente, si prefieres hacerlo manual, en la misma pestaña Environment haz clic en "Add..." y agrega como minimo:
| Name | Value |
|---|---|
DB_ENCRYPTION_KEY |
(valor del .env) |
SPRING_PROFILES_ACTIVE |
common,dev |
CONFIG_ENV |
dev-config |
Este es el escenario habitual. Tu microservicio corre en tu PC pero consume los recursos de infraestructura del servidor (PostgreSQL, MongoDB, Redis, Kafka, Eureka, Config Server). No necesitas levantar Docker localmente.
VPN OBLIGATORIA. El servidor DEV (
nodo-01) solo existe en la red interna, en10.120.0.2. Todo lo que consuma el nodo exige la VPN de Centrica activa; sin ella nada resuelve ni conecta.
NO edites los .env. Los .env usan nombres de contenedores Docker como hostname (mongodb-dev, simappe-eureka-server, postgres-dev, oracle-xe, ...). Esos nombres se resuelven desde tu PC registrandolos una sola vez en /etc/hosts contra la IP interna del nodo:
10.120.0.2 simappe-config-server simappe-eureka-server simappe-gateway-server simappe-oauth2-server oracle-xe redis-dev kafka-dev postgres-dev mongodb-dev
De esta forma el .env queda tal cual lo recibiste y no hay valores duplicados que mantener. El procedimiento completo (comando idempotente de registro y verificacion) esta en Flujo de Prueba Local, seccion 2.
Lo unico que necesitas es:
.env cargado en STS sin modificar/etc/hosts contra 10.120.0.2common,devSi prefieres correr toda la infraestructura localmente (PostgreSQL, MongoDB, Redis, Kafka, Eureka en tu propio Docker Compose), ajusta los hostnames de tu .env para que apunten a localhost:
# El .env original apunta a la red Docker del servidor:
EUREKA_SERVICE_URL=http://simappe-eureka-server:8761
DATABASE_TEMPLATE_NO_SQL=mongodb://<usuario>:<password>@mongodb-dev:27017/...
# Para infraestructura 100% local, cambia a localhost:
EUREKA_SERVICE_URL=http://localhost:8761
DATABASE_TEMPLATE_NO_SQL=mongodb://<usuario>:<password>@localhost:27017/...
Los valores reales de usuario y password vienen en tu
.env. Nunca se escriben en la wiki ni en ningun repositorio.
Ejecuta tu microservicio desde STS. En la consola de salida, confirma que:
Fetching config from server at: ...)ConnectionSchemaCipher: NO inicializadoRegistration status: 204)Si al levantar un servicio (por ejemplo nebula-accounting-core) ves este error:
SimappeException: ConnectionSchemaCipher: NO inicializado.
Configurar application.security.db-encryption-key en config-server
(env var DB_ENCRYPTION_KEY) para usar el header multi-esquema.
Causa: la variable DB_ENCRYPTION_KEY no esta definida o esta vacia. El archivo de configuracion del config-server referencia esta variable asi:
security:
db-encryption-key: ${DB_ENCRYPTION_KEY:}
El : sin valor default significa que si la variable no existe, queda como string vacio, y el cifrador AES-256-GCM no puede inicializarse.
Solucion: asegurate de que tu archivo .env contenga la linea:
DB_ENCRYPTION_KEY=<valor-base64-de-32-bytes>
Y que el servicio lo este cargando (via env_file en compose o importado en la Run Configuration de Spring Tool Suite — ver Paso 2 de la seccion 4).
.env al repositorio. Verificar que .gitignore incluya .env.env por canales no seguros (Slack, email, WhatsApp). Usar SCP o acceso directo al servidor.env en el servidor deben tener permisos 600 (chmod 600 .env).env en el servidor y distribuira un nuevo comprimido| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.2.0 | 2026-08-05 | Carlos Torres | Purgadas las credenciales en claro de los ejemplos (usuario/password de Mongo): los valores reales viven solo en el .env. Escenario A alineado al flujo vigente: no se editan los .env — los hostnames Docker se resuelven por /etc/hosts contra 10.120.0.2, con VPN obligatoria. |
| 1.1.0 | 2026-06-09 | Carlos Torres | Ajuste: distribucion via comprimido por arquitecto, IDE STS, escenarios local vs servidor, exclusion de .env internos (MCP, SAR) |
| 1.0.0 | 2026-06-09 | Carlos Torres | Creacion de la guia tras migracion de secretos hardcodeados a archivos .env |