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.
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
Archive powered by MHonArc 2.6.16.