Are Enviornment Variables Still Considered a Secure Choice for Production?
I am hosting my Django website, and I am very concerned about security measures and implementations. However, I feel like system environment variables saved in servers (in my example I am using Koyeb) or files have a security issue with them. Is this the case? If so, what are some very low cost, low maintenance (I had trouble with Google Secret Manager before), methods to keep my secrets secure and safe?
I would suggest to avoid them by all means. And this is not “still”. It was a bad idea in the first place.
Some may disagree, but I doubt they have convincing arguments. Generally, an application should be functionally independent from the environment as much as possible. Not only from the environment variables, but from all the environment details.
I mostly agree with Surgey, but where we still find them useful is to reference the key stores where you retain the actual key values.
But never store secrets or keys in environment variables.
"an application should be functionally independent from the environment as much as possible" is quite a weak argument to make against environment variables. An application being independent from its environment is an illusion, where does the application run? On a machine, that machine is its environment. You literally cannot have an application run without an environment.
Let's keep that aside and consider some specific things. Let's say you want to deploy multiple instances of an application each with it's own database. Now where should this config live? Let's say you disagree with environment variables. What other choices are there? On the disk? Isn't that also the "environment"? In some separate secret store? What about the config and credentials for this secret store then, where does that live? Independence from the environment simply isn't a convincing argument to avoid environment variables.
Technically and as far as you should concerned, due to drive failures, they could potentially contribute to memory leaks because they are stored variables. No, this is not secure because of JIT. There is an opportunity cost. Better go with cryptographic hashing.
Where are the settings actually stored? Who else can log in to your servers? What are you concerned about?
Is it secure to store passwords as environment variables (rather than as plain text) in config files? discusses environment variables vs. local files in some depth. The core risk of environment variables seems to be that you'll accidentally leak them through diagnostics; of local files, that you'll accidentally check them into source control. Is it unsafe to use environmental variables for secret data? on [security.se] also talks about a couple of things like environment variables being passed to child processes and core dumps.
I largely work in container environments like Kubernetes and plain Docker, and from a code point of view environment variables tend to be more usable than other options. You can change a single environment-variable setting independently of other configuration at the container-configuration layer. If for example the database hostname varies by installation then it's easy to inject this into an environment variable, and much harder to generate a configuration file that contains it.
The most actually secure option is to use some sort of external secret store. You mention Google Secret Manager, AWS has a similar service, Hashicorp Vault is the most popular open-source option I know of. Your service needs to identify itself somehow still, and you need to wire the secret-store configuration into your application-framework configuration, but having done this, you have no secrets locally at all aside from the one credential to access the service store, and often this can be injected for you.
This is not a cure-all! In a Kubernetes context: if a developer can create a Pod for whatever purpose, then they can create it with whatever ServiceAccount they want; which means they can impersonate the real service to the secret store. In a Django context: if you're going to start up, interrogate Vault once, and store the results in a global variable, it's still very possible code bugs and debuggers can leak secrets. If you have some guarantee that nobody else can log into your server, and you don't have a corporate security team requiring a specific setup, then either environment variables or local files can be just fine.
Again, I say as much as possible. I did not say just independent. So, if this is an illusion, this is not my illusion. Your statement that my argument is weak is an arbitrary judgment.
The truly robust configuration is using a configuration file associated with the particular application, and not anything system-wide.
Sorry, your opinion doesn't look convincing.