Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2025-07-20 05:51:46 -04:00
Code Issues Projects Releases Packages Wiki Activity

WIP

Browse source
This commit is contained in:
Felix Schuster 2022-10-14 09:26:56 +02:00
parent 8f3be2b7f9
commit 1290aad6d6
3 changed files with 18 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/docs/architecture/attestation.md
View file

@ -4,7 +4,7 @@ This page explains Constellation's attestation process and highlights the corner
## Terms ## Terms
The following lists terms and concepts that help to understand the attestation concept of Constellation. The following lists important terms and concepts.
### Trusted Platform Module (TPM) ### Trusted Platform Module (TPM)
@ -18,22 +18,20 @@ A runtime measurement is a cryptographic hash of the memory pages of a so called
### Platform Configuration Register (PCR) ### Platform Configuration Register (PCR)
A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. PCRs cannot be written, they can only be "extended".
To store a new value in a PCR, the existing value is extended with a new value as follows: When a PCR is extended with a value, the PCR's new value `PCR[n]` is calculated as follows:
``` ```
PCR[N] = HASHalg( PCR[N] || ArgumentOfExtend ) PCR[n] = Hash( PCR[n-1] || value )
``` ```
The PCRs are typically used to store runtime measurements. Thus, the value of a PCR always depends on all previous values. PCRs are typically used to store runtime measurements. In that case, the value of a PCR uniquely reflects the sequence of runtime measurements it was extended with.
The new value of a PCR is always an extension of the existing value.
Thus, storing the measurements of multiple components into the same PCR irreversibly links them together.
### Measured boot ### Measured boot
Measured boot builds on the concept of chained runtime measurements. Measured boot builds on the concept of chained runtime measurements.
Each component in the boot chain loads and measures the next component into the PCR before executing it. Each component in the boot chain loads and measures the next component and extends the measurements into the PCR.
By comparing the resulting PCR values against trusted reference values, the integrity of the entire boot chain and thereby the running system can be ensured. By comparing the resulting PCR values against reference values, the integrity of the entire boot chain can be ensured.
### Remote attestation (RA) ### Remote attestation (RA)

15
docs/docs/architecture/components.md
View file

@ -1,7 +1,9 @@
# Components # Components
Constellation takes care of bootstrapping and initializing a Confidential Kubernetes cluster. (**FS: Overall, good**)
During the lifetime of the cluster, it handles day 2 operations such as key management, remote attestation, and updates.
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**)
These features are provided by several components: These features are provided by several components:
* The [Bootstrapper](components.md#bootstrapper) initializes a Constellation node and bootstraps the cluster * The [Bootstrapper](components.md#bootstrapper) initializes a Constellation node and bootstraps the cluster
@ -9,7 +11,7 @@ These features are provided by several components:
* The [VerificationService](components.md#verificationservice) provides remote attestation functionality * The [VerificationService](components.md#verificationservice) provides remote attestation functionality
* The [Key Management Service (KMS)](components.md#kms) manages Constellation-internal keys * The [Key Management Service (KMS)](components.md#kms) manages Constellation-internal keys
The relations between components are shown in the following diagram: The relations between components are shown in the following diagram: (**FS: this doesn't look quite right. Talk to Moritz. Maybe remove.**)
```mermaid ```mermaid
flowchart LR flowchart LR
@ -34,18 +36,19 @@ flowchart LR
## Bootstrapper ## Bootstrapper
**FS: some context missing**
The *Bootstrapper* is the first component launched after booting a Constellation node image. 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. 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. 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. The *Bootstrapper* tries to find an existing cluster 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. Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
## JoinService ## JoinService
The *JoinService* runs as [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) on each control-plane node. The *JoinService* runs as [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) on each control-plane node (**FS: should we define control-plane somewhere?**).
New nodes (at cluster start, or later through autoscaling) send a request to the service over [attested TLS (aTLS)](attestation.md#attested-tls-atls). New nodes (at cluster start, or later through autoscaling) send a request to the service over [attested TLS (aTLS)](attestation.md#attested-tls-atls).
The *JoinService* verifies the new node's certificate and attestation statement. The *JoinService* verifies the new node's certificate and attestation statement.
If attestation is successful, the new node is supplied with an encryption key from the [*KMS*](components.md#kms) for its state disk, and a Kubernetes bootstrap token. If attestation is successful, the new node is supplied with an encryption key from the [*KMS*](components.md#kms) (**FS: we should make clear that this is our own KMS**) for its state disk and a Kubernetes bootstrap token.
```mermaid ```mermaid

2
docs/docs/architecture/overview.md
View file

@ -1,11 +1,13 @@
# Overview # Overview
**FS: OK'ish but not great. Do we need this section at all? Probably not.**
Constellation is a cloud-based confidential orchestration platform. Constellation is a cloud-based confidential orchestration platform.
The foundation of Constellation is Kubernetes and therefore shares the same technology stack and architecture principles. The foundation of Constellation is Kubernetes and therefore shares the same technology stack and architecture principles.
To learn more about Constellation and Kubernetes, see [product overview](../overview/product.md). To learn more about Constellation and Kubernetes, see [product overview](../overview/product.md).
## About orchestration and updates ## About orchestration and updates
**FS: this is more like How-To**
As a cluster administrator, you can use the [Constellation CLI](orchestration.md) to install and deploy a cluster. As a cluster administrator, you can use the [Constellation CLI](orchestration.md) to install and deploy a cluster.
Updates are provided in accordance with the [support policy](versions.md). Updates are provided in accordance with the [support policy](versions.md).