[chef] Re: Client/Server secure model

[Bryan McLellan < >]

On Tue, Feb 7, 2012 at 5:22 AM,  
<
 >
 wrote:
> I'm quite new on Chef, but some guys told me that Chef don't use a secure
> channel model between client and server. So they told me to use "Puppet", 
> that
> does this natively  (I'm not talking about use a external tunnel or 
> something
> like that, but about Chef's internal secure communication
> implementation/model).

I haven't used Puppet in a long time, although I just stumbled through
the docs to create an EC2 instance with a master on it. I wanted to
confirm that their SSL implementation hasn't change much, and it
appears it has not.

This is one of the cases where Puppet and Chef have fundamentally
different designs.

Puppet comes with a complete Public Key Infrastructure (PKI) built
into it utilizing SSL. This is convenient for small installations,
because the Puppet master utilizes SSL for both authentication and
encryption. That is, each agent node gets a client key from the
Certificate Authority (CA) built into the Puppet master, which it then
uses to identify itself to the server. Another node or an attacker
would need this private key, stored on the Puppet agent node, to
identify as that agent node to the master. These same credentials are
used to encrypt the connection between the agent and the master using
SSL. Thus, when you connect to the Puppet master (tcp port 8140) you
always do so over SSL:


 :~$
 openssl s_client -connect localhost:8140
CONNECTED(00000003)
depth=1 /CN=Puppet CA: domu-12-31-39-0b-04-d4.compute-1.internal
verify error:num=19:self signed certificate in certificate chain
verify return:0

A long time ago, Chef used OpenID for node authentication but switched
to PKI using signed headers for authentication. The Chef server
creates a client keypair from a self-signed certificate much like the
Puppet master, but the client only uses this for authentication and
the connection to the API on tcp/4000 is not encrypted using SSL. This
is intentional.

The original Chef developers were all former Puppet users, and one of
the design goals was scalability. When running a Puppet master you can
separate the file server from the main server when you're starting to
have scaling issues [1]. It is best practice for both tools to avoid
having all of your nodes contact the server at the same time, but
sometimes you need to have a large number of synchronized runs, such
as when doing deployments to a cluster of web servers. While we tended
to have multiple Puppet masters, one for each environment such as
test, prod, qa, and dev, this became inconvenient at scale and didn't
really help when all of the nodes you wanted to run were against the
same master.

There are a number of scalability differences here. Puppet evaluates
templates on the master but Chef evaluates them on the node. We
believe this to not only be of benefit to scalability, but that it is
also more secure to not be evaluating user-generated Ruby on the
server. However, Chef has more server side features, the biggest being
the built in search system.

Thus, Chef was designed to be modular. Many parts of it can be
disconnected and moved to another server; the database, the search
server, the web interface. You can also run multiple Chef servers
operating against the same database, which Opscode obviously does as
part of Opscode Hosted Chef. Thus, if we're trying to make the service
modular, why would we bake the SSL server into the Chef API? Herein
Chef adheres to the Unix philosophy [2], "Write programs that do one
thing and do it well."

Most users of the Open Source Chef server put an SSL proxy in front of
their Chef Server. There is, of course, a cookbook that can do this
for you [3]. Larger users will put SSL on an nginx load balancer. I've
seen installations where the SSL proxy is on an F5 firewall. These
certificates really should be part of your official PKI infrastructure
and signed however is current practice in your company. If you don't
care how SSL is configured, Puppet helps you by making it simple and
giving it to you for "free" without having to think about it. But we
think that you know best how you want to run SSL in your
infrastructure, so Chef lets you do so easily. I think experienced
builders of infrastructure will recognize from experience that SSL is
a service burden unto itself.

Hopefully this helps understand the difference.

Bryan

[1] http://projects.puppetlabs.com/projects/1/wiki/Puppet_Scalability
[2] 
http://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix
[3] http://community.opscode.com/cookbooks/chef-server