A chef-client is an agent that runs locally on every node that is registered with the Chef Server. When a chef-client is run, it will perform all of the steps that are required to bring the node into the expected state, including:
When a node runs chef-client for the first time, it generally does not yet have an API client identity, and so it cannot make authenticated requests to the server. This is where the validation client (named chef-validator) comes in. When the chef-client runs, it checks if it has a client key. If the client key does not exist, it then attempts to borrow the validation client’s identity to register itself with the Chef Server. In order to register with the Chef Server, the validation client’s private key needs to be copied to the host and placed in /etc/chef/validation.pem.
Once the chef-client has registered itself with the Chef Server, it no longer uses the validation client for anything. It is recommended that you delete the validation client’s private key from the host after the host has registered or use the delete_validation recipe that can be found in the chef-client cookbook (http://community.opscode.com/cookbooks/chef-client).
An SSL certificate is used between the chef-client and the Chef Server to ensure that each node has access to the right data.
Chef uses signed header authentication to validate communications between the Chef Server and any node that is being managed by the Chef Server. An API client manages each authentication request. A public and private key pair is used for the authentication itself. The public key is stored in the database on the Chef Server. The private key is stored locally on each node and is kept separate from node data (typically in the /etc/chef/client.pem directory). Each request to the Chef Server by a node must include a request signature in the HTTP headers. This signature is computed from a hash of request content and is encrypted using the private key.
