Hello.
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?
2)What to do with bootstrapped servers? Does everyone put it in advance?
On May 20, 2013, at 3:09 PM, nowarry@gmail.com 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.
2)What to do with bootstrapped servers? Does everyone put it in advance?
Yup. It's a shared secret file. It has to be copied over from the Chef Workstation to the nodes at bootstrap time.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
On Monday, May 20, 2013 at 6:08 PM, Brad Knowles wrote:
On May 20, 2013, at 3:09 PM, nowarry@gmail.com (mailto:nowarry@gmail.com) 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 <brad@shub-internet.org (mailto:brad@shub-internet.org)>
LinkedIn Profile: http://tinyurl.com/y8kpxu
--
Daniel DeLeo
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 dan@kallistec.com wrote:
On Monday, May 20, 2013 at 6:08 PM, Brad Knowles wrote:
On May 20, 2013, at 3:09 PM, nowarry@gmail.com 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 brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu--
Daniel DeLeo
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 spheromak@gmail.com 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 dan@kallistec.com wrote:
On Monday, May 20, 2013 at 6:08 PM, Brad Knowles wrote:
On May 20, 2013, at 3:09 PM, nowarry@gmail.com 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 brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu--
Daniel DeLeo
On May 21, 2013, at 12:45 PM, steve . leftathome@gmail.com wrote:
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... )
True enough, but where are the standard procedures or tools documented for doing any of this?
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...
Sure, it's just code. You can do anything you want with code. You can re-write the entire operating system if you want -- it's just code.
A small matter of programming, that's all.
The key is that we don't want to have to invent or reinvent any wheels here.
Most of the people on this list are smarter and more advanced with Chef than we are, so if you've got any existing documented standard procedures or tools for how you do these sorts of things, we'd love to hear about it.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu