61–70 of 223 posts
On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command? I suppose if you don’t want it to stay after execution i believe you can: > $(source .env; my command) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file
I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.
Just set those env vars in your IDE. Let your IDE or docker-compose or whatever read an .env file if you must. But don't do it directly from your application code, indeed you're one lazy dev away from putting an .env file on prod servers. Using dotenv-like constructions is, in my eyes, an antipattern.
How is that different from a dotenv, other than location of where the k/v persists?
And the attackers will be after this file not the .env anymore.
It looks great nonetheless, especially the cross-language feature.
In Rails, the entire file is encrypted unlike here where only the secrets are
On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command? I suppose if you don’t want it to stay after execution i believe you can: > $(source .env; my command) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file
I don't really understand why this is a new project. Seems it would have been pretty simple to add these in a backwards compatible way. It would only break in cases where people's values specifically started with "encrypted:"
I've never used it (knowingly) but if I did and wanted to use this new version/project even the CLI name change to append 'x' would be annoying (I'd probably alias /symlink it).
This is similar to how Rails handles secrets - https://edgeguides.rubyonrails.org/security.html#environment... In Rails, the entire file is encrypted unlike here where only the secrets are
I don't really understand why this is a new project. Seems it would have been pretty simple to add these in a backwards compatible way. It would only break in cases where people's values specifically started with "encrypted:"
Encrypting secrets and committing them seems very convenient but I'm paranoid about these sorts of things. Can anyone tell me why this would be a bad idea? One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally…
Using encrypted secrets provides a way better developer experience than using a vault. Typically, developers can’t change production secrets in vaults and need to follow some other protocols. Encrypted secrets mean you deploy everything along side the secrets. The developer experience is great, but the biggest issues I have faced while using Kubeseal were 1. Developers HAVE the secret in order to encrypt it. This can…
It’s a learning curve, but I think it’s best to just bite the bullet and use a vault rather than trusting developers to know and manage secrets properly.
We’ve been pushing for committing encrypted secrets for many years now, and have written an open source spec and implementation in multiple languages: https://github.com/neosmart/securestore-rs
I've used it at two jobs now over about 5 years and have had zero issues.