Starting with the Chef 12.2.0 Client there is no longer any need to use the validation key to provision new chef nodes with knife. Furthermore, all that needs to be done to take advantage of this feature is to delete your validation keys and optionally remove the validator configuration from your knife.rb
file.
Instead of shipping a validation key up to the newly provisioned node and having the node use the validation key to authorize itself to provision a new client and node, the knife bootstrap command will use the user’s key to create a client key for the node, use the client key to create a node object, and then ship the client key up to the node.
### Configuration Details
Starting with Chef 12.2.0 existing Users will begin seeing a new banner on new knife bootstraps:
[shell]
Doing old-style registration with the validation key at /home/lamont/.chef/myorg-validator.pem…
Delete your validation key in order to use your user credentials instead
[/shell]
In order to use the new behavior it is as simple as deleting the validator key:
[shell]
rm -f /home/lamont/.chef/myorg-validator.pem
[/shell]
The existing `validation_client_name` and `validation_key` parameters in the knife.rb file can also be deleted. Note that the default value of the `validation_key` is “/etc/chef/validation.pem” and if that file happens to exist on the workstation or server that it will attempt to be used after
removing the `validation_key` setting. That file should either also be deleted, or else the `validation_key` should be set to something like “/nonexist” to disable it.
### Provisioning Details
The new output of knife bootstrap when not using a validation key will look similar to:
[shell]
desktop% knife bootstrap 10.1.1.1 -N foo01.acme.org \
-E dev -r ‘role[base] -j ‘{ "foo": "bar" }’ \
–ssh-user vagrant –sudo
Node foo01.acme.org exists, overwrite it? (Y/N)
Client foo01.acme.org exists, overwrite it? (Y/N)
Creating new client for foo01.acme.org
Creating new node for foo01.acme.org
Connecting to 10.1.1.1
10.1.1.1 Starting first Chef Client run…
[….etc…]
[/shell]
What you can see here is that if the node and client already exist that knife bootstrap will prompt to overwrite them. The ‘-y’ command line flag can be used to skip the prompts and answer ‘y’ to both questions. The new client is created first and the new node is then created with the client key.
Behind the scenes the ‘-r’ and ‘-E’ and ‘-j’ flags to knife bootstrap are already applied to the new node which gets created — so the object in the database will have its `run_list`, `environment` and initial ‘normal’ json attributes saved. This avoids the edge condition where for some reason if the initial chef-client run fails the node is never saved and it ‘forgets’ its own `run_list` and `environment`. Since the node is saved with that correct data before provisioning starts on the host, the `run_list` will still be correct even if the initial chef-client run fails for some reason.
### Summary
The validatorless bootstrap changes to Chef 12.2.0 achieve a few key things:
* No more need for the validation key (fewer things, reduced fussiness)
* Ability to eliminate shared access (and ultimately have better auditing around provisioning actions)
* Eliminating the first-run failure edge conditions where a node forgets its `run_list`, `environment` or attributes
* Gracefully handling the situation where an old Client key or Node object exist in the database
