provisioner/chef: Add ability to skip chef registration

[samdunne]

This change allows a user to skip the bootstrap stage for a machine.

A machine might self register on boot for use outside of terraform. In this case we don't want to recreate the client but just skip the registration as this is done already.

[svanharmelen]

Thanks for the PR @samdunne LGTM!

[apparentlymart]

I wonder if this can be used in conjunction with the chef_node resource to finally address the issue of how to have Terraform de-register a node after it's destroyed. Does that seem plausible as-is, or would we need to add some additional stuff to that resource to make that work smoothly?

People have asked about this a lot, so if it's now possible (or even if it's super close!) it'd be great to be able to talk about this a bit in the docs for the Chef provisioner!

[svanharmelen]

@apparentlymart I don't think the chef_node resource can help here, as that is only for creating and configuring a node object. But you still need a client object in your Chef server in order for the new server to be able to talk to the Chef server.

It's not much work to add a resource which could manage client objects, but that would mean the private key of each of your new servers would be registered in the Terraform state. And that seems like a very big security issue to me... Of course you could say then lets not record the private key, but you need that key to be present on your new servers for them to be able to talk with the Chef server.

Next to that if you create the node object using a different client key then the one that was created for the new server (your personal key would be very likely), the rights on the node object are not set correctly so we should also need to add some logic to fix/correct that.

Having that said, I think we already a solution in place since PR #8577 added a new option to recreate_client. Which effectively solves this issue by allowing you to recreate an existing client.

So it will still not properly cleanup client objects when you delete servers, but it will take away the pain that you have to manually cleanup the client object before being able to (re)create a server again. Which I think was (for the majority at least) the big burden in using the chef provisioner.

[apparentlymart]

Oh right... I had forgotten about the "client" object... I'm pretty rusty on Chef since these days I'm only using chef-solo^[1]. Now that you make me think about the client private keys, it makes me think instead about a secret backend for Vault that registers a client and returns its key, which could be securely passed to the server using response wrapping... but that's far outside the scope of what we're discussing here, so I'll take that away and think about it some more. 😀

[1] Funnily enough, our abandoning of Chef server was largely because we had no way to deregister servers once they are destroyed, and we were accumulating hundreds of stale node and client objects in the Chef server due to the fact that most of our servers only live for one or two days before they get replaced by a fresh one with a new image.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.