Furthermore, environmental variables are probably on-par security wise. For example, I believe...
DATABASE_URI=mysql://foo:bar@localhost/myDatabase ... could be queried from the /proc directory on Linux, just like other command line parameters for any running process once you have a shell account on the box. You might want to see if that is the case first before using that strategy. The best bet is to use some sort of crypto to at least obscure the password properly (although private keys will always need to be accessible, unless you manually start the server and enter your passphrase). However, I'm yet to do that on Rails so I can't give you specifics. Cheers, Nigel On Sun, Jul 29, 2012 at 7:33 PM, Nigel Sheridan-Smith <[email protected]>wrote: > Hi all, > > Can't say I know of any specific horror stories, but there is at least one > sizeable Australian company that used to have "password" as the password on > every VCS user account. Not sure if they ever ended up fixing that. > > Plus it's fairly trivial to take complete control of a server with > privileged access to most databases. Are you sure you want that? > > Nigel > ex-Pentester > > > > On Sun, Jul 29, 2012 at 4:15 PM, Michael Pearson <[email protected]>wrote: > >> .. getting way off topic here. >> >> Personally, I'm still undecided as to whether "credentials in VCS" is >> enough of a security issue that it justifies either: >> >> - hand-entering credentials on a per system basis >> - bespoke credential distribution solutions such as the one described >> below >> >> I kinda like the chef encrypted data bag solution, assuming you've rolled >> your own chef server (how is trusting opscode any better/worse than >> trusting github?) >> >> Anybody care to share some horror stories on having creds in VCS (or >> other developer or external party sources) that led to an incident? >> >> On Sun, Jul 29, 2012 at 4:06 PM, Chris Berkhout >> <[email protected]>wrote: >> >>> At REA we have a config service that is queried via HTTP and tailors >>> its response based on the hostname of the request (which should >>> indicate the environment). Our DNS setup takes care of making the >>> config service available on the same hostname in all environments. >>> >>> Our config service client writes the results into files that can be >>> sourced to set the environment variables. It's probably nicer to not >>> write that stuff at all when you can avoid it, but you should make >>> sure you don't pass credentials as command line parameters that are >>> visible to anyone who can list running processes. >>> >>> This is different from Heroku and the 12factor idea of having build + >>> config = release. We version control the builds but they get whatever >>> config is current for the given environment. >>> >>> The sensitive data has to go somewhere, but not in in the app code and >>> also not in your chef/puppet scripts. You could put it in its own >>> repo, which would let you see what happened to config over time, but >>> it's probably better to have config destroyed forever when it is no >>> longer current. >>> >>> Cheers, >>> Chris >>> >>> >>> On Sun, Jul 29, 2012 at 2:09 PM, James Healy <[email protected]> wrote: >>> > 2012/7/29 Mike Bailey <[email protected]> >>> >> >>> >> When and how are you setting the environment variable? >>> > >>> > I'm interested in this too. I've worked on apps with two dozen or more >>> > environment dependent config options (databases, API keys, admin email >>> > addresses, etc) and they usually end up being stored in version >>> > control in one way or another (in the project or separate chef >>> > recipes). >>> > >>> > I like the idea of setting the config values via ENV vars, but how >>> > should I set them without also storing sensitive data as cleartext in >>> > a repo somewhere? >>> > >>> > James >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "Ruby or Rails Oceania" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> [email protected]. >>> > For more options, visit this group at >>> http://groups.google.com/group/rails-oceania?hl=en. >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby or Rails Oceania" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/rails-oceania?hl=en. >>> >>> >> >> >> -- >> Michael Pearson >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> > > > > -- > http://www.whossingle.net - check out who's available, engaged or taken > amongst > your friends and their friends > http://www.joinsomeone.com <http://www.partneredup.com> > > *Dr Nigel Sheridan-Smith PhD BE* > Mob: 0403 930 963 > Email: nigel --AT-- joinsomeone.com > LI: http://www.linkedin.com/in/nsheridansmith > > > -- http://www.whossingle.net - check out who's available, engaged or taken amongst your friends and their friends http://www.joinsomeone.com <http://www.partneredup.com> *Dr Nigel Sheridan-Smith PhD BE* Mob: 0403 930 963 Email: nigel --AT-- joinsomeone.com LI: http://www.linkedin.com/in/nsheridansmith -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
