Support discovering node name from RKM and connecting to AD domain via certificates for PXE Boot

[hach-que]

Rough outline for this is:

• Need a web service that runs on Linux nodes inside RKM
  • This service always runs on the Kubernetes primary node.
  • Discovered via UDP broadcast, using the same mechanism that RKM nodes use to discover the controller on first run.
  • This service reads a custom resource like "PxeBootNode" or something like that.
    • This resource contains the desired computer name and generation number (the latter can be increased to force a reprovision even if Windows is already installed).
  • This service reads a custom resource like "PxeBootConfiguration" or something like that.
    • This resource contains configuration as to whether AD join should be enabled (including a reference to the certificate in Kubernetes that should be trusted for AD certificate provisioning).
    • This service automatically creates X509 certificates signed with the main CA secret in response to PXE Boot node requests, based on the MAC address or computer serial number.
    • Maybe we try to have PXE Boot nodes store a certificate or sign data using the TPM, that way we can prove that the node is who it says it is when making the request to the service?
    • This configuration needs to also specify what AD group machines should be joined to by default.
  • We might need a "PxeBootNodeRequest" resource, which can contain the public fingerprint of a new node that is yet to be approved. That way, we don't have to type MAC address / serial number / TPM public key from the computer showing it in WinPE.
• Need a service that can run on an AD controller that exposes a HTTP endpoint. That endpoint accepts requests signed by client certificates, and uses djoin to generate an offline join file. This file is then sent to the PXE Boot node in WinPE which uses it to apply the join to the VHDX before first boot. In this case we don't set up a local Administrator password on the machine.

[hach-que]

UET can now access the TPM, and we can use the TPM EK<->AIK to prove that the machine being provisioned is the same machine across reprovisions, even if the disk is completely wiped.

The process needs to look something like this:

• The AD join service creates an X509 certificate to act as a root certificate (without having to store ephemeral certificates).
• On the node, EK is accessed and AIK is loaded.
• EK public key PEM needs to be allowlisted by the AD join service (using the PxeBootNode / PxeBootNodeRequest process above).
  • PxeBootNode / PxeBootNodeRequest needs to require a node name be set when approved, or the AD join service will ignore it.
• If the public key PEM is approved, the AD join service creates a ephemeral certificate signed by the root certificate, with the subject name encoding the node's name and an expiry no later than a few minutes in the future.
  • It generates a secret, which it both uses to encrypt the ephemeral certificate (including private key) and passes to CreateActivationCredentials.
  • It then passes the encrypted secret, encrypted ephemeral certificate and challenge text to the node.
  • The node then uses ActivateCredential with the encrypted secret to retrieve the original secret, and uses the original secret to decrypt the ephemeral certificate.
  • The node signs the challenge text with the decrypted ephemeral certificate, and passes the signed challenge back to the AD join service along with the ephemeral certificate (public side only).
  • The AD join service then verifies that the provided ephemeral certificate is signed by the root certificate, and that the signed challenge is validly signed by the certificate. It then uses djoin to create the offline join file and returns the file encrypted with the ephemeral certificate's public key.
  • The node decrypts the offline join file and uses it to join the offline image to AD.