[chef] Re: security of chef

[Noah Kantrowitz < >]

On Sep 25, 2012, at 8:25 PM, William Herry wrote:

> Hi
> 
> I've test chef for a while and I really like it, now we want integrate it 
> with openstack for help configure instances, 
> 
> my boss want me to finger it out is it is safe to use chef like this, 
> which I don't think it is, but always think about security is not much bad
> 
> here are the question he want to know
> 
> 1. what info about chef server can client(instance) get?

If you are using open-source chef, nodes can get read-only access to 
everything else on the server but they only have write access to themselves. 
In hosted and private chef there is a full role-based access control system 
so you can dictate exactly what is visible from where.

> 2. is it easy to hack the chef server from client(if client already been 
> cracked)?

Each server gets an RSA key, which should be set as only readable by root (or 
the user that chef-client runs as if that isn't root). If you have that key, 
you can impersonate the node via the API. All that gets you is whatever 
access the node had to begin with though, all data access and manipulation is 
subject to the ACLs I mentioned before. So this boils down to that if one of 
your servers is compromised and either there is a privilege elevation or they 
find another way to read a protected file (bad FS driver, etc), they can get 
the private key material. This has to be done per-server though, as the 
chef-server itself doesn't store any private keys.

> 3. if my chef server have been cracked, how do I know that?

There are Chef cookbooks available for many popular IDS and analysis tools 
(Snort, Tripwire, etc). The details of such things are outside of the scope 
of this mailing list.

> 
> I know chef have no such issue, I know it separated Authentication and 
> Authorization
> but I have to make sure and explain to my boss
> 

To make this part clear, the Chef REST API requires an RSA signature on all 
requests which proves (to whatever degree you trust your attacker isn't 
capable of brute-forcing an RSA private key, or that there is a weakness in 
OpenSSL) who is on the other end. Additionally because it is all just normal 
HTTP, we run the hosted chef (and private chef, but thats normally local) API 
traffic over TLS (HTTPS). You can set this up for the open source server as 
well using something like nginx, apache, or stunnel as a proxy for the API 
service. That covers authentication. The authorization rules I described 
above, for open source it is a simple admin boolean flag on each client 
(admins get full read/write, non-admins get read-only except the node 
matching the name of the client) and for hosted/private it is a customizable 
RBAC system. Hope that makes things clear.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail