Add support for AuthN/AuthZ to Hegel/Tink Server workflows

[micahhausler]

Right now, Tinkerbell effectively trusts all MAC addresses coming in as the hardware it claims to be before supplying an image for PXE booting with tink-worker, and tink-worker eventually runs a workflow assigned to that machine's MAC address. The machine (via a workflow step) may call hegel and request additional machine information like boot scripts with secret information in them.

The PXE booted image hopefully won't contain anything secret, but the workflow or hegel metadata responses could contain boot-time secrets.

In order to prevent a MAC address spoof for a compromised machine from gaining anything other than a PXE booted image, it seems like integration for AuthN/Z to Hegel and possibly workflows could help to mitigate this threat.

TPMs might be a great solution here for machines that support it. In addition to the MAC/IP tuple stored in the hardware data, if a TPM device's public key was pre-registered or trusted on first use, sensitive data used in machine bootstrapping would be more resistant to a bad actor.

Current Behaviour

• A compromised machine that can spoof MAC addresses can request workflows and hegel metadata of other machines in the same L2 broadcast domain.
• In a scenario such as Kubernetes Cluster API (CAPI), Tinkerbell may issue X509 CA data over Hegel. Should a compromised Kubernetes worker spoof a Kubernetes Control Plane MAC address and replay the provisioning workflow, they'd effectively have control of the Kubernetes cluster.

Expected Behaviour

• A compromised host that can spoof MAC addresses cannot steal configuration data of legitimate hardware.

Possible Solution

Add TPM attestation to calls to hegel or tink-server workflows

I'm mainly opening this as a tracking ticket, not a formal proposal

Relates to #134

[tstromberg]

For what it's worth, I feel like the core and correct part of this proposal is the signed requests to Hegel. All secrets should be communicated via that path. I'm a bit iffy on the tink-server workflows aspect, as for some provisioning setups -- the certificates may only be available to the node after the initial installation.

Regardless, adding the support and documenting how to implement this in production will take some effort. Help wanted!

[tstromberg]

Discussed at triage: in particular, securing the communication between the tink-worker and hegel seems reasonable. It's difficult to ensure a fully trusted environment until the operating system is installed, so doing so beforehand may not be feasible.

Help wanted!

[chrisdoherty4]

This has been documented as a roadmap item. Please refer to that issue for additional information.

tinkerbell/roadmap#1