Question about Hosted Chef


#1

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef
solution. Since we store many credential information in our cook books such
as SSL certificate, passwords and etc, we would like to learn more about
the security mode for hosted Chef solution.

Can anyone please help us on it?

Thanks so much

Jing Li
Senior .Net Developer, The Network for Learning Ltd

D: +64 9 222 0170 | W:
A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052
P: PO Box 37118, Parnell, Auckland 1151

http://www.n4l.co.nz
https://twitter.com/@N4LNZ/ https://www.facebook.com/NetworkForLearning
https://plus.google.com/104649004276520409744/about
http://www.linkedin.com/company/the-network-for-learning-ltd-n4l-


#2

On May 26, 2015, at 9:02 PM, Jing Li jing.li@n4l.co.nz wrote:

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef solution. Since we store many credential information in our cook books such as SSL certificate, passwords and etc, we would like to learn more about the security mode for hosted Chef solution.

Can anyone please help us on it?

The security model is basically that there isn’t one. Chef has lots of awesome engineers but Hosted Chef is, at heart, just a big database-powered web app and so has the same overall security properties as most other apps like that you’ve worked with. One of the major reasons why encrypted data bags were added is it gives you an “out” on the security side of things, Hosted Chef never gets a copy of the decryption key(s) and so within the bounds of AES being considered unbreakable these days you can assume that no possible data leakage from Hosted Chef could disclose the encrypted items. Beyond that you would need to be more specific about what kind of properties you are looking at.

–Noah


#3

Some clarification is required here.

Chef takes the security of Hosted Chef very seriously. For details
please contact Chef Sales and they can supply you with all the information
you need, depending on the types of concerns or compliance requirements you
have.

To Noah’s point, encrypted data bags provide you with additional security
to ensure that even above-and-beyond the security we employ your data is
safe. We highly recommend utilizing encryption to ensure the highest level
of protection. You can learn more about them here:

https://docs.chef.io/chef/essentials_data_bags.html

On Tue, May 26, 2015 at 11:25 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On May 26, 2015, at 9:02 PM, Jing Li jing.li@n4l.co.nz wrote:

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef
solution. Since we store many credential information in our cook books such
as SSL certificate, passwords and etc, we would like to learn more about
the security mode for hosted Chef solution.

Can anyone please help us on it?

The security model is basically that there isn’t one. Chef has lots of
awesome engineers but Hosted Chef is, at heart, just a big database-powered
web app and so has the same overall security properties as most other apps
like that you’ve worked with. One of the major reasons why encrypted data
bags were added is it gives you an “out” on the security side of things,
Hosted Chef never gets a copy of the decryption key(s) and so within the
bounds of AES being considered unbreakable these days you can assume that
no possible data leakage from Hosted Chef could disclose the encrypted
items. Beyond that you would need to be more specific about what kind of
properties you are looking at.

–Noah


#4

Yep, please no one take my comments out of context. Hosted Chef is AFAIK a secure system. When I say there are few security properties I’m talking about provable cryptographic models. This is very different from saying there is no security, just that there is no provable model for why (say) you cannot read another user’s data. That is a property of the system because the code says that you cannot, not because of some fancy trick of math that makes it so. When you start talking about audit logs, ACLs, etc those are a totally different layer of the system :slight_smile:

–Noah

On May 27, 2015, at 1:12 AM, Ben Rockwood benr@chef.io wrote:

Some clarification is required here.

Chef takes the security of Hosted Chef very seriously. For details please contact Chef Sales and they can supply you with all the information you need, depending on the types of concerns or compliance requirements you have.

To Noah’s point, encrypted data bags provide you with additional security to ensure that even above-and-beyond the security we employ your data is safe. We highly recommend utilizing encryption to ensure the highest level of protection. You can learn more about them here:

https://docs.chef.io/chef/essentials_data_bags.html

On Tue, May 26, 2015 at 11:25 PM, Noah Kantrowitz noah@coderanger.net wrote:

On May 26, 2015, at 9:02 PM, Jing Li jing.li@n4l.co.nz wrote:

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef solution. Since we store many credential information in our cook books such as SSL certificate, passwords and etc, we would like to learn more about the security mode for hosted Chef solution.

Can anyone please help us on it?

The security model is basically that there isn’t one. Chef has lots of awesome engineers but Hosted Chef is, at heart, just a big database-powered web app and so has the same overall security properties as most other apps like that you’ve worked with. One of the major reasons why encrypted data bags were added is it gives you an “out” on the security side of things, Hosted Chef never gets a copy of the decryption key(s) and so within the bounds of AES being considered unbreakable these days you can assume that no possible data leakage from Hosted Chef could disclose the encrypted items. Beyond that you would need to be more specific about what kind of properties you are looking at.

–Noah


#5

Thanks so much, your comments actually solved our concerns. Very appreciate.

Jing

On Thu, May 28, 2015 at 4:34 AM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, please no one take my comments out of context. Hosted Chef is AFAIK a
secure system. When I say there are few security properties I’m talking
about provable cryptographic models. This is very different from saying
there is no security, just that there is no provable model for why (say)
you cannot read another user’s data. That is a property of the system
because the code says that you cannot, not because of some fancy trick of
math that makes it so. When you start talking about audit logs, ACLs, etc
those are a totally different layer of the system :slight_smile:

–Noah

On May 27, 2015, at 1:12 AM, Ben Rockwood benr@chef.io wrote:

Some clarification is required here.

Chef takes the security of Hosted Chef very seriously. For details
please contact Chef Sales and they can supply you with all the information
you need, depending on the types of concerns or compliance requirements you
have.

To Noah’s point, encrypted data bags provide you with additional
security to ensure that even above-and-beyond the security we employ your
data is safe. We highly recommend utilizing encryption to ensure the
highest level of protection. You can learn more about them here:

https://docs.chef.io/chef/essentials_data_bags.html

On Tue, May 26, 2015 at 11:25 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On May 26, 2015, at 9:02 PM, Jing Li jing.li@n4l.co.nz wrote:

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef
solution. Since we store many credential information in our cook books such
as SSL certificate, passwords and etc, we would like to learn more about
the security mode for hosted Chef solution.

Can anyone please help us on it?

The security model is basically that there isn’t one. Chef has lots of
awesome engineers but Hosted Chef is, at heart, just a big database-powered
web app and so has the same overall security properties as most other apps
like that you’ve worked with. One of the major reasons why encrypted data
bags were added is it gives you an “out” on the security side of things,
Hosted Chef never gets a copy of the decryption key(s) and so within the
bounds of AES being considered unbreakable these days you can assume that
no possible data leakage from Hosted Chef could disclose the encrypted
items. Beyond that you would need to be more specific about what kind of
properties you are looking at.

–Noah

Jing Li
Senior .Net Developer, The Network for Learning Ltd

D: +64 9 222 0170 | W:
A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052
P: PO Box 37118, Parnell, Auckland 1151

http://www.n4l.co.nz
https://twitter.com/@N4LNZ/ https://www.facebook.com/NetworkForLearning
https://plus.google.com/104649004276520409744/about
http://www.linkedin.com/company/the-network-for-learning-ltd-n4l-


#6

One more question for the charge. We are using auto scaling at the moment,
so some of the nodes will only up for couple of hours per day. We have a
script to de-register this kind of nodes from Chef before it’s going
offline. Then, a brand new node (totally different FQDN and IP) will be
brought to online if required. We are wondering how is monthly charge will
be according to this model?

Thanks
Jing

On Thu, May 28, 2015 at 9:11 AM, Jing Li jing.li@n4l.co.nz wrote:

Thanks so much, your comments actually solved our concerns. Very
appreciate.

Jing

On Thu, May 28, 2015 at 4:34 AM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, please no one take my comments out of context. Hosted Chef is AFAIK
a secure system. When I say there are few security properties I’m talking
about provable cryptographic models. This is very different from saying
there is no security, just that there is no provable model for why (say)
you cannot read another user’s data. That is a property of the system
because the code says that you cannot, not because of some fancy trick of
math that makes it so. When you start talking about audit logs, ACLs, etc
those are a totally different layer of the system :slight_smile:

–Noah

On May 27, 2015, at 1:12 AM, Ben Rockwood benr@chef.io wrote:

Some clarification is required here.

Chef takes the security of Hosted Chef very seriously. For details
please contact Chef Sales and they can supply you with all the information
you need, depending on the types of concerns or compliance requirements you
have.

To Noah’s point, encrypted data bags provide you with additional
security to ensure that even above-and-beyond the security we employ your
data is safe. We highly recommend utilizing encryption to ensure the
highest level of protection. You can learn more about them here:

https://docs.chef.io/chef/essentials_data_bags.html

On Tue, May 26, 2015 at 11:25 PM, Noah Kantrowitz noah@coderanger.net
wrote:

On May 26, 2015, at 9:02 PM, Jing Li jing.li@n4l.co.nz wrote:

Hi There,

We are currently hosting our own Chef Server on AWS, it’s awesome!

As our servers growing, we are looking at to move to the hosted Chef
solution. Since we store many credential information in our cook books such
as SSL certificate, passwords and etc, we would like to learn more about
the security mode for hosted Chef solution.

Can anyone please help us on it?

The security model is basically that there isn’t one. Chef has lots of
awesome engineers but Hosted Chef is, at heart, just a big database-powered
web app and so has the same overall security properties as most other apps
like that you’ve worked with. One of the major reasons why encrypted data
bags were added is it gives you an “out” on the security side of things,
Hosted Chef never gets a copy of the decryption key(s) and so within the
bounds of AES being considered unbreakable these days you can assume that
no possible data leakage from Hosted Chef could disclose the encrypted
items. Beyond that you would need to be more specific about what kind of
properties you are looking at.

–Noah

Jing Li
Senior .Net Developer, The Network for Learning Ltd

D: +64 9 222 0170 | W:
A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052
P: PO Box 37118, Parnell, Auckland 1151

http://www.n4l.co.nz
https://twitter.com/@N4LNZ/
https://www.facebook.com/NetworkForLearning
https://plus.google.com/104649004276520409744/about
http://www.linkedin.com/company/the-network-for-learning-ltd-n4l-

Jing Li
Senior .Net Developer, The Network for Learning Ltd

D: +64 9 222 0170 | W:
A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052
P: PO Box 37118, Parnell, Auckland 1151

http://www.n4l.co.nz
https://twitter.com/@N4LNZ/ https://www.facebook.com/NetworkForLearning
https://plus.google.com/104649004276520409744/about
http://www.linkedin.com/company/the-network-for-learning-ltd-n4l-


#7

On Thu, 28 May 2015, Jing Li wrote:

One more question for the charge. We are using auto scaling at the
moment, so some of the nodes will only up for couple of hours per day.
We have a script to de-register this kind of nodes from Chef before it’s
going offline. Then, a brand new node (totally different FQDN and IP)
will be brought to online if required. We are wondering how is monthly
charge will be according to this model?

I don’t know the answer to this off the top of my head (hey, I only work
here :slight_smile: ) but if you contact sales@chef.io someone will be able to answer
this for you.

  • Julian