Hello,
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 think this is not true (what they told me), but I have not solid arguments to
discuss/use with they.
Can you help me?
On Tue, Feb 7, 2012 at 5:22 AM, faleiros@gmail.com 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:
ubuntu@domU-12-31-39-0B-04-D4:~$ 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] Unix philosophy - Wikipedia
[3] http://community.opscode.com/cookbooks/chef-server
http://wiki.opscode.com/display/chef/Authentication+and+Authorization
You can run the chef server on HTTPS for communication channel
encryption and the signed headers style authentication model ensures
that the chef server is not vulnerable to an SSL replay attack, among
other things.
Cheers,
AJ
On 7 February 2012 23:22, faleiros@gmail.com wrote:
Hello,
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 think this is not true (what they told me), but I have not solid arguments to
discuss/use with they.Can you help me?
Chef uses https for client server communication. Every chef client (nodes,
users who operate /manage chef) uses their own private key. The
registration of clients are done via admin clients or validation client (a
special client that can only register non-admin clients). Communication
between chef server and client never happens in an insecure manner, while
other integration points (like rabitmq to chef server or solr to chef
server) are secured via firewalls and tool specific authentication (like
vhosts and user credentials for rabbitmq).
That said, you can also create custom public key /private key pair and hook
in them to chef server to authenticate your clients/servers against chef
server.
Chef is developed after puppet, there is very little chance that chef will
miss some obvious and important feature that puppet has.
regards
ranjib
On Tue, Feb 7, 2012 at 3:52 PM, faleiros@gmail.com wrote:
Hello,
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 think this is not true (what they told me), but I have not solid
arguments to
discuss/use with they.Can you help me?
Hi,
I think a "standard installation", e.g. from Debian packages in the Opscode
apt repository, of open source Chef servers is not using https by default,
but plain http. Of course you still have signed headers, which makes it
difficult to replay/inject data in the authenticated client/server
communication, however you still can eavesdrop on certain things, most
importantly attributes. This affect those collected by ohai as well as
those that were set on the server for a specific node or role.
Thus if you use Chef on a network where eavesdroppers might hang around,
you should opt for an SSL proxy, which would additionally encrypt the
communication, not only sign it. There is a pretty decent tutorial up on
the Chef wiki.
On a further note, I don't think Chef "missed" this obvious feature of SSL
encrypted communication but instead offers that nice web app on which you
can apply all those standard web techniques that are well investigated, in
this case using apache or nginx as a SSL proxy.
Kind regards,
Oscar
On Tue, Feb 7, 2012 at 11:48 AM, Ranjib Dey ranjibd@thoughtworks.comwrote:
Chef uses https for client server communication. Every chef client (nodes,
users who operate /manage chef) uses their own private key. The
registration of clients are done via admin clients or validation client (a
special client that can only register non-admin clients). Communication
between chef server and client never happens in an insecure manner, while
other integration points (like rabitmq to chef server or solr to chef
server) are secured via firewalls and tool specific authentication (like
vhosts and user credentials for rabbitmq).
That said, you can also create custom public key /private key pair and
hook in them to chef server to authenticate your clients/servers against
chef server.Chef is developed after puppet, there is very little chance that chef will
miss some obvious and important feature that puppet has.regards
ranjibOn Tue, Feb 7, 2012 at 3:52 PM, faleiros@gmail.com wrote:
Hello,
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 think this is not true (what they told me), but I have not solid
arguments to
discuss/use with they.Can you help me?
On Sat, Feb 11, 2012 at 10:24 AM, oscar schneider os4839@googlemail.com wrote:
I think a "standard installation", e.g. from Debian packages in the Opscode
apt repository, of open source Chef servers is not using https by default,
but plain http.Thus if you use Chef on a network where eavesdroppers might hang around, you
should opt for an SSL proxy, which would additionally encrypt the
communication, not only sign it. There is a pretty decent tutorial up on the
Chef wiki.
Yes, exactly. The SSL proxy with Apache tutorial is here:
http://wiki.opscode.com/display/chef/How+to+Proxy+Chef+Server+with+Apache
The latest chef-server cookbook in our github repo has patches to add
support to do this with Nginx as well, and there's some additional
improvements in the cookbook related to SSL proxying. Part of the
release process for the next version of that cookbook will include
additional documentation. You're free to jump into the code and poke
around, of course :-).
--
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman