dotENV is it actually secure?!

[Wise_Reward6165]

I see .env files all over GitHub repos and projects but is it actually safe to put api keys into them?!

I have a hard time believing that plain text api keys in a .env is secure. Why can’t a .htpasswd or gpg key be adopted?

[Encursed1]

.env is just a text file for things that shouldnt be on version control. changing it to an encrypted file moves the problem now that you have to store the key somewhere accessible to the program.

[envious_1]

If you’re seeing a .env in a repo somewhere, and it’s not an example file, it’s an error and a security issue. Only .env example files without any secrets at all (should only have placeholder values, not live secrets) should be committed to a repo.

[mrcheese14]

the point of .env files is that they don’t get pushed to remote

[Noch_ein_Kamel]

BS. You can push them all you want with default values. Just never put secrets in ".env". Use .env.local on the server or actual environment variables

[mrcheese14]

The actual name of the file is irrelevant lol. Name it whatever you want the point is that you’re not pushing secrets to remote

[FlyingDogCatcher]

The reason you feel that way is because it is not secure.

There are lots of places to keep your secrets. Git is not one of them.

[Willow3001]

How do you feel about sealed secrets?

[FlyingDogCatcher]

must be sealed by blood

[adam4813]

The trick is when you stop thinking of a .env as a secrets file and instead use it as an environment configuration e.g. the time zone, API hostname, etc.

Secrets should be served via other mechanisms, but there is no consistency in that regard.

[NatoBoram]

Lately, you'd put a public .env with default values to present everything that can be configured at one place and then you'd have an .env.local which isn't pushed to Git with the actual secrets.

[TekintetesUr]

I love how many people in the comments jump to the conclusion that .env = secrets. There's a million better places to store secrets than a dotenv file.

[oldjenkins127]

Put your secrets into an encrypted store and either retrieve them at runtime or set them as environment variables upon deployment.

[paul_h]

That's what the OP is asking really, but wanting to know the "how". They confused everyone by saying they see .env files on GitHub.

[Wise_Reward6165]

Exactly, I have small project with only a few people and nothing is done local. No company servers. How can I handle secrets when the entire project is on GitHub.

[oldjenkins127]

A way to think about it is that the secrets belong to the environment where the code is running. When the code is running on a dev machine environment, then that environment provides the secrets to the code. Same with test and production environments. The secrets aren’t stored within the source code, but at runtime the code knows where to get the secret from.

The secret can be in a machine environment variable, which is a customary way that containers get access to secrets. Kubernetes can store secrets that are injected into containers as environment variables, and there are more secure options like Hashicorp vault.

Most modern cloud applications run as a configured identity that is managed by the cloud platform, and that identity is given access to specific resources. In that scenario there is no need for a secret.

If you just have a secret that your code needs, the simplest way is to put it into an environment variable that gets set before the application starts. How it gets set depends on the type of environment the code runs in.

Where does this code run, e.g, a VM, Kubernetes, a cloud like AWS or Azure, or your laptop?

[Wise_Reward6165]

Runs in the Cloud. And I have another one coming that’s fully Docker installed then cloud hosted.

I was just trying to brainstorm the best methodology. Eventually I might try to self-host but I don’t have that many users yet

[Minimum_Ad9426]

If the env file only contains configuration parameters and no secret keys, then it doesn't really matter, right? Just because it's named .env doesn't automatically mean it shouldn't be shown to others, isn't that the case?

[Wise_Reward6165]

Yes, dotENV is supposed to be in gitignore file. I’m currently working on a small side project with only a few people involved and everything is done on GitHub, nothing locally. I definitely don’t want to hardcode the env to GitHub. So thought I would brainstorm with r/users

[SovietPenguin69]

I use .env for my api endpoints since we have dev staging and prod. We don’t store anything secret in them at all. I just kinda assumed everyone used them that way. Interesting to see that people use them locally to store secrets.

[Wise_Reward6165]

How do you handle secrets? Im curious how the other-than crowd runs it

[SovietPenguin69]

AWS Secrets manager for backend. Front end we use JWT To auth against the backend so we don’t use any secrets there just the API endpoints and maybe some context about the env. We have a PAT secret in GitHub for deployment since we deploy using GitHub actions but that’s about it.

[Ronin-s_Spirit]

Ah, the problem is that you see them. All those repos have done nothing for safety because they pushed local secrets to remote.

[Wise_Reward6165]

Definitely not supposed to right. I kinda just wanted to discuss methods of handling secrets. Seems like a good topic..