Storing .env files

[RyanonRails]

Hey Everyone,

We've been using .env files and foreman for awhile now at AMA and it works great for having config vars out of our repo and keeping the environments separate. But.. We haven't found a really good way to store them. 

We're currently using keychain + dropbox to store them, but we've ran into a few issues:

Tracking changes (what if someone accidentally deletes a line? Changes aren't very visible in Dropbox)

Dropbox being full and bungling up keychain (this causes the keychain to get all out of sync)

Disjointed from our flow

So to open this up.. Has anyone found a really good way to store .env's? This can include backing up heroku ENV's.

Thanks,

Ryan

[Ben Zittlau]

Hey Ryan,

We've recently gone through a big security audit and one of the outcomes of it was the decision that we shouldn't have any secure information (private keys, passwords, etc) in our repos.  The solution we arrived at is to use chef's encrypted data bags to store these assets.  We've just been using this strategy for the last couple weeks and still are in the process of migrating to it fully, but it's looking quite promising.  If you're not using chef this might not be directly applicable, but you might be able to use something conceptually similar.

http://docs.opscode.com/chef/essentials_data_bags.html

Cheers,

Ben

--
You received this message because you are subscribed to the Google Groups "YEGRB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yegrb+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
benzittlau.com

[RyanonRails]

Hey Ben,

Couple questions:

Where is the data_bag_key stored? How does the server decrypt those variables and load them into the app? Does it decrypt on the server? Or during the deploy?

We've been toying around with the idea of keeping an internal gitlab server to manage the keys. It would allow us to have a visible change history and a central location for the keys (with a PR process for ENV changes). It would let us do some 'fancy' things like whenever we do a capistrano deploy we could pull down the most recent version of the .env.

Thanks,

Ryan

[Ben Zittlau]

The key is stored locally on the machine that's running the deploy.  It's moved to the target server to perform the decryption, and then removed afterwards.  All decryption happens on the target server.

I believe this is different than the typical chef setup; we use chef in combination with fabric instead of chef server.

Cheers,

Ben

[Nathan Youngman]

Late to the party.

Just wanted to add that we use and commit .env.development and .env.test to store ENV variables (via via dotenv-rails). This includes keys, but never the same production keys that we have configured in Heroku-land.

We do NOT have a .env.production or bare .env file.

Nathan.

Nathan Youngman
Email: n...@nathany.com
Web: http://www.nathany.com

[Neil Lamoureux]

If you are running on AWS, you can set up IAM roles to eliminate the need to store credentials on servers.  I don't know too much about it, but for a personal project I set up a role to allow an EC2 instance (started with that role) to access a private S3 bucket, all without any access keys.  

See http://aws.typepad.com/aws/2012/06/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2.html 

"You can create an IAM role, assign it a set of permissions, launch EC2 instances with the IAM role, and then AWS access keys with the specified permissions are automatically made available on those EC2 instances."

Neil Lamoureux, VP Engineering
CodeBaby® | codebaby.com

---

From: ye...@googlegroups.com <ye...@googlegroups.com> on behalf of Nathan Youngman <n...@nathany.com>
Sent: Thursday, January 02, 2014 20:56
To: ye...@googlegroups.com
Cc: Ryan Jones
Subject: Re: Storing .env files