Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: From dotenv to dotenvx – better config management

dotenvx.com

Post reply on HN
Print view View original

201–210 of 223 posts

Re: Show HN: From dotenv to dotenvx – better config management

#201

Post by macNchz »

qweqwe14 wrote: post #152
itchyouch wrote: post #149

Earlier quoted context omitted.

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

There isn't a right answer. It's just that people don't understand that one doesn't provide any meaningful benefit over the other (in the context of storing secrets), but the security "experts" are always eager to claim "X is insecure, do Y instead, it's best practice btw" Unless I'm missing something, there are three scenarios where this comes up: 1. You are using a .env file to store secrets that will then be passe…

I’d wager that–in the context of web apps–over time there have been many more (or more readily exploitable) arbitrary file read/directory traversal/file inclusion vulnerabilities than remote code execution ones, so the preference for having secrets in memory as env vars may stem from that. You’re also probably not reading from /proc/self/mem without code execution either.

Re: Show HN: From dotenv to dotenvx – better config management

#202

Post by Alifatisk »

So with this, I have to prefix every executable with dotenvx in order to utilize the env variables?

Can’t I somehow do this in the script itself so “ruby index.rb” is enough? I know I’m only saving a couple of characters in the command line but I’m asking out of curiosity.

Re: Show HN: From dotenv to dotenvx – better config management

#203

Post by lucasyvas »

jen20 wrote: post #191
jillesvangurp wrote: post #168

Earlier quoted context omitted.

Disagree here. Basically if you use docker (which for most of the stuff you mention, you should), environment variables are pretty much how you configure your docker containers and a lot of sever software packaged up as docker containers expects to be configured this way. Building a lot of assumptions into your containers about where and how they are being deployed kind of defeats the point of using containers. You s…

> The right time to access secret stores is just before you start the container as part of the deploy process or vm startup in cloud environments. So how do you rotate secrets without bouncing app servers..?!

You don’t - you bounce the servers because it’s simpler. If your secret is static for the lifetime of a deployment - just redeploy to get a new value.

I like secret stores but only when the value of something regularly changes in a way that redeploying becomes unacceptable.

Re: Show HN: From dotenv to dotenvx – better config management

#204

Post by qweqwe14 »

macNchz wrote: post #201
qweqwe14 wrote: post #152

Earlier quoted context omitted.

There isn't a right answer. It's just that people don't understand that one doesn't provide any meaningful benefit over the other (in the context of storing secrets), but the security "experts" are always eager to claim "X is insecure, do Y instead, it's best practice btw" Unless I'm missing something, there are three scenarios where this comes up: 1. You are using a .env file to store secrets that will then be passe…

I’d wager that–in the context of web apps–over time there have been many more (or more readily exploitable) arbitrary file read/directory traversal/file inclusion vulnerabilities than remote code execution ones, so the preference for having secrets in memory as env vars may stem from that. You’re also probably not reading from /proc/self/mem without code execution either.

Well, if there's an arbitrary file read, shouldn't the attacker be able to just read /proc/PID/environ anyway? It behaves like a regular file in that regard, unlike /proc/PID/mem, which requires seek operations to read data.

Re: Show HN: From dotenv to dotenvx – better config management

#205

Post by pak9rabid »

dagss wrote: post #165

Something I have done for secrets is use a syntax in environment variables to tell the process to go a key vault for the secret. So we can have FOOPW=pw1 when testing locally, but FOOPW="{vault1:secret1}" in production. Env vars are processed simply by running a regex with callback that fetches secrets from vaults. This is quite flexible and has the advantage of being able to inject the secrets in the same place as o…

Hah! I've done something similar. In my case, I could have something like this in my .env file:

SOME_CONFIG_OPTION = @AWS::some_config_option

And I've written a config library that knows that when a config value starts with `@AWS::' it needs to resolve the config option to an actual value by reaching out to AWS's Secrets Manager service and looking it up there, in which case it receives the value and caches it locally so that subsequent references to this configuration option don't require an additional call out to the cloud.

It works surprisingly well.

Re: Show HN: From dotenv to dotenvx – better config management

#206

Post by justinclift »

itchyouch wrote: post #149
skissane wrote: post #134

Earlier quoted context omitted.

> Instead, read secrets from a vault or from a file-system from _inside_ your process. I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that cont…

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

Pull them from a remote host over ssh? :D

Re: Show HN: From dotenv to dotenvx – better config management

#207

Post by jampekka »

qweqwe14 wrote: post #152
itchyouch wrote: post #149

Earlier quoted context omitted.

I used to store secrets in the FS, and was told the best practice was env vars. Now it's not env vars. What is it then?

There isn't a right answer. It's just that people don't understand that one doesn't provide any meaningful benefit over the other (in the context of storing secrets), but the security "experts" are always eager to claim "X is insecure, do Y instead, it's best practice btw" Unless I'm missing something, there are three scenarios where this comes up: 1. You are using a .env file to store secrets that will then be passe…

The main security benefit of byzantine paranoid security best practices is that they massively hinder productivity. If you can't make a system, the system will have no vulnerabilities.

Re: Show HN: From dotenv to dotenvx – better config management

#208

Post by qweqwe14 »

jampekka wrote: post #207
qweqwe14 wrote: post #152

Earlier quoted context omitted.

There isn't a right answer. It's just that people don't understand that one doesn't provide any meaningful benefit over the other (in the context of storing secrets), but the security "experts" are always eager to claim "X is insecure, do Y instead, it's best practice btw" Unless I'm missing something, there are three scenarios where this comes up: 1. You are using a .env file to store secrets that will then be passe…

The main security benefit of byzantine paranoid security best practices is that they massively hinder productivity. If you can't make a system, the system will have no vulnerabilities.

lmao so true

Re: Show HN: From dotenv to dotenvx – better config management

#209

Post by darkwater »

cimnine wrote: post #88

I think it's good advice to not pass secrets through environment variables. Env vars leak a lot. Think php_info, Sentry, java vm dumps, etc. Also, env vars leak into sub-processes if you don't pay extra attention. Instead, read secrets from a vault or from a file-system from _inside_ your process. See also [1] (or [2] which discusses [1]). Dotnet does this pretty good with user secrets [3]. [1] https://blog.diogomoni…

Remember we are mainly talking about dev envs here. If you put the secret key in a file...where do you put the file? In a common location for all the dotenv instances? One per dotenv instance? What if people start putting it as a dotfile in the same project directory?

Re: Show HN: From dotenv to dotenvx – better config management

#210

Post by andrewmcwatters »

nprateem wrote: post #175
TristanBall wrote: post #161

Earlier quoted context omitted.

Did they say why? It strikes me that those envs might be particularly prone to corporate inertia, ieg "the current way passed security audit, don't change it or we need to requalify" It's possibly also harder to rely on a HSM when your software is in a container? ( I'm guessing here tho )

It's a useless, unproveable generalisation from a supposedly omniscient "insider". I know of at least one finance organisation using HSM as you'd expect.

Yeah, you don't have to trust me, there are plenty of software engineers working in finance who can tell you the same. Or they're using outdated ciphers, or they're storing information in plaintext or in logs, or they have no security playbooks.

It's irrelevant to me whether you believe it, it's happening today, and it happens with some of the top financial institutions and their subsidiaries and it's the same bureaucratic nonsense to move those teams to do something about it like it is anywhere else.

Post reply on HN