[chef] Re: Re: Re: Re: Database Secrets

[Lamont Granquist < >]

Another way to go about this would be to ACL search results.  If you had a data bag that only one node could read and you couldn't bypass that with search then that would help.  Or you could introduce new objects that weren't indexed and searchable and only the node could retrieve (e.g. a node-like object that was not indexed and was by default created with private permissions so that only admins and the node client key could write to it).  We need to break up the node object anyway since having the run_list and normal attrs stored with the rest of the node attrs is a bit terrible (CHEF-4978).

Hosted would still need encryption, but if you trust the Chef Server you should be able to fix this problem by rubbing ACLs on it.

On 9/22/14, 12:26 PM, Bryan Berry wrote:

" type="cite">

I have thought a lot about this problem and it really requires using a stateful orchestration server to store the secerets and arbitrate access to them. Why the orchestration server? Because the orchestration server can verify the identity of your instances, encrypt the secrets using instance specific creds, and can remove access for instances that have been destroyed. Sadly I am not aware of an open source tool that currently does this.

On Sep 22, 2014 9:00 PM, "Lamont Granquist" < "> > wrote:

Can't quite understand exactly what your implementation is.  However, everyone should be aware that by default the clients group is allowed read access to all the cookbooks -- so any node on your network can read any cookbook.  Without managing the default Chef ACLs you cannot publish secrets in cookbooks/recipes and expect them to stay secret from attackers who control one of your nodes at all.  There's also still the search loophole where any Chef ACL can be defeated if you can get search to return a result (although cookbooks are not indexed).  Obviously if you try to leverage using cookbooks to push out encrypted data bag secrets in order to use encrypted data bags, then attackers can read the cookbooks to get the encrypted data bag secrets in order to decrypt the data bags.

So,

#1 don't store unencrypted secrets in cookbooks/recipes
#2 don't store unencrypted secrets in data bags
#3 don't store unencrypted secrets in node data ('normal' attrs, roles, environments, etc)
#4 the decryption keys for encrypted databags are unencrypted secrets and rules #1, #2, and #3 apply.

On 9/21/14, 10:09 PM, Marco Betti wrote:

Hi,

we store encryption secret file within separate git repos (one different repo for each environment cookbook it refers to) with very restricted access despite to each environment cookbook chef repo that contains encrypted data bag items only.
In this way we don'let cookbooks to generate random passwords out of our control, but we decide our passwords rules and change policies.

Regards,
Marco

Il 22/set/2014 06:34 "Angus Buchanan" < " target="_blank"> > ha scritto:

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