Gestión de Secretos con GhostEnv

Los archivos .env son uno de los mayores vectores de fuga de secretos en la industria. No es teoría: hay bots que pasan 24/7 escaneando repositorios, commits y backups buscando variables de entorno. Cualquier .env que termine en Git, en un backup o en un log puede exponer claves de API, contraseñas de bases de datos y tokens que ponen en riesgo todo el sistema.

Por eso decidí construir GhostEnv: un gestor de variables de entorno seguro que encripta los secretos y los inyecta en memoria en el momento de ejecución. Está escrito en Go y está pensado también para trabajar en equipo: los desarrolladores no tienen que ver las variables de producción; solo el tech lead las gestiona, y el equipo puede desplegar a producción sin tener acceso a las claves.

En este artículo explico el problema real de los .env, por qué elegí Go para esta herramienta, cómo funciona GhostEnv y cómo usarlo en un flujo de equipo seguro.

El problema: .env en texto plano

Un archivo .env es texto plano. Cualquier proceso con acceso al sistema de archivos puede leerlo. Si se sube a Git por error, queda en el historial. Si un backup incluye el proyecto, incluye el .env. Si alguien hace un dump de memoria o un log de variables, las claves aparecen tal cual.

Peor aún: hay bots automatizados que rastrean repositorios públicos (y a veces commits que se creían privados), buscando patrones como API_KEY=, DATABASE_URL=, SECRET=, PASSWORD=. Cuando encuentran algo, lo indexan y lo venden o lo usan para ataques. No es paranoia; es algo que ocurre a diario.

Las consecuencias son claras: cuentas de cloud vaciadas, bases de datos comprometidas, tokens de servicios externos revocados, y auditorías de seguridad fallidas. Por eso la gestión de secretos no puede ser “un archivo que no se sube a Git”. Tiene que ser encriptación en reposo y inyección solo en runtime para el proceso que lo necesita.

Por qué GhostEnv y por qué Go

Quería una herramienta que:

No guarde secretos en texto plano — ni en disco ni en Git.
Inyecte las variables en el proceso en el momento de ejecución, sin crear archivos .env temporales.
Permitiera trabajar en equipo de forma segura: que el tech lead o quien administra infraestructura gestione las variables, y que el resto del equipo pueda desplegar sin ver las claves.
Fuera multiplataforma y funcionara con cualquier lenguaje o runtime que lea variables de entorno.

Elegí Go por rendimiento, portabilidad y por la facilidad de generar un único binario sin dependencias externas. GhostEnv se distribuye como un ejecutable; no requiere un runtime instalado. Además, Go es adecuado para herramientas de sistema: manejo de procesos, encriptación y acceso al sistema de archivos están bien cubiertos en la librería estándar.

Qué hace GhostEnv

GhostEnv no reemplaza el uso de variables de entorno; las usa. La diferencia es que en lugar de leerlas desde un .env en texto plano, las lee desde bóvedas encriptadas (archivos .gev) y las inyecta directamente en el entorno del proceso hijo cuando ejecutas un comando.

Encriptación y almacenamiento

Algoritmo: AES-256-GCM (encriptación autenticada).
Derivación de clave: Argon2id (resistente a fuerza bruta).
Archivos: Cada entorno (dev, staging, production) puede tener su propio archivo .gev dentro de .ghostenv/ en el proyecto. Fuera del proyecto se usa una bóveda global en ~/.ghostenv.gev.
Permisos: Los archivos de bóveda se crean con permisos restringidos (solo el propietario puede leer/escribir).
Nada en texto plano: Las claves nunca se escriben en disco sin encriptar.

Inyección en runtime

Cuando ejecutas:

ghostenv run -- node app.js

GhostEnv desencripta las variables en memoria, crea el proceso hijo (node app.js) e inyecta esas variables en su entorno. El proceso hijo ve process.env.API_KEY, process.env.DATABASE_URL, etc., pero nunca existió un archivo .env en disco con esos valores. Funciona con Node, Python, Go, Docker, scripts de shell o cualquier binario que use variables de entorno.

Entornos por proyecto

Puedes tener distintos secretos por entorno:

# Desarrollo (por defecto)
ghostenv set API_KEY "dev-key"
ghostenv run -- npm run dev

# Producción (solo el tech lead configura estas)
ghostenv --env production set API_KEY "prod-key"
ghostenv --env production run -- npm run deploy

Los desarrolladores pueden tener solo acceso a la bóveda de dev. La bóveda de production la gestiona solo quien tenga la contraseña maestra de producción (por ejemplo, el tech lead o DevOps). Así, el equipo puede desplegar a producción (ejecutando ghostenv --env production run -- ...) en un pipeline o en un servidor donde la contraseña se inyecte de forma segura (por ejemplo, desde un secret manager del CI/CD), sin que los desarrolladores vean nunca las claves de producción.

Flujo de trabajo en equipo

Tech lead / DevOps: Tiene la contraseña maestra de producción. Configura ghostenv --env production set ... en el servidor o en un entorno seguro, o importa desde un .env que nunca se sube a Git. Puede hacer ghostenv --env production list para ver qué claves existen (no los valores, si no se hace get).
Desarrolladores: Conocen solo la contraseña de dev (o ninguna si usan valores por defecto). Trabajan con ghostenv run -- npm run dev. No necesitan ver las variables de producción.
Despliegue: En CI/CD se configura una única variable (por ejemplo GHOSTENV_PASS) con la contraseña de la bóveda de producción. El pipeline ejecuta ghostenv --env production run -- npm run deploy (o el comando que corresponda). Las variables se inyectan en memoria en ese proceso; nadie tiene que editar .env ni ver las claves en la interfaz del CI.

De esta forma, las variables de entorno no las ven los desarrolladores; solo el tech lead (o quien administre secretos) las gestiona, y el equipo puede desplegar a producción sin tener acceso a las claves.

Uso básico

Instalación (desde código fuente con Go instalado):

git clone https://github.com/SrPlugin/GhostEnv.git
cd GhostEnv
make build
make install

Primeros pasos:

# Definir la contraseña maestra cuando te la pida
ghostenv set API_KEY "tu-clave-secreta"

# Ejecutar la app con las variables inyectadas
ghostenv run -- node app.js

Importar desde un .env existente (por ejemplo, uno que ya no quieras usar en texto plano):

ghostenv import .env
# Opcional: para producción
ghostenv --env production import .env.production

Listar claves (no muestra valores):

ghostenv list
ghostenv --env production list

Todo lo demás (múltiples entornos, export, remove, etc.) está en la documentación del proyecto.

Resumen de ventajas

Sin .env en texto plano: No hay archivos que se puedan filtrar por Git, backups o logs.
Bots y escaneos: Aunque alguien acceda al repo o a un backup, solo verá archivos binarios encriptados, no claves legibles.
Trabajo en equipo: El tech lead controla las variables de producción; los desarrolladores despliegan sin verlas.
Idioma agnóstico: Cualquier lenguaje que use variables de entorno puede usar GhostEnv.
Multiplataforma: Linux, macOS y Windows, con un solo binario.

Mi perspectiva personal

Las fugas de .env no son un fallo de “un desarrollador que subió el archivo”. Son un fallo de diseño: seguir usando texto plano para secretos cuando hay herramientas y prácticas que evitan exponerlos. Los bots que escanean 24/7 hacen que cualquier .env que toque Internet sea un riesgo real.

GhostEnv lo construí para mi propio uso y para equipos que quieran una alternativa simple pero seria: encriptación fuerte, inyección en memoria y separación clara entre quien administra secretos y quien solo ejecuta y despliega. No sustituye a un secret manager corporativo tipo HashiCorp Vault o AWS Secrets Manager cuando ya tienes toda esa infraestructura, pero para proyectos medianos, startups o equipos que quieren dejar de depender del “no subas el .env”, es una opción que reduce el riesgo de forma tangible.

Si te interesa probarlo o contribuir, el proyecto está en GitHub: SrPlugin/GhostEnv. La idea es mantenerlo enfocado: una herramienta, un binario, sin dependencias de runtime, que te permita dejar de tener secretos en texto plano y trabajar en equipo sin que todo el mundo tenga que ver las claves de producción.