- From: Noah Kantrowitz <
- Subject: [chef] Re: security of chef
- Date: Tue, 25 Sep 2012 20:46:11 -0700
On Sep 25, 2012, at 8:25 PM, William Herry wrote:
> 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
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
> 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.
Description: Message signed with OpenPGP using GPGMail
Archive powered by MHonArc 2.6.16.