Chef security - Are payload signed

Chef Infra (archive)
1

Im just doing my initial research into Chef. Trying to follow a Chef Tutorial For Beginners. And i started wondering about the security.

Do the nodes trust the server, or are the cookbooks signed on the workstation before uploading to the server.

If the nodes trust the server, it would be a major security risk, as the whole network would rely on the security of the Chef Server. And all my segmentation in the network would be useless.

But if i can sign the the payloads on the workstation, it would be really great. But i am unable to find any information on this.

Maybe someone can help me?

2

Every node has its own key. Which can be rotated. One can use Policyfiles which are stateful.

3

But this does not help if the Chef Server is compromised. An intruder will then be able to change the recipes at will.

  1. A node must be bootstrapped with a list of public keys to trust.
  2. All recipes, templates and whatnot must be signed on the workstation (maybe upon upload).
  3. Node validates all changes before apply.

It is very peculiar that this is not the first thing implemented.

This should not be a very hard thing to implement. The company i work for might be interested in opening a bounty to get this feature.

Everything else about Chef is very good, and very suitable for our need.

4

Check out policyfiles that may be what your looking for. Id reach out to Chef directly if you have any security concerns. As far as validation goes that’s what test kitchen/inspec is for.

A node is bootstrapped with an org key from the chef server. This of course can be rotated. Once the node is bootstrapped it receives a key that is used from that point on. Of course it also can be rotated.

Policyfiles when pushed to the chef server create a revision_id for the policyfile and each cookbook is created an identifier. This is a hash on the file.

5

Make no mistake, if the Chef Server is compromised, your security is dead in the water. The same is true of every system that relies on authoritative system management. One technique I've used for certain classes of tracking is to back up all of the Chef Server configurations, to a source controlled repository, to allow tracking of specific changes. It's burdned by the churn in the "node" configurations, but it's very useful for tracking unexpected changes, or reverting disastrous configuration changes.

A much more common problem is when a cookbook is updated that is not tested in all environments. That is one of the big reasons I published the hooks over at https://github.com/nkadel/nkadel-chef-local-wrapper, to use a pure git repository based, local chef implementation. But the provenance of a single git server is, well, much easier to ensure than that of a Chef server. So it's an approach you might want to examine if you don't feel you can have high confidence in a Chef server's invulnerability to abuse or compromise.