Pass over components

This commit is contained in:
Felix Schuster 2022-12-23 09:56:41 +01:00
parent 5fc94b7c62
commit d7051ac6b4

View File

@ -1,6 +1,8 @@
# Components
(**FS: Overall, good**)
(**FS: Overall, good. Should be renamed to something like "Kubernetes Components"**)
Constellation takes care of bootstrapping and initializing a Confidential Kubernetes cluster. (**FS: weird**)
During the lifetime of the cluster, it handles day 2 operations such as key management, remote attestation, and updates. (**FS: features**)
@ -11,15 +13,15 @@ These features are provided by several components:
* The [VerificationService](components.md#verificationservice) provides remote attestation functionality
* The [Key Management Service (KMS)](components.md#kms) manages Constellation-internal keys
The relations between components are shown in the following diagram: (**FS: this doesn't look quite right. Talk to Moritz. Maybe remove.**)
The relations between components are shown in the following diagram: (**FS: this is only the first node**)
```mermaid
flowchart LR
subgraph admin [Admin's machine]
A[Constellation CLI]
end
subgraph img [Constellation OS image]
B[Constellation OS]
subgraph img [Node / Confidential VM]
B[Constellation OS image]
C[Bootstrapper]
end
subgraph Kubernetes
@ -27,7 +29,7 @@ flowchart LR
E[KMS]
F[VerificationService]
end
A -- deploys -->
A -- boots -->
B -- starts --> C
C -- deploys --> D
C -- deploys --> E
@ -39,8 +41,8 @@ flowchart LR
**FS: some context missing**
The *Bootstrapper* is the first component launched after booting a Constellation node image.
It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions. (**FS: where are they configured?**)
The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) (**FS: this is not a good link**) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions. (**FS: where are they configured?**)
The *Bootstrapper* tries to find an existing cluster (**FS: how?**) and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
## JoinService
@ -73,4 +75,4 @@ Read more about the hardware-based [attestation feature](attestation.md) of Cons
The *KMS* runs as DaemonSet on each control-plane node.
It implements the key management for the [storage encryption keys](keys.md#storage-encryption) in Constellation. These keys are used for the [state disk](images.md#state-disk) of each node and the [transparently encrypted storage](encrypted-storage.md) for Kubernetes.
Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) or [user-managed](keys.md#user-managed-key-management) mode is used, the *KMS* holds the key encryption key (KEK) directly or calls an external service for key derivation respectively.
Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) (**FS: this is an odd name.**)or [user-managed](keys.md#user-managed-key-management) mode is used, the *KMS* holds the key encryption key (KEK) directly or calls an external service for key derivation respectively.