Enrollment process?

[sorenisanerd]

What should the enrollment process look like?

How would the client authenticate itself to a supposed "enrollment service"? I.e. when an enrollment request comes in, how do we know it's legit?

Maybe it's fundamentally just a CSR that gets sent to the enrollment service. Organization policy can determine what kind and level of scrutiny to apply on the server side. Nodes can poll for a signed certificate.

How would it identify itself? What comprises its identity? machine-id?

Once enrolled, sd-sysupdate can pull the node's confext which can include hostname, network config, etc.

[sorenisanerd]

As it turns out, there are several enrollments going on. First, there is Secure Boot enrollment. This involves, at a minimum, nodes detecting that they're in Setup mode and requesting a (presumably unique[1]) PK[2] from a central service. The service generates a signed PK cert, returns it, and the node installs it. The private key is generated centrally, kept, and never revealed.

Since the node never sees the private key, it can't be used as a credential which is why at least one more enrollment needs to take place. At the end of this enrollment, the node should have a unique identity, and be able to somehow authenticate itself to a central service. The identity is not sensitive or secret, so it may be saved in /boot or could be derived from e.g. a system serial number.

The credential itself should, of course, be protected. systemd-creds handily provides an interface for encrypting/decrypting credentials using a host key, a TPM, or both. The host key lives in /var/lib so cannot be accessed until after local storage is mounted. If we protect the node credentials using this mechanism, we can't use them from the initrd. I think that's ok, but it deserved being pointed out.

There's a bit of a chicken-egg situation here. When setting up encryption for local storage, we want to save enroll a recovery key that gets saved centrally. We want to associate recovery keys with the new node, but at this point in the provisioning process (i.e. when setting up encrypted storage), we have not yet established an identity or trust relationship.

If systemd-repart --dry-run=yes suggests there are changes to be made, we should generate a key file in /run somewhere, proceed with systemd-repart. After the initrd->OS transition, we can check if the node is enrolled. If not, we perform the enrollment. At this point, we can upload the recovery keys, and delete them locally.

[1]: It's possible a unique key per system is overkill. One per hardware profile might suffice.
[2]: PK = Platform Key. See James Bottomley's write-up of the different UEFI keys for more info.
[3]: KEK = Key Exchange Key. See also [2].

[sorenisanerd]

Enrollment into e.g. Vault and Consul can leverage the existing trust relationship established through the second (non-Secure Boot) enrollment.