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.
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?
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.
> 2. is it easy to hack the chef server from client(if client already been cracked)?
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.
> 3. if my chef server have been cracked, how do I know that?
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.
>
> 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
>
--Noah
Archive powered by MHonArc 2.6.16.