General discussion about Chef

[chef] Re: Re: Re: Re: Encrypted data bags


Chronological Thread 
  • From: "steve ." < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Encrypted data bags
  • Date: Tue, 21 May 2013 11:45:31 -0700
For that matter, there's nothing that says you _have_ to encrypt/decrypt the data bag item with the key that's in the default location on the chef-client.  You can distribute keys through a web service that performs some other means of authentication.  You can distribute keys through your favorite orchestration layer, assuming you have one.  (Or Pushy, though I haven't seen it running anywhere outside of Opscodeland yet... )

The nice thing about doing it that way is that re-keying is fairly straightforward, and the easier it is to re-key, the more likely it is that you'll do so on a regular basis.

That having been said, yeah, it's still a shared key and you're still compromising the data bag item if the key on disk gets compromised.  But as long as you can write some Ruby code to deliver the key contents somehow to the function that loads the encrypted data bag item in your recipe (or library), you can solve this problem any way you like...



On Tue, May 21, 2013 at 10:17 AM, Jesse Nelson < " target="_blank"> > wrote:
Gonna toss a shout out to knife-vault[1] here.  Which will let you encrypt a bag using the key from a host (or set of hosts). In this way you don't have to keep/distribute another secret, and only those hosts can get at that bag.



On Tue, May 21, 2013 at 8:21 AM, Daniel DeLeo < " target="_blank"> > wrote:

On Monday, May 20, 2013 at 6:08 PM, Brad Knowles 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.

-- 
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§