Add design for the boot phases

[alicefr]

Design proposal for the booting process

[travier]

This sounds great! Thanks

[travier]

Does that mean that we will need two IP/URL for the trustee servers (KBS1 & 2)? How does the node know to go the the second one after the attestation on first boot?

We will also need to figure out how we can tie a connection to a node ID for the second boot (that's not a new problem, we already had this).

[alicefr]

Does that mean that we will need two IP/URL for the trustee servers (KBS1 & 2)? H

I think we can do it in 2 ways, either with 2 IPs and KBS services or the KBS can interpret the constant path for the firstboot secret and trigger the phase for the key generation. However, for the latter, it isn't implemented by trustee so we will need to add this on top of the kbs offered by trustee.

how does the node know to go the the second one after the attestation on first boot?

Since the plan is to implement the clevis pin we could specify the 2 URL as 2 different parameters for the pin. We will register the second URL for the standard KBS to contact for second boot.

We will also need to figure out how we can tie a connection to a node ID for the second boot (that's not a new problem, we already had this).

This needs to be figure out at the end of the first phase when the LUKs key needs to be registered in KBS1 and be matched with a machine object. The IP of the HTTP request is always a valid option, as it was already discussed in the past. The only issue is that the address in the Machine object is optional, and depends on the provider. At least for KubeVirt, Azure and GCP, they set the field. For providers which don't support this, the operator will need to look for this information somewhere else.

As far as it regards the provider ID, this is a mandatory field in the Machine object but it isn't necessarily present inside the node. So, my guess is that we will need to rely on the IP of the connection and then somehow match it with what is available in the environment.

[alicefr]

As far as it regards providers which don't set the IP in the Machine, we would need to use their API. In any case, the fallback plan to the Machine object was to use each provider APIs, so this won't be different then the case without the Machine object. It will be nice to check if each provider can somehow advertise if they expose the IP address without the need of checking into the code of each provider. I will ask the cluster api community if there is such an option.

The list of capi providers is quite large, but we are interested only on those who support confidential computing.

[alicefr]

/hold wait until we clarify the node identifier, this might change the design

[uril]

This registration service is only needed if we can not get the node id from OpenShift

[travier]

Alternative if we can figure out how to tie a ressource request to the TPM AK from the attestation request.

[alicefr]

/cc @Jakob-Naucke

[alicefr]

@travier @Jakob-Naucke I'd like to merge this since we have already more or less implemented.

initdata format incompatibilities

[travier]

Some nits but LGTM.

[alicefr]

@Jakob-Naucke @travier PTAL

[travier]

I pushed a few nits. LGTM.