I see that Chef Infra Client 17, just released, no longer includes the "knife" command. Unfortunately for my company, our system management processes and tooling have grown up over the past 5 years around the assumption that "knife" would be present on every Chef-managed node. I'm concerned that it is going to be a lot of effort for my company to adjust processes, tooling, and culture to no longer having access to "knife" on each node. Does anyone else have similar concerns?
One example of an issue we will face: We have multiple Chef Infra Servers in multiple data centers. Today operations folks do not need to know which server to contact to update a node's run-list, because they make the change from the node itself (or automation makes the change from the node itself). If we move to a model where all run-list changes are made from a Chef Workstation, we're going to have to figure out an efficient way to map a node name to the Chef Infra Server that manages it.
For historical packaging reasons the Chef Infra Client packages have always shipped with the knife command for managing your Chef Infra nodes. With Chef Workstation there’s no benefit to shipping knife in the Chef Infra Client package and there are several downsides. Shipping management tooling within the client is seen as a security risk to many and increases the side of the Chef Infra Client codebase by adding a large number of management dependencies. With Chef Infra Client 17 we’ve split knife into its own Ruby Gem, which will continue to ship in Chef Workstation, but will no longer come bundled with Chef Infra Client. We hope you’ll enjoy the new faster and smaller Chef Infra Client while continuing to use knife in Chef Workstation uninterrupted.
I want to provide a little more detail on use cases my company has for using "knife" on client nodes.
Our operations personnel routinely log into servers directly as an administrative user other than "root". Among the Chef-related tasks they perform directly on those boxes are the following. Most of these tasks are done using a custom wrapper script to the local "knife" command that among other things prevents the operator from removing the "base" cookbook from the first position on the run-list. It also provides sudo access to chef-client as needed. The engineer need not know which of the company's multiple Chef Infra Servers the node is registered with, as the knife wrapper script authenticates to the correct Chef Infra Server via the node's local client.rb config file.
Update a node's run-list and force an ad-hoc Chef run to verify it works
View a node's run-list
Execute a one-time run of a recipe on a node
Apply and remove Chef tags from a node
View a node's environment as stored on Chef Infra Server
View/Delete a node's current attributes stored on Chef Infra Server
You should be able to install the knife gem from within your chef run itself using the chef_gem resource. The one caveat is that the actual knife command won’t be available in your PATH. You’ll need to reference the bin using absolute path or symlink to somewhere in your PATH.
We do everything that newatlantis mentions above without ever running knife commands on the nodes - which is as stated very insecure.
We have an HA Chef environment with 3 backend Postgres servers. With this setup all of the Chef configuration and node information is saved to the database instead of on the filesystem of the Chef Infra server itself.
Then it doesn't matter which Infra Server the node registered with and you can make changes to any node from your personal workstation using knife instead of doing it from the node itself.
It has long been a best practice not to give people knife access to chef-server or nodes really. Most things can be managed in another more secure manner. Managing a run-list should be done via a policy assignment and not a knife command. If your pipeline is managing such things, then it's a matter of editing a policy and allowing your pipeline to change the run-list in the appropriate place. if you aren't using policyfile then I would suggest that as a first step. As far as your bullet points, some of that if not all will be available in automate once the chef-manage style interface has been implemented.
Thank you, @jasonwbarnett. I think that's what we'll need to do. Our systems management tools and processes are too deeply entrenched in requiring "knife" on each Chef-managed node for it to be practical for us to remove that dependency in time for the required update to Chef 17 (by April 30, 2022).
Unfortunately, I cannot seem to install the latest "knife" gem on a Windows 2012R2 Chef 17 (Ruby 3.0) node -- I get an error compiling the native binaries for the extensions to some dependency(ies). I'm trying to get Chef Support's help with that. (I can install the same "knife" gem fine on Chef 16 (Ruby 2.7) nodes.)
We use knife from Jenkins nodes in CI/CD. These jobs do things such as re-uploading encrypted data-bags from Jenkins secrets, uploading Chef definitions, cookbook uploads from cookbook, CI/CD, etc.
Obviously, the Jenkins nodes themselves are maintained by Chef, including our workstation nodes. But after upgrade, suddenly the chef client version enforcement is also wiping workstation installed via rpm from Chef..! We are using chef_client_updater.
Even before this recent change to remove knife from Chef Client, we have installed and maintained Chef Workstation along side Chef Client on our CI/CD nodes.
What we have done historically to ensure updates didn’t break our PATH, we fully path our knife commands in our pipelines to ensure it used the right knife command.
It would seem with this recent change to Chef Client that should no longer be necessary but it seemed like a good point to share.