Version: 1.0
Fecha: 9 de Junio, 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.
IMPORTANTE: los .env originales usan nombres de contenedores Docker como hostname (ej. mongodb-dev, simappe-eureka-server, postgres-dev). Estos nombres solo resuelven dentro de la red Docker del servidor. Desde tu PC local debes reemplazarlos por la IP del servidor.
Ejemplo de variables que debes ajustar:
# Original (hostname Docker — NO funciona desde tu PC):
EUREKA_SERVICE_URL=http://simappe-eureka-server:8761
DATABASE_TEMPLATE_NO_SQL=mongodb://sysadmin:centrica2026@mongodb-dev:27017/...
# Ajustado para desarrollo local contra el servidor:
EUREKA_SERVICE_URL=http://<IP-DEL-SERVIDOR>:8761
DATABASE_TEMPLATE_NO_SQL=mongodb://sysadmin:centrica2026@<IP-DEL-SERVIDOR>:27017/...
Consulta al arquitecto la IP y los puertos expuestos del servidor de desarrollo.
Lo unico que necesitas es:
.env cargado en STS con los hostnames Docker reemplazados por la IP del servidorcommon,dev (o common,localhost segun tu caso)Si prefieres correr toda la infraestructura localmente (PostgreSQL, MongoDB, Redis, Kafka, Eureka en tu propio Docker Compose), debes ajustar los hostnames en 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://sysadmin:centrica2026@mongodb-dev:27017/...
# Para infraestructura 100% local, cambia a localhost:
EUREKA_SERVICE_URL=http://localhost:8761
DATABASE_TEMPLATE_NO_SQL=mongodb://sysadmin:centrica2026@localhost:27017/...
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.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 |