[chef] Re: Re: Encrypted data bags

[Daniel DeLeo < >]

On Monday, May 20, 2013 at 6:08 PM, Brad Knowles wrote:

On May 20, 2013, at 3:09 PM, "> wrote:

I have a few questions about using encrypted things in Chef.

1)What is the best practice to distribute encrypted_data_bag_secret to servers?

The short answer is that these things do NOT work like you think they do.

Keep in mind that the only purpose of encrypted data bags is to keep the contents encrypted while it remains on the Chef server. This was meant primarily for use with Hosted Chef, so that people could feel comfortable that their secrets were not exposed if Opscode should happen to have a security problem and the contents of these data bags were somehow leaked.

The contents have to be unencrypted on the Chef Workstation, so that you can encrypt them with the shared key, and then upload the encrypted data bag to the Chef Server.

The contents have to be unencrypted on the nodes, because otherwise it would be impossible to access the information stored in them. And since a shared key is used, once a single node is compromised, then all data bags that were encrypted with that same shared key are now vulnerable across your entire infrastructure.

I repeat, the short answer is that these things do NOT work like you think they do.

This isn't strictly true. At Opscode we have some S3 keys that we only want to make available to one or two machines. Since this is a low churn part of our infrastructure and protecting the keys is worth the hassle, we manually copy the keys over when bootstrapping these nodes. The cookbooks that handle these keys have conditional logic to emit warnings and skip some resources if the encrypted data bag secret isn't available.

The key thing to understand is that there's not a single best practice for all use cases. If you just want to hide your data from Opscode or anyone who might have access to your Chef server's database, then a single shared secret distributed to all nodes will accomplish that. If you only want Chef client on your database servers to see the root database password, then something like we do at Opscode may make more sense.

--

Brad Knowles < "> >

LinkedIn Profile: <http://tinyurl.com/y8kpxu>

-- 

Daniel DeLeo