Securing the Chef server & clients

Keys, RBAC, and the pull model’s risks.

Advanced14 min · lesson 12 of 12

Chef’s pull model concentrates trust in two places: the Chef server (which holds all cookbooks, data bags, and node definitions) and the client keys (which authenticate nodes and users). Securing Chef means hardening both. On the server, use its RBAC to scope what each user and node can read and change — not everyone should upload cookbooks or read every data bag — and protect it like the critical service it is, since it dictates what runs as root fleet-wide.

terminal

# scope access with server RBAC, and rotate client keys periodically
$ knife group create cookbook-authors
$ knife acl add group cookbook-authors cookbooks web update
$ knife client reregister web1 > /tmp/web1.pem   # rotate a node’s key

Node-side and secret hygiene

On nodes, chef-client runs as root, so protect its keys and the encrypted-data-bag secret with tight file permissions, mark sensitive resources so secrets stay out of logs, and keep the run interval and error handling sane so a bad converge does not loop destructively. Prefer an external secret manager or Chef Vault over a shared data-bag key, and keep cookbooks in reviewed version control with testing as a gate.

client.rb

chef_server_url  "https://chef.acme.internal/organizations/acme"
ssl_verify_mode  :verify_peer     # never :verify_none in production
file_cache_path  "/var/chef/cache"
# protect /etc/chef/client.pem and the data-bag secret with 0600 root-only

ssl_verify_mode :verify_none is a MITM invitation

Disabling TLS verification so a node will talk to the server tells chef-client to trust any endpoint answering as the Chef server — and that endpoint then dictates what runs as root on the node. Keep :verify_peer, fix the certificate trust properly, and treat any suggestion to set :verify_none like Ansible’s host_key_checking=False: a security hole, not a workaround.

Policyfiles & environmentsFinish · self-test