3 ms·

I've always been uncomfortable with the "store config in the environment" part of the 12 factor app thing, since it does imply storing things like database pass

I've always been uncomfortable with the "store config in the environment" part of the 12 factor app thing, since it does imply storing things like database passwords and such, and the argument is that those shouldn't be in files. But, filesystem permissions are reasonably flexible and are easy to reason about (unlike the potential visibility of ENV). I also don't really buy the arguments for ENV storage of even non-sensitive data. There's just not really any good reason to do so; your config has to be put in place by some tool, even if it is in ENV; why not make your tool produce a file, with reasonable permissions in a well-defined default location? The 12 Factor App article seems to believe that config files live in your source tree, and are thus easily accidentally checked into revision control. That's not where my config files live. My config files live in /etc; or, if I want it to isolate a service to a user, I make a /home/user/etc directory. One could say, "Don't store passwords in the revision control system alongside your source." And that would be reasonable. But, there's no reason to throw the baby out with the bath water.

fubarred 12y ago
Config is ultra-sensitive information. It's like not having the right .gitignore if you're backing up /etc in git or not having enough password log filters. The issue is that ultimately, one has to trust some infrastructure as being of an ultimately trusted network (whether it's Puppet/Chef/cfe2+ or offline authoritative CA's)
aikah 12y ago
> filesystem permissions are reasonably flexible Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line. You don't want your config or keys to depend on an OS,or a language. Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. I believe env variables are better than other solutions.
- mschulze 12y ago
  Spring Boot allows all of this at once [1]. You can specify a configuration file in your sources but if you set specific keys in the environment that configuration has a higher priority. I think this is a very good solution. Particularly this allows you to package a general configuration file, a user can provide an external configuration file and can for a specific instance even overwrite that with env (or command line arguments). [1] http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config http://docs.spring.io/spring-boot/docs/current/reference/htm...
- mreinsch 12y ago
  I agree that ENV variables are useful for general configuration, that's exactly what they were invented for... ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.
  - geocar 12y ago
    Delete sensitive environment variables after you read them, or don't run programs you don't trust with an unsanitary environment/argument list (e.g. execve not system)
    - mreinsch 12y ago
      Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.
- hueving 12y ago
  >just start a server or an app with different env variables in the command line. Just reference a different config file on the command line. >You don't want your config or keys to depend on an OS,or a language. A path to a config file isn't an OS or language. The ini format is pretty widely supported. >Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. This is exactly what filesystem permissions do for files already.

fubarred 12y ago

Config is ultra-sensitive information. It's like not having the right .gitignore if you're backing up /etc in git or not having enough password log filters. The issue is that ultimately, one has to trust some infrastructure as being of an ultimately trusted network (whether it's Puppet/Chef/cfe2+ or offline authoritative CA's)

aikah 12y ago

> filesystem permissions are reasonably flexible Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line. You don't want your config or keys to depend on an OS,or a language. Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. I believe env variables are better than other solutions.

mschulze 12y ago
Spring Boot allows all of this at once [1]. You can specify a configuration file in your sources but if you set specific keys in the environment that configuration has a higher priority. I think this is a very good solution. Particularly this allows you to package a general configuration file, a user can provide an external configuration file and can for a specific instance even overwrite that with env (or command line arguments). [1] http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config http://docs.spring.io/spring-boot/docs/current/reference/htm...
mreinsch 12y ago
I agree that ENV variables are useful for general configuration, that's exactly what they were invented for... ENV variables are not restricted by user though, your process can spawn another process under a different user and give it the same environment. It's the nature of the environment that it is usually inherited from the parent which causes the issues when we're talking about secrets.
- geocar 12y ago
  Delete sensitive environment variables after you read them, or don't run programs you don't trust with an unsanitary environment/argument list (e.g. execve not system)
  - mreinsch 12y ago
    Thanks for that idea of deleting sensitive environment variables. I like that for hosters such as heroku which use ENV variables for config (including secrets) by default.
hueving 12y ago
>just start a server or an app with different env variables in the command line. Just reference a different config file on the command line. >You don't want your config or keys to depend on an OS,or a language. A path to a config file isn't an OS or language. The ini format is pretty widely supported. >Finally Env variables can be restricted to a set of users,so third party process started with a different one cant access them. This is exactly what filesystem permissions do for files already.