🔐 Manage your .env files securely (local secrets and credentials)

I have been using and testing different AI programming assistants for a while now, and I love them. The only thing that concerns me is that misconfiguration could lead to credentials being sent over the network.

In the end, we all work with .env files where we sometimes need credentials for different tests. There are many strategies to improve security: the principle of least privilege, credential rotation, etc. But ultimately, the human factor is always there, so the best way to avoid it is to not have credentials in your local project.

I have been thinking about how to improve this so that I can work securely, and my first approach has been to move all the .env files out of the projects I work on. This way, using a small open-source utility that I developed in Rust, just for learning purposes, I read these variables according to the project/environment and dynamically inject them into the process or Docker container.

Security while developing locally

Security in software development is essential, and there are thousands of ways to improve our processes. For me, it's the small day-to-day details that are easy to forget (or skip for convenience): setting up a firewall, managing credentials correctly, following the principle of least privilege... By taking care of these details, we are already laying a solid foundation.

Lately, I have been considering the use of .env files locally, which is a very common, convenient, and necessary practice. Whether it's a .env file or a json file, we always need to have certain credentials on our computer for testing purposes.

The rise of AI

With the recent emergence of AI programming assistants, I have been using many of them, and I love using them because they allow me to learn and develop faster. I will talk about this in another post.

The problem I have observed is that it's easy for one of these files with credentials to pass through the assistant due to a careless mistake, which can result in sensitive information traveling over the network, which shouldn't happen.

To avoid this, I have asked myself what is the best way to develop locally securely, without having to worry about myself, as most failures are human errors in the end.

And the answer is simple: there should be no credentials in the project I'm working on. This way, I can develop with peace of mind knowing that there are no credentials in my project.

Managing secrets (.env) locally with Rust

Since I have been learning Rust for a while, and what better way to do it than by using it in small side projects, I have created secret-manager (GitHub) to manage .env files in a directory outside the current project.

The .env files are organized in an external directory, centralized at ~/.secret-manager/project-env.env. The tool allows you to access the variables contained in these files from the command line, and it also dynamically injects the credentials into a process, thus increasing security by avoiding environment variables with sensitive data.

The idea behind secret-manager or the sm command is to have an executable in your terminal that allows you to interact with these files conveniently, without worrying about their location or having to install third-party packages.

This is very useful when working on small projects where it's more convenient and faster to have credentials, for example, from a cloud provider or a production connection, to perform certain operations. As I mentioned in another post, in small projects, one can iterate faster with two environments: local and production.

Now I can run processes with sm in the following way:

cd project/asdf
sm init -> creates the ~/.secret-manager/asdf-dev.env file
nano $(sm path) -> edit the credentials file with a non-AI editor
sm run npm start -> execute npm start injecting dynamic environment variables

docker run --env-file $(sm path) ... -> you can also use it with Docker

I can think of many improvements for this command, such as integrating it with third-party systems like 1Password, encrypting data locally, or managing different environments, but for now, it serves its purpose, and it allows me to work with peace of mind knowing that the secrets are not in the project.

What do you think about this? I read you on X (Twitter).