🔐 Gestiona tus .env de forma segura (secretos y credenciales en local)

Llevo un tiempo utilizando y probando diferentes asistentes de IA a la programación, y me encantan. Lo único que me preocupa es que por una mala configuración se envíen credenciales a través de la red.

Al final, todos trabajamos con ficheros .env donde tenemos que tener en ocasiones credenciales para realizar diferentes pruebas. Hay muchas estrategias para mejorar la seguridad: principio de mínima responsabilidad, rotación de credenciales, etc. Pero al final el factor humano siempre está ahí por lo que, la mejor forma de evitarlo es no tener credenciales en tu proyecto local.

Me he planteado cómo mejorar esto de forma que pueda trabajar de forma segura, y mi primera aproximación ha sido mover todos los .env fuera de los proyectos en los que trabajo. De esta forma mediante una pequeña utilidad open-source que he desarrollado en Rust, por aprender, leo estas variables según el proyecto/entorno y las inyecto dinámicamente al proceso o al contenedor de Docker.

La seguridad desarrollando en local

La seguridad en en el desarrollo de software es algo esencial, y hay miles de formas de mejorar nuestro procesos. Para mí lo importante son los pequeños detalles del día a día que son fáciles de olvidar (o de saltarte por comodidad): configurar un firewall, gestionar credenciales correctamente, seguir el principio de mínima responsabilidad... Por lo que cuidando estos detalles, ya estamos asentando unas buenas bases.

Últimamente me planteo el uso de los ficheros .env en local, que es una práctica muy común, cómoda y necesaria. Ya que ya sea un fichero .env o un fichero json, siempre necesitaremos tener ciertas credenciales en nuestro ordenador para hacer pruebas.

La aparición de la IA

Con la aparición reciente de los asistentes por IA a la programación, he estado utilizando muchos de ellos y me encanta utilizarlos porque me permiten tanto aprender como desarrollar más rápido. De esto hablaré en otro post.

El problema que he observado es que es fácil que uno de estos ficheros con credenciales pase por el asistente por un descuido, por lo que la información sensible puede terminar viajando por la red y no debería.

Para evitar esto me he preguntado a mí mismo cuál es la mejor forma de desarrollar en local de forma segura, sin tener que preocuparme por mí mismo, ya que al final la mayoría de fallos son humanos.

Y la respuesta es simple: que no haya credenciales en el proyecto en el que trabajo. De esta forma, puedo desarrollar tranquilo ya que no habrá credenciales en mi proyecto.

Gestionando los secretos (.env) en local con Rust

Como llevo un tiempo aprendiendo Rust, y qué mejor forma de hacerlo utilizándolo en pequeños side-projects, he creado secret-manager (GitHub) para gestionar los ficheros .env en un directorio fuera del proyecto actual.

Los ficheros .env se organizan en un directorio externo a tu proyecto y centralizado en ~/.secret-manager/project-env.env. La herramienta desde la línea de comandos te permite acceder a las variables que contienen estos ficheros, y además inyecta las credenciales de forma dinámica a un proceso, de forma que incrementa la seguridad evitando que haya variables de entorno con datos sensibles.

La idea de secret-manager o el comando sm es tener ejecutable en tu terminal que te permite interactuar con estos ficheros de forma cómoda, sin preocuparte de su ubicación o de tener que instalar paquetes de terceros.

Esto es muy útil cuando uno trabaja en pequeños proyectos donde lo más cómodo y rápido es tener las credenciales, por ejemplo de un proveedor cloud o una conexión de producción, para realizar ciertas operaciones. Como comentaba en este otro post, en pequeños proyectos uno puede iterar más rápido con dos entornos: local y producción.

Ahora puedo ejecutar los procesos con sm de la siguiente forma:

cd project/asdf
sm init -> crea el fichero ~/.secret-manager/asdf-dev.env
nano $(sm path) -> edito el fichero de credenciales con un editor sin IA
sm run npm start -> ejecuto npm start inyectándo las variables de entorno dinámicas

docker run --env-file $(sm path) ... -> puedes utilizarlo también con docke

Se me ocurren muchas mejoras de este comando, como integrarlo con sistemas de terceros como 1Password, encriptar datos en local o gestionar diferentes entornos, pero por ahora cumple su función y es que me permite trabajar con tranquilidad sabiendo que los secretos no están en el proyecto.

¿Qué opinas sobre esto? Te leo en X (Twitter).