4 ms·

I've always wondered the proper way to deal with this, and this makes total sense. How would you typically set such an environment variable? In bash init?

xasos 12y ago
It depends on language. In node, you can set environment variables in the code with process.env and Python with os.environ and then use those to specify the values on the command line. In fact, even services like Heroku will let you edit these from their web-based client.
- kbenson 12y ago
  That's really more of an implementation detail though. You'll want a file to specify these environment variables, so you can actually have services start on boot, so that means you need a config file (whether it's used for setting the environ, or read directly by the application is the implementation detail). What's really needed is to correctly separate and secure important configuration options outside of source, and designing for that from the beginning. Using environment variables in a way forces this, which is good, but it doesn't help if there's just a startup script that specifies those variables and it gets accidentally committed to the repo.
sesteel 12y ago
Environment variables can work well for development but I wouldn't put them in .bashrc or .bash_profile; if you are like me, you like to store your dot files somewhere public. I typically leave them in an encrypted file on dev systems, but this only solves the accidental over the shoulder problem. Production systems require another level of security altogether. Typically, I've seen services run in restricted user accounts with limited system access, reading passwords out of an encrypted file. This file is stored in some obscure location on the box to which that user account is the only one with read permissions to. Keep in mind, every system has weaknesses and I am still interested in listening to others' approaches.
- jemfinch 12y ago
  > if you are like me, you like to store your dot files somewhere public. In your public .bashrc, put a line "source .bashrc.secret." Just keep an empty .bashrc.secret in your public repository, and keep your actual secret credential on your machines.
  - mateuszf 12y ago
    And don't forget to add it to .gitignore, otherwise when overwritten accidently it might land in public repo.
    - devonkim 12y ago
      That's a fantastic way to TELL attackers what filename to search for on a filesystem if they have access to your source code. Randomizing filenames and forcing an attacker to have to write a custom utility to find the path to files keeps you from getting hit by a number of drive-by hackings. And every single incorrect use of a credential must be recorded off-system and monitored. Avoid using defaults in general for any third party software and you can do things like generating random paths to S3 buckets that contain certificates and environment variables in your own software. S3 buckets are incredibly secure if you tack on CloudHSM plus use host certificates effectively with IAM policies. Otherwise, I'd try to use keystore systems available on your respective OS or language platform toolchain (CSP on .NET, JCE for Java, I dunno wtf else you'd use for anything else because the only people I've heard of that want to go this far are all F500 enterprises basically with software in exactly those two languages only).
      - tlrobinson 12y ago
        You can create a global .gitignore: https://help.github.com/articles/ignoring-files/ https://help.github.com/articles/ignoring-files/
reinhardt 12y ago
Envdir [1] or its python port [2] are one way to organize environment variables [1] http://cr.yp.to/daemontools/envdir.html http://cr.yp.to/daemontools/envdir.html [2] http://envdir.readthedocs.org/en/latest/ http://envdir.readthedocs.org/en/latest/
robin_reala 12y ago
I’ve had good luck with foreman [0] (if you’re happy with Ruby). Create a .env file in your project root with your variable pairs and foreman makes them available inside your app. Then you just need to make sure .env is in your .gitignore and you’re happy. [0] https://github.com/ddollar/foreman https://github.com/ddollar/foreman

xasos 12y ago

It depends on language. In node, you can set environment variables in the code with process.env and Python with os.environ and then use those to specify the values on the command line. In fact, even services like Heroku will let you edit these from their web-based client.

kbenson 12y ago
That's really more of an implementation detail though. You'll want a file to specify these environment variables, so you can actually have services start on boot, so that means you need a config file (whether it's used for setting the environ, or read directly by the application is the implementation detail). What's really needed is to correctly separate and secure important configuration options outside of source, and designing for that from the beginning. Using environment variables in a way forces this, which is good, but it doesn't help if there's just a startup script that specifies those variables and it gets accidentally committed to the repo.

sesteel 12y ago

Environment variables can work well for development but I wouldn't put them in .bashrc or .bash_profile; if you are like me, you like to store your dot files somewhere public. I typically leave them in an encrypted file on dev systems, but this only solves the accidental over the shoulder problem. Production systems require another level of security altogether. Typically, I've seen services run in restricted user accounts with limited system access, reading passwords out of an encrypted file. This file is stored in some obscure location on the box to which that user account is the only one with read permissions to. Keep in mind, every system has weaknesses and I am still interested in listening to others' approaches.

jemfinch 12y ago
> if you are like me, you like to store your dot files somewhere public. In your public .bashrc, put a line "source .bashrc.secret." Just keep an empty .bashrc.secret in your public repository, and keep your actual secret credential on your machines.
- mateuszf 12y ago
  And don't forget to add it to .gitignore, otherwise when overwritten accidently it might land in public repo.
  - devonkim 12y ago
    That's a fantastic way to TELL attackers what filename to search for on a filesystem if they have access to your source code. Randomizing filenames and forcing an attacker to have to write a custom utility to find the path to files keeps you from getting hit by a number of drive-by hackings. And every single incorrect use of a credential must be recorded off-system and monitored. Avoid using defaults in general for any third party software and you can do things like generating random paths to S3 buckets that contain certificates and environment variables in your own software. S3 buckets are incredibly secure if you tack on CloudHSM plus use host certificates effectively with IAM policies. Otherwise, I'd try to use keystore systems available on your respective OS or language platform toolchain (CSP on .NET, JCE for Java, I dunno wtf else you'd use for anything else because the only people I've heard of that want to go this far are all F500 enterprises basically with software in exactly those two languages only).
    - tlrobinson 12y ago
      You can create a global .gitignore: https://help.github.com/articles/ignoring-files/ https://help.github.com/articles/ignoring-files/

reinhardt 12y ago

Envdir [1] or its python port [2] are one way to organize environment variables [1] http://cr.yp.to/daemontools/envdir.html http://cr.yp.to/daemontools/envdir.html [2] http://envdir.readthedocs.org/en/latest/ http://envdir.readthedocs.org/en/latest/

robin_reala 12y ago

I’ve had good luck with foreman [0] (if you’re happy with Ruby). Create a .env file in your project root with your variable pairs and foreman makes them available inside your app. Then you just need to make sure .env is in your .gitignore and you’re happy. [0] https://github.com/ddollar/foreman https://github.com/ddollar/foreman