mirror of
https://github.com/edgelesssys/constellation.git
synced 2026-01-14 06:01:01 -05:00
Add explanation of clusterID
This commit is contained in:
parent
dd72ec6600
commit
0ea55e0b0f
1 changed files with 4 additions and 1 deletions
|
|
@ -59,7 +59,10 @@ The CLI automatically selects one of the nodes as *first node*. The CLI automati
|
|||
2. The CLI generates the [master secret](../architecture/keys.md#master-secret) of the to-be-created cluster and sends it to the first node.
|
||||
3. The first node generates a [kubeconfig file](https://www.redhat.com/sysadmin/kubeconfig) and sends it to the CLI. The kubeconfig file contains Kubernetes credentials for the CLI and the Kubernetes cluster's public key, among others.
|
||||
|
||||
After this, the aTLS connection is closed and the node is marked as "initialized" by extending. This marker is irrevocably reflected in the node's remote attestation. This mechanism prevents a node from (accidentally or maliciously) joining different clusters.
|
||||
After this, the aTLS connection is closed and the Bootstrapper marks the node irrevocably as "initialized". This mechanism prevents a node from accidentally or maliciously joining different clusters. On all supported CVM platforms this is currently implemented by *extending* one of the respective TPM's registers with the unique ID of the cluster (`clusterID`). More information can be found in the [Constellation documentation].
|
||||
|
||||
For [launch digest-based attestation](#remote-attestation-of-nodes) on future CVM platforms, an alternative would be to extend `clusterID` to the so called RTMR registers of Intel TDX. TDX provides four RTMRs, which are automatically included in the `auxiliary data` part of a remote-attestation statement. For AMD SEV-SNP, a different solution exists.
|
||||
|
||||
|
||||
## Kubernetes bootstrapping on the first node
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue