I am building a website and was hoping to deploy it to a DigitalOcean Droplet (running Ubuntu). However, I have a question about setting environment variables in this environment.
In development I am using a .env file and the python-dotenv package to load secrets into my settings. I know that this file should be ignored by Git. On the production server I could create a new .env file to load secrets from. However, I am uncertain about the security of this, as this means that sensitive info (SECRET_KEY, EMAIL_HOST_PASSWORD, etc.) would be in plaintext and could be read by a malicious user if they gained access to the server.
I am aware of other methods of setting environment vars that seem like they may be considered more secure. For example, the DigitalOcean App Platform and others allow you to set environment vars through their interfaces. On the other hand, DigitalOcean Droplets don’t have this feature. I am also aware of services like HashiCorp Vault to store secrets, but, if possible, I would like to avoid that as of now.
Is the method I described above of setting environment vars in production using a .env file considered relatively safe, or should I consider another option?
If you’ve got someone with direct access to your server, you’ve got bigger problems than just access to your environment file. (In a full server environment, there are a number of ways to mitigate this even further, but the basic issue is the same. Once someone gets shell access to the account with access to the environment file, it’s pretty much game-over.)
It’s the right thing to do if you’re loading settings type data via environment variables.
I loved the day I was running projects with 1 settings file and not one per environment. Maintenance on that is so much easier.
So after that it’s a case of using the best tools available to you in order to get those variables loaded in to your remote environments. If you’re just running your own droplet, I think just setting up a file on the server is fine. You’re in control of access to that server, so it’s secure provided you’re doing things right!
Thanks. This logic makes sense. I thought this may have been the case. So, in other words, you think that this method is a viable option then?
OK, thank you for your opinion. As a matter of fact I have separated my development, production, and staging settings into separate files, just delegating sensitive info to a .env file.
If you’re using systemd (or something like that) to start your project, you can set the environment from the service file, restricting the access of that file to root. That provides some protection if someone gets access to the server but doesn’t get root. (If an attacker gets root, then all bets are off regardless of anything else you do.)