Here's what we do (the text below is adapted from our documentation):
Our approach
We use chef's built-in encrypted databags. This solution is less
secure than some of the alternatives, because you need a shared key,
this key is needed by you to encrypt the databag and by the instances
to decrypt the databag. However it is pretty simple, the main problem
is where to store this shared key. We didn't want this key on every
server (it would have meant the key has to be in our bootstrap or
cloudformation template). Therefore we chose to download the key from
S3 when we need it.
The S3 solution is not ideal but with the help of the AWS policy we
deny access to the bucket where the shared keys are, except for an IAM
role which is used by our instances. Therefore if you know where is
the key, you can get it as long as you do it through a server with the
correct IAM profile and by using the tmp credentials.
Creating and updating encrypted databags
The standard process following opscode instructions is to do a knife data bag from file
with the shared key as an argument, however if we
want to do it in our continuous deployment it is a problem because
- each developer needs the key stored locally
- each developer needs knife configured properly (with a key on the
chef account)
- it bypasses our CI by pushing directly to the chef server
- we wouldn't be keeping track of our the encrypted databag in our chef-repo
In order to fix that we created a rake task which will, take a json
formatted databag, download the shared key via an ssh connection to an
instance + an S3 download, encrypt the databag, create a file in the
chef-repo with the encrypted databag. Our CI process will then deploy
the encrypted databag like any other databag.
If you need to update a databag you need to decrypt it, then encrypt
it again. The take task will do that for you.
Using them from chef
Chef will have to download the key from S3, then load the databag and
decrypt it. We created a cookbook which helps to load encrypted
databag.
On Mon, Sep 22, 2014 at 12:11 AM, AJ Christensen
aj@junglistheavy.industries wrote:
this is a Hard Problem.
good article by Noah here: Secrets Management and Chef – Noah Kantrowitz
I like the look of GitHub - oleiade/trousseau: File based encrypted key-value store but haven't
really built out integration with Chef.
Storing secrets in Consul or etcd is high on my to-evaluate list as well!
cheers,
aj
On Mon, Sep 22, 2014 at 4:34 PM, Angus Buchanan
angus.o.buchanan@gmail.com wrote:
What ways have people used to maintain database secrets? I'm thinking
specifically of the mysql root password which is just an attribute in the
mysql cookbook, and passwords for production databases?
I don't want to be checking passwords into Git.
What strategies have you successfully used?
-aob
--
Brian Pitts
Web Operations Engineer