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

restructured archticeture docs

Browse Source
This commit is contained in:
david-crypto 2024-10-23 12:52:40 +02:00
parent bf2d497c8c
commit 031c0cc9d6
22 changed files with 651 additions and 336 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
dev-docs/package-lock.json generated Normal file
View File

@ -0,0 +1,6 @@
{
"name": "dev-docs",
"lockfileVersion": 3,
"requires": true,
"packages": {}
}

BIN
docs/docs/_media/chain-of-trust.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
docs/docs/architecture/chain-of-trust.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

1
docs/docs/architecture/components/cli.md Normal file
View File

@ -0,0 +1 @@
# CLI

1
docs/docs/architecture/components/keys.md Normal file
View File

@ -0,0 +1 @@
# Keys and cryptographic primitives

1
docs/docs/architecture/components/microservices.md Normal file
View File

@ -0,0 +1 @@
# Microservices

1
docs/docs/architecture/components/node-images.md Normal file
View File

@ -0,0 +1 @@
# Node images

101
docs/docs/architecture/attestation.md → docs/docs/architecture/old/attestation.md
View File

@ -1,5 +1,7 @@
# Attestation
[comment]: hello
[comment]: hello
This page explains Constellation's attestation process and highlights the cornerstones of its trust model.
## Terms
@ -9,12 +11,12 @@ The following lists terms and concepts that help to understand the attestation c
### Trusted Platform Module (TPM)
A TPM chip is a dedicated tamper-resistant crypto-processor.
It can securely store artifacts such as passwords, certificates, encryption keys, or *runtime measurements* (more on this below).
When a TPM is implemented in software, it's typically called a *virtual* TPM (vTPM).
It can securely store artifacts such as passwords, certificates, encryption keys, or _runtime measurements_ (more on this below).
When a TPM is implemented in software, it's typically called a _virtual_ TPM (vTPM).
### Runtime measurement
A runtime measurement is a cryptographic hash of the memory pages of a so called *runtime component*. Runtime components of interest typically include a system's bootloader or OS kernel.
A runtime measurement is a cryptographic hash of the memory pages of a so called _runtime component_. Runtime components of interest typically include a system's bootloader or OS kernel.
### Platform Configuration Register (PCR)
@ -66,9 +68,9 @@ The protocol can be used by clients to verify a server certificate, by a server
The challenge for Constellation is to lift a CVM's attestation statement to the Kubernetes software layer and make it end-to-end verifiable.
From there, Constellation needs to expand the attestation from a single CVM to the entire cluster.
The [*JoinService*](microservices.md#joinservice) and [*VerificationService*](microservices.md#verificationservice) are where all runs together.
Internally, the *JoinService* uses remote attestation to securely join CVM nodes to the cluster.
Externally, the *VerificationService* provides an attestation statement for the cluster's CVMs and configuration.
The [_JoinService_](microservices.md#joinservice) and [_VerificationService_](microservices.md#verificationservice) are where all runs together.
Internally, the _JoinService_ uses remote attestation to securely join CVM nodes to the cluster.
Externally, the _VerificationService_ provides an attestation statement for the cluster's CVMs and configuration.
The following explains the details of both steps.
@ -80,23 +82,23 @@ The solution is a verifiable boot chain and an integrity-protected runtime envir
Constellation uses measured boot within CVMs, measuring each component in the boot process before executing it.
Outside of CC, this is usually implemented via TPMs.
CVM technologies differ in how they implement runtime measurements, but the general concepts are similar to those of a TPM.
For simplicity, TPM terminology like *PCR* is used in the following.
For simplicity, TPM terminology like _PCR_ is used in the following.
When a Constellation node image boots inside a CVM, measured boot is used for all stages and components of the boot chain.
This process goes up to the root filesystem.
The root filesystem is mounted read-only with integrity protection.
For the details on the image and boot stages see the [image architecture](../architecture/images.md) documentation.
For the details on the image and boot stages see the [image architecture](images.md) documentation.
Any changes to the image will inevitably also change the corresponding PCR values.
To create a node attestation statement, the Constellation image obtains a CVM attestation statement from the hardware.
This includes the runtime measurements and thereby binds the measured boot results to the CVM hardware measurement.
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../workflows/create.md) that irrevocably marks the node as initialized.
The measurement is created using the [*clusterID*](../architecture/keys.md#cluster-identity), tying all future attestation statements to this ID.
In addition to the image measurements, Constellation extends a PCR during the [initialization phase](../../workflows/create.md) that irrevocably marks the node as initialized.
The measurement is created using the [_clusterID_](keys.md#cluster-identity), tying all future attestation statements to this ID.
Thereby, an attestation statement is unique for every cluster and a node can be identified unambiguously as being initialized.
To verify an attestation, the hardware's signature and a statement are verified first to establish trust in the contained runtime measurements.
If successful, the measurements are verified against the trusted values of the particular Constellation release version.
Finally, the measurement of the *clusterID* can be compared by calculating it with the [master secret](keys.md#master-secret).
Finally, the measurement of the _clusterID_ can be compared by calculating it with the [master secret](keys.md#master-secret).
### Runtime measurements
@ -106,16 +108,16 @@ The following gives a detailed description of the available measurements in the
The runtime measurements consist of two types of values:
* **Measurements produced by the cloud infrastructure and firmware of the CVM**:
These are measurements of closed-source firmware and other values controlled by the cloud provider.
While not being reproducible for the user, some of them can be compared against previously observed values.
Others may change frequently and aren't suitable for verification.
The [signed image measurements](#chain-of-trust) include measurements that are known, previously observed values.
- **Measurements produced by the cloud infrastructure and firmware of the CVM**:
These are measurements of closed-source firmware and other values controlled by the cloud provider.
While not being reproducible for the user, some of them can be compared against previously observed values.
Others may change frequently and aren't suitable for verification.
The [signed image measurements](#chain-of-trust) include measurements that are known, previously observed values.
* **Measurements produced by the Constellation bootloader and boot chain**:
The Constellation Bootloader takes over from the CVM firmware and [measures the rest of the boot chain](images.md).
The Constellation [Bootstrapper](microservices.md#bootstrapper) is the first user mode component that runs in a Constellation image.
It extends PCR registers with the [IDs](keys.md#cluster-identity) of the cluster marking a node as initialized.
- **Measurements produced by the Constellation bootloader and boot chain**:
The Constellation Bootloader takes over from the CVM firmware and [measures the rest of the boot chain](images.md).
The Constellation [Bootstrapper](microservices.md#bootstrapper) is the first user mode component that runs in a Constellation image.
It extends PCR registers with the [IDs](keys.md#cluster-identity) of the cluster marking a node as initialized.
Constellation allows to specify in the config which measurements should be enforced during the attestation process.
Enforcing non-reproducible measurements controlled by the cloud provider means that changes in these values require manual updates to the cluster's config.
@ -264,17 +266,17 @@ On AWS, AMD SEV-SNP is used to provide runtime encryption to the VMs.
An SEV-SNP attestation report is used to establish trust in the VM.
You may customize certain parameters for verification of the attestation statement using the Constellation config file.
* TCB versions
- TCB versions
You can set the minimum version numbers of components in the SEV-SNP TCB.
Use the latest versions to enforce that only machines with the most recent firmware updates are allowed to join the cluster.
Alternatively, you can set a lower minimum version to allow slightly out-of-date machines to still be able to join the cluster.
* AMD Root Key Certificate
- AMD Root Key Certificate
This certificate is the root of trust for verifying the SEV-SNP certificate chain.
* AMD Signing Key Certificate
- AMD Signing Key Certificate
This is the intermediate certificate for verifying the SEV-SNP report's signature.
If it's not specified, the CLI fetches it from the AMD key distribution server.
@ -286,17 +288,17 @@ On Azure, AMD SEV-SNP is used to provide runtime encryption to the VMs.
An SEV-SNP attestation report is used to establish trust in the vTPM running inside the VM.
You may customize certain parameters for verification of the attestation statement using the Constellation config file.
* TCB versions
- TCB versions
You can set the minimum version numbers of components in the SEV-SNP TCB.
Use the latest versions to enforce that only machines with the most recent firmware updates are allowed to join the cluster.
Alternatively, you can set a lower minimum version to allow slightly out-of-date machines to still be able to join the cluster.
* AMD Root Key Certificate
- AMD Root Key Certificate
This certificate is the root of trust for verifying the SEV-SNP certificate chain.
* Firmware Signer
- Firmware Signer
This config option allows you to specify how the firmware signer should be verified.
More explicitly, it controls the verification of the `IDKeyDigest` value in the SEV-SNP attestation report.
@ -309,17 +311,17 @@ On GCP, AMD SEV-SNP is used to provide runtime encryption to the VMs.
An SEV-SNP attestation report is used to establish trust in the VM.
You may customize certain parameters for verification of the attestation statement using the Constellation config file.
* TCB versions
- TCB versions
You can set the minimum version numbers of components in the SEV-SNP TCB.
Use the latest versions to enforce that only machines with the most recent firmware updates are allowed to join the cluster.
Alternatively, you can set a lower minimum version to allow slightly out-of-date machines to still be able to join the cluster.
* AMD Root Key Certificate
- AMD Root Key Certificate
This certificate is the root of trust for verifying the SEV-SNP certificate chain.
* AMD Signing Key Certificate
- AMD Signing Key Certificate
This is the intermediate certificate for verifying the SEV-SNP report's signature.
If it's not specified, the CLI fetches it from the AMD key distribution server.
@ -336,25 +338,25 @@ There is no additional configuration available for STACKIT.
## Cluster attestation
Cluster-facing, Constellation's [*JoinService*](microservices.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
User-facing, the [*VerificationService*](microservices.md#verificationservice) provides an interface to verify a node using remote attestation.
By verifying the first node during the [initialization](microservices.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the *JoinService*, the whole cluster is verified in a transitive way.
Cluster-facing, Constellation's [_JoinService_](microservices.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
User-facing, the [_VerificationService_](microservices.md#verificationservice) provides an interface to verify a node using remote attestation.
By verifying the first node during the [initialization](microservices.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the _JoinService_, the whole cluster is verified in a transitive way.
### Cluster-facing attestation
The *JoinService* is provided with the runtime measurements of the whitelisted Constellation image version as the ground truth.
During the initialization and the cluster bootstrapping, each node connects to the *JoinService* using [aTLS](#attested-tls-atls).
The _JoinService_ is provided with the runtime measurements of the whitelisted Constellation image version as the ground truth.
During the initialization and the cluster bootstrapping, each node connects to the _JoinService_ using [aTLS](#attested-tls-atls).
During the handshake, the node transmits an attestation statement including its runtime measurements.
The *JoinService* verifies that statement and compares the measurements against the ground truth.
The _JoinService_ verifies that statement and compares the measurements against the ground truth.
For details of the initialization process check the [microservice descriptions](microservices.md).
After the initialization, every node updates its runtime measurements with the *clusterID* value, marking it irreversibly as initialized.
After the initialization, every node updates its runtime measurements with the _clusterID_ value, marking it irreversibly as initialized.
When an initialized node tries to join another cluster, its measurements inevitably mismatch the measurements of an uninitialized node and it will be declined.
### User-facing attestation
The [*VerificationService*](microservices.md#verificationservice) provides an endpoint for obtaining its hardware-based remote attestation statement, which includes the runtime measurements.
A user can [verify](../workflows/verify-cluster.md) this statement and compare the measurements against the configured ground truth and, thus, verify the identity and integrity of all Constellation components and the cluster configuration. Subsequently, the user knows that the entire cluster is in the expected state and is trustworthy.
The [_VerificationService_](microservices.md#verificationservice) provides an endpoint for obtaining its hardware-based remote attestation statement, which includes the runtime measurements.
A user can [verify](../../workflows/verify-cluster.md) this statement and compare the measurements against the configured ground truth and, thus, verify the identity and integrity of all Constellation components and the cluster configuration. Subsequently, the user knows that the entire cluster is in the expected state and is trustworthy.
## Putting it all together
@ -362,20 +364,20 @@ This section puts the aforementioned concepts together and illustrate how trust
### CLI and node images
It all starts with the CLI executable. The CLI is signed by Edgeless Systems. To ensure non-repudiability for CLI releases, Edgeless Systems publishes corresponding signatures to the public ledger of the [sigstore project](https://www.sigstore.dev/). There's a [step-by-step guide](../workflows/verify-cli.md) on how to verify CLI signatures based on sigstore.
It all starts with the CLI executable. The CLI is signed by Edgeless Systems. To ensure non-repudiability for CLI releases, Edgeless Systems publishes corresponding signatures to the public ledger of the [sigstore project](https://www.sigstore.dev/). There's a [step-by-step guide](../../workflows/verify-cli.md) on how to verify CLI signatures based on sigstore.
The CLI contains the latest runtime measurements of the Constellation node image for all supported cloud platforms. In case a different version of the node image is to be used, the corresponding runtime measurements can be fetched using the CLI's [fetch-measurements command](../reference/cli.md#constellation-config-fetch-measurements). This command downloads the runtime measurements and the corresponding signature from cdn.confidential.cloud. See for example the following files corresponding to node image v2.16.3:
The CLI contains the latest runtime measurements of the Constellation node image for all supported cloud platforms. In case a different version of the node image is to be used, the corresponding runtime measurements can be fetched using the CLI's [fetch-measurements command](../../reference/cli.md#constellation-config-fetch-measurements). This command downloads the runtime measurements and the corresponding signature from cdn.confidential.cloud. See for example the following files corresponding to node image v2.16.3:
* [Measurements](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json)
* [Signature](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json.sig)
- [Measurements](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json)
- [Signature](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json.sig)
The CLI contains the long-term public key of Edgeless Systems to verify the signature of downloaded runtime measurements.
### Cluster creation
When a cluster is [created](../workflows/create.md), the CLI automatically verifies the runtime measurements of the *first node* using remote attestation. Based on this, the CLI and the first node set up a temporary TLS connection. This [aTLS](#attested-tls-atls) connection is used for two things:
When a cluster is [created](../../workflows/create.md), the CLI automatically verifies the runtime measurements of the _first node_ using remote attestation. Based on this, the CLI and the first node set up a temporary TLS connection. This [aTLS](#attested-tls-atls) connection is used for two things:
1. The CLI sends the [master secret](../architecture/keys.md#master-secret) of the to-be-created cluster to the CLI. The master secret is generated by the first node.
1. The CLI sends the [master secret](keys.md#master-secret) of the to-be-created cluster to the CLI. The master secret is generated by the first node.
2. The first node sends a [kubeconfig file](https://www.redhat.com/sysadmin/kubeconfig) with Kubernetes credentials to the CLI.
After this, the aTLS connection is closed and the first node bootstraps the Kubernetes cluster. All subsequent interactions between the CLI and the cluster go via the [Kubernetes API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) server running inside the cluster. The CLI (and other tools like kubectl) use the credentials referenced by the kubeconfig file to authenticate themselves towards the Kubernetes API server and to establish a mTLS connection.
@ -400,10 +402,11 @@ flowchart LR
### Upgrades
Whenever a cluster is [upgraded](../workflows/upgrade.md) to a new version of the node image, the CLI sends the corresponding runtime measurements via the Kubernetes API server. The new runtime measurements are stored in etcd within the cluster and replace any previous runtime measurements. The new runtime measurements are then used automatically by the JoinService for the verification of new nodes.
Whenever a cluster is [upgraded](../../workflows/upgrade.md) to a new version of the node image, the CLI sends the corresponding runtime measurements via the Kubernetes API server. The new runtime measurements are stored in etcd within the cluster and replace any previous runtime measurements. The new runtime measurements are then used automatically by the JoinService for the verification of new nodes.
## References
[^1]: Linux IMA produces runtime measurements of user-space binaries.
However, these measurements aren't deterministic and thus, PCR\[10] can't be compared to a constant value.
Instead, a policy engine must be used to verify the TPM event log against a policy.
[^1]:
Linux IMA produces runtime measurements of user-space binaries.
However, these measurements aren't deterministic and thus, PCR\[10] can't be compared to a constant value.
Instead, a policy engine must be used to verify the TPM event log against a policy.

6
docs/docs/architecture/encrypted-storage.md → docs/docs/architecture/old/encrypted-storage.md
View File

@ -5,7 +5,7 @@ In the context of Kubernetes, this is sufficient for the confidentiality and int
Consider a front-end web server, for example, that keeps all connection information cached in main memory.
No sensitive data is ever written to an insecure medium.
However, many real-world applications need some form of state or data-lake service that's connected to a persistent storage device and requires encryption at rest.
As described in [Use persistent storage](../workflows/storage.md), cloud service providers (CSPs) use the container storage interface (CSI) to make their storage solutions available to Kubernetes workloads.
As described in [Use persistent storage](../../workflows/storage.md), cloud service providers (CSPs) use the container storage interface (CSI) to make their storage solutions available to Kubernetes workloads.
These CSI storage solutions often support some sort of encryption.
For example, Google Cloud [encrypts data at rest by default](https://cloud.google.com/security/encryption/default-encryption), without any action required by the customer.
@ -28,7 +28,7 @@ All cryptographic operations happen inside the trusted environment of the confid
Note that for integrity-protected disks, [volume expansion](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/) isn't supported.
By default the driver uses data encryption keys (DEKs) issued by the Constellation [*KeyService*](microservices.md#keyservice).
By default the driver uses data encryption keys (DEKs) issued by the Constellation [_KeyService_](microservices.md#keyservice).
The DEKs are in turn derived from the Constellation's key encryption key (KEK), which is directly derived from the [master secret](keys.md#master-secret).
This is the recommended mode of operation, and also requires the least amount of setup by the cluster administrator.
@ -59,4 +59,4 @@ The tag size is 32 Bytes.
## Encrypted S3 object storage
Constellation comes with a service that you can use to transparently retrofit client-side encryption to existing applications that use S3 (AWS or compatible) for storage.
To learn more, check out the [s3proxy documentation](../workflows/s3proxy.md).
To learn more, check out the [s3proxy documentation](../../workflows/s3proxy.md).

0
docs/docs/architecture/images.md → docs/docs/architecture/old/images.md
View File

30
docs/docs/architecture/old/key-concepts.md Normal file
View File

@ -0,0 +1,30 @@
# Key concepts
Constellation is a cloud-based confidential orchestration platform.
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).
## Orchestration and updates
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).
## Microservices and attestation
Constellation manages the nodes and network in your cluster. All nodes are bootstrapped by the [_Bootstrapper_](microservices.md#bootstrapper). They're verified and authenticated by the [_JoinService_](microservices.md#joinservice) before being added to the cluster and the network. Finally, the entire cluster can be verified via the [_VerificationService_](microservices.md#verificationservice) using [remote attestation](attestation.md).
## Node images and verified boot
Constellation comes with operating system images for Kubernetes control-plane and worker nodes.
They're highly optimized for running containerized workloads and specifically prepared for running inside confidential VMs.
You can learn more about [the images](images.md) and how verified boot ensures their integrity during boot and beyond.
## Key management and cryptographic primitives
Encryption of data at-rest, in-transit, and in-use is the fundamental building block for confidential computing and Constellation. Learn more about the [keys and cryptographic primitives](keys.md) used in Constellation, [encrypted persistent storage](encrypted-storage.md), and [network encryption](networking.md).
## Observability
Observability in Kubernetes refers to the capability to troubleshoot issues using telemetry signals such as logs, metrics, and traces.
In the realm of Confidential Computing, it's crucial that observability aligns with confidentiality, necessitating careful implementation.
Learn more about the [observability capabilities in Constellation](./observability.md).

32
docs/docs/architecture/keys.md → docs/docs/architecture/old/keys.md
View File

@ -12,7 +12,7 @@ For details on the implementations and cryptographic soundness, refer to the har
## Master secret
The master secret is the cryptographic material used for deriving the [*clusterID*](#cluster-identity) and the *key encryption key (KEK)* for [storage encryption](#storage-encryption).
The master secret is the cryptographic material used for deriving the [_clusterID_](#cluster-identity) and the _key encryption key (KEK)_ for [storage encryption](#storage-encryption).
It's generated during the bootstrapping of a Constellation cluster.
It can either be managed by [Constellation](#constellation-managed-key-management) or an [external key management system](#user-managed-key-management).
In case of [recovery](#recovery-and-migration), the master secret allows to decrypt the state and recover a Constellation cluster.
@ -27,10 +27,10 @@ On node boot, they're determined using the CVM's attestation mechanism and [meas
The **clusterID** represents the identity of a single initialized Constellation cluster.
It's derived from the master secret and a cryptographically random salt and unique for every Constellation cluster.
The [Bootstrapper](microservices.md#bootstrapper) measures the *clusterID* into its own PCR before executing any code not measured as part of the *base measurements*.
The [Bootstrapper](microservices.md#bootstrapper) measures the _clusterID_ into its own PCR before executing any code not measured as part of the _base measurements_.
See [Node attestation](attestation.md#node-attestation) for details.
The remote attestation statement of a Constellation cluster combines the *base measurements* and the *clusterID* for a verifiable, unspoofable, unique identity.
The remote attestation statement of a Constellation cluster combines the _base measurements_ and the _clusterID_ for a verifiable, unspoofable, unique identity.
## Network encryption
@ -50,16 +50,16 @@ Constellation supports transparent encryption of persistent storage.
The Linux kernel's device mapper-based encryption features are used to encrypt the data on the block storage level.
Currently, the following primitives are used for block storage encryption:
* [dm-crypt](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html)
* [dm-integrity](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html)
- [dm-crypt](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html)
- [dm-integrity](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html)
Adding primitives for integrity protection in the CVM attacker model are under active development and will be available in a future version of Constellation.
See [encrypted storage](encrypted-storage.md) for more details.
As a cluster administrator, when creating a cluster, you can use the Constellation [installation program](orchestration.md) to select one of the following methods for key management:
* Constellation-managed key management
* User-managed key management
- Constellation-managed key management
- User-managed key management
### Constellation-managed key management
@ -68,7 +68,7 @@ As a cluster administrator, when creating a cluster, you can use the Constellati
During the creation of a Constellation cluster, the cluster's master secret is used to derive a KEK.
This means creating two clusters with the same master secret will yield the same KEK.
Any data encryption key (DEK) is derived from the KEK via HKDF.
Note that the master secret is recommended to be unique for every cluster and shouldn't be reused (except in case of [recovering](../workflows/recovery.md) a cluster).
Note that the master secret is recommended to be unique for every cluster and shouldn't be reused (except in case of [recovering](../../workflows/recovery.md) a cluster).
#### State and storage
@ -87,7 +87,7 @@ The etcd storage is backed by the encrypted and integrity protected [state disk]
#### Recovery
Constellation clusters can be recovered in the event of a disaster, even when all node machines have been stopped and need to be rebooted.
For details on the process see the [recovery workflow](../workflows/recovery.md).
For details on the process see the [recovery workflow](../../workflows/recovery.md).
### User-managed key management
@ -100,10 +100,10 @@ This follows the common scheme of "bring your own key" (BYOK).
Constellation will support several KMSs for managing the storage and access of your KEK.
Initially, it will support the following KMSs:
* [AWS KMS](https://aws.amazon.com/kms/)
* [GCP KMS](https://cloud.google.com/security-key-management)
* [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/#product-overview)
* [KMIP-compatible KMS](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip)
- [AWS KMS](https://aws.amazon.com/kms/)
- [GCP KMS](https://cloud.google.com/security-key-management)
- [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/#product-overview)
- [KMIP-compatible KMS](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip)
Storing the keys in Cloud KMS of AWS, Azure, or GCP binds the key usage to the particular cloud identity access management (IAM).
In the future, Constellation will support remote attestation-based access policies for Cloud KMS once available.
@ -117,9 +117,9 @@ DEKs are generated to encrypt your data before storing it on persistent storage.
After being encrypted by the KEK, the DEKs are stored on dedicated cloud storage for persistence.
Currently, Constellation supports the following cloud storage options:
* [AWS S3](https://aws.amazon.com/s3/)
* [GCP Cloud Storage](https://cloud.google.com/storage)
* [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/#overview)
- [AWS S3](https://aws.amazon.com/s3/)
- [GCP Cloud Storage](https://cloud.google.com/storage)
- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/#overview)
The DEKs are only present in plaintext form in the encrypted main memory of the CVMs.
Similarly, the cryptographic operations for encrypting data before writing it to persistent storage are performed in the context of the CVMs.

29
docs/docs/architecture/microservices.md → docs/docs/architecture/old/microservices.md
View File

@ -4,10 +4,10 @@ Constellation takes care of bootstrapping and initializing a Confidential Kubern
During the lifetime of the cluster, it handles day 2 operations such as key management, remote attestation, and updates.
These features are provided by several microservices:
* The [Bootstrapper](microservices.md#bootstrapper) initializes a Constellation node and bootstraps the cluster
* The [JoinService](microservices.md#joinservice) joins new nodes to an existing cluster
* The [VerificationService](microservices.md#verificationservice) provides remote attestation functionality
* The [KeyService](microservices.md#keyservice) manages Constellation-internal keys
- The [Bootstrapper](microservices.md#bootstrapper) initializes a Constellation node and bootstraps the cluster
- The [JoinService](microservices.md#joinservice) joins new nodes to an existing cluster
- The [VerificationService](microservices.md#verificationservice) provides remote attestation functionality
- The [KeyService](microservices.md#keyservice) manages Constellation-internal keys
The relations between microservices are shown in the following diagram:
@ -34,19 +34,18 @@ flowchart LR
## Bootstrapper
The *Bootstrapper* is the first microservice launched after booting a Constellation node image.
The _Bootstrapper_ is the first microservice 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 the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](microservices.md#joinservice) to join the node.
To this end, the _Bootstrapper_ first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
The _Bootstrapper_ tries to find an existing cluster and if successful, communicates with the [JoinService](microservices.md#joinservice) to join the node.
Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
## 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.
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.
If attestation is successful, the new node is supplied with an encryption key from the [*KeyService*](microservices.md#keyservice) for its state disk, and a Kubernetes bootstrap token.
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 [_KeyService_](microservices.md#keyservice) for its state disk, and a Kubernetes bootstrap token.
```mermaid
sequenceDiagram
@ -62,12 +61,12 @@ sequenceDiagram
## VerificationService
The *VerificationService* runs as DaemonSet on each node.
The _VerificationService_ runs as DaemonSet on each node.
It provides user-facing functionality for remote attestation during the cluster's lifetime via an endpoint for [verifying the cluster](attestation.md#cluster-attestation).
Read more about the hardware-based [attestation feature](attestation.md) of Constellation and how to [verify](../workflows/verify-cluster.md) a cluster on the client side.
Read more about the hardware-based [attestation feature](attestation.md) of Constellation and how to [verify](../../workflows/verify-cluster.md) a cluster on the client side.
## KeyService
The *KeyService* runs as DaemonSet on each control-plane node.
The _KeyService_ 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 *KeyService* holds the key encryption key (KEK) directly or calls an external key management service (KMS) for key derivation respectively.
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 _KeyService_ holds the key encryption key (KEK) directly or calls an external key management service (KMS) for key derivation respectively.

0
docs/docs/architecture/networking.md → docs/docs/architecture/old/networking.md
View File

2
docs/docs/architecture/observability.md → docs/docs/architecture/old/observability.md
View File

@ -36,7 +36,7 @@ The payload is an actual message emitted from your system along with a metadata
Detailed system-level logs are accessible via `/var/log` and [journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) on the nodes directly.
They can be collected from there, for example, via [Filebeat and Logstash](https://www.elastic.co/guide/en/beats/filebeat/current/logstash-output.html), which are tools of the [Elastic Stack](https://www.elastic.co/de/elastic-stack/).
In case of an error during the initialization, the CLI automatically collects the [Bootstrapper](./microservices.md#bootstrapper) logs and returns these as a file for [troubleshooting](../workflows/troubleshooting.md). Here is an example of such an event:
In case of an error during the initialization, the CLI automatically collects the [Bootstrapper](./microservices.md#bootstrapper) logs and returns these as a file for [troubleshooting](../../workflows/troubleshooting.md). Here is an example of such an event:
```shell-session
Cluster initialization failed. This error is not recoverable.

36
docs/docs/architecture/orchestration.md → docs/docs/architecture/old/orchestration.md
View File

@ -7,7 +7,7 @@ The CLI is also used for updating your cluster.
## Workspaces
Each Constellation cluster has an associated *workspace*.
Each Constellation cluster has an associated _workspace_.
The workspace is where data such as the Constellation state and config files are stored.
Each workspace is associated with a single cluster and configuration.
The CLI stores state in the local filesystem making the current directory the active workspace.
@ -21,15 +21,15 @@ Only when a cluster was terminated, and you are sure the files aren't needed any
## Cluster creation process
To allow for fine-grained configuration of your cluster and cloud environment, Constellation supports an extensive configuration file with strong defaults. [Generating the configuration file](../workflows/config.md) is typically the first thing you do in the workspace.
To allow for fine-grained configuration of your cluster and cloud environment, Constellation supports an extensive configuration file with strong defaults. [Generating the configuration file](../../workflows/config.md) is typically the first thing you do in the workspace.
Altogether, the following files are generated during the creation of a Constellation cluster and stored in the current workspace:
* a configuration file
* a state file
* a Base64-encoded master secret
* [Terraform artifacts](../reference/terraform.md), stored in subdirectories
* a Kubernetes `kubeconfig` file.
- a configuration file
- a state file
- a Base64-encoded master secret
- [Terraform artifacts](../../reference/terraform.md), stored in subdirectories
- a Kubernetes `kubeconfig` file.
After the initialization of your cluster, the CLI will provide you with a Kubernetes `kubeconfig` file.
This file grants you access to your Kubernetes cluster and configures the [kubectl](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) tool.
@ -39,13 +39,13 @@ In addition, the cluster's [identifier](orchestration.md#post-installation-confi
1. The CLI `apply` command first creates the confidential VM (CVM) resources in your cloud environment and configures the network
2. Each CVM boots the Constellation node image and measures every component in the boot chain
3. The first microservice launched in each node is the [*Bootstrapper*](microservices.md#bootstrapper)
4. The *Bootstrapper* waits until it either receives an initialization request or discovers an initialized cluster
5. The CLI then connects to the *Bootstrapper* of a selected node, sends the configuration, and initiates the initialization of the cluster
6. The *Bootstrapper* of **that** node [initializes the Kubernetes cluster](microservices.md#bootstrapper) and deploys the other Constellation [microservices](microservices.md) including the [*JoinService*](microservices.md#joinservice)
7. Subsequently, the *Bootstrappers* of the other nodes discover the initialized cluster and send join requests to the *JoinService*
3. The first microservice launched in each node is the [_Bootstrapper_](microservices.md#bootstrapper)
4. The _Bootstrapper_ waits until it either receives an initialization request or discovers an initialized cluster
5. The CLI then connects to the _Bootstrapper_ of a selected node, sends the configuration, and initiates the initialization of the cluster
6. The _Bootstrapper_ of **that** node [initializes the Kubernetes cluster](microservices.md#bootstrapper) and deploys the other Constellation [microservices](microservices.md) including the [_JoinService_](microservices.md#joinservice)
7. Subsequently, the _Bootstrappers_ of the other nodes discover the initialized cluster and send join requests to the _JoinService_
8. As part of the join request each node includes an attestation statement of its boot measurements as authentication
9. The *JoinService* verifies the attestation statements and joins the nodes to the Kubernetes cluster
9. The _JoinService_ verifies the attestation statements and joins the nodes to the Kubernetes cluster
10. This process is repeated for every node joining the cluster later (e.g., through autoscaling)
## Post-installation configuration
@ -56,22 +56,22 @@ Once configured, orchestrate the Kubernetes cluster via `kubectl`.
After the initialization, the CLI will present you with a couple of tokens:
* The [*master secret*](keys.md#master-secret) (stored in the `constellation-mastersecret.json` file by default)
* The [*clusterID*](keys.md#cluster-identity) of your cluster in Base64 encoding
- The [_master secret_](keys.md#master-secret) (stored in the `constellation-mastersecret.json` file by default)
- The [_clusterID_](keys.md#cluster-identity) of your cluster in Base64 encoding
You can read more about these values and their meaning in the guide on [cluster identity](keys.md#cluster-identity).
The *master secret* must be kept secret and can be used to [recover your cluster](../workflows/recovery.md).
The _master secret_ must be kept secret and can be used to [recover your cluster](../../workflows/recovery.md).
Instead of managing this secret manually, you can [use your key management solution of choice](keys.md#user-managed-key-management) with Constellation.
The *clusterID* uniquely identifies a cluster and can be used to [verify your cluster](../workflows/verify-cluster.md).
The _clusterID_ uniquely identifies a cluster and can be used to [verify your cluster](../../workflows/verify-cluster.md).
## Upgrades
Constellation images and microservices may need to be upgraded to new versions during the lifetime of a cluster.
Constellation implements a rolling update mechanism ensuring no downtime of the control or data plane.
You can upgrade a Constellation cluster with a single operation by using the CLI.
For step-by-step instructions on how to do this, refer to [Upgrade your cluster](../workflows/upgrade.md).
For step-by-step instructions on how to do this, refer to [Upgrade your cluster](../../workflows/upgrade.md).
### Attestation of upgrades

8
docs/docs/architecture/versions.md → docs/docs/architecture/old/versions.md
View File

@ -14,8 +14,10 @@ When a new minor version of Kubernetes is released, support is added to the next
Subsequent Constellation releases drop support for the oldest (and deprecated) Kubernetes version.
The following Kubernetes versions are currently supported:
<!--AUTO_GENERATED_BY_BAZEL-->
<!--DO_NOT_EDIT-->
* v1.28.13
* v1.29.8
* v1.30.4
- v1.28.13
- v1.29.8
- v1.30.4

275
docs/docs/architecture/overview.md
View File

@ -1,30 +1,245 @@
# Overview
Constellation is a cloud-based confidential orchestration platform.
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).
## About orchestration and updates
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).
## About microservices and attestation
Constellation manages the nodes and network in your cluster. All nodes are bootstrapped by the [*Bootstrapper*](microservices.md#bootstrapper). They're verified and authenticated by the [*JoinService*](microservices.md#joinservice) before being added to the cluster and the network. Finally, the entire cluster can be verified via the [*VerificationService*](microservices.md#verificationservice) using [remote attestation](attestation.md).
## About node images and verified boot
Constellation comes with operating system images for Kubernetes control-plane and worker nodes.
They're highly optimized for running containerized workloads and specifically prepared for running inside confidential VMs.
You can learn more about [the images](images.md) and how verified boot ensures their integrity during boot and beyond.
## About key management and cryptographic primitives
Encryption of data at-rest, in-transit, and in-use is the fundamental building block for confidential computing and Constellation. Learn more about the [keys and cryptographic primitives](keys.md) used in Constellation, [encrypted persistent storage](encrypted-storage.md), and [network encryption](networking.md).
## About observability
Observability in Kubernetes refers to the capability to troubleshoot issues using telemetry signals such as logs, metrics, and traces.
In the realm of Confidential Computing, it's crucial that observability aligns with confidentiality, necessitating careful implementation.
Learn more about the [observability capabilities in Constellation](./observability.md).
# Protocol overview
The security of Constellation is based on a set of protocols.
The protocols are outlined in the following.
The following diagram sketches the basic trust relationships between the entities in a Constellation cluster.
![chain of trust](chain-of-trust.jpg)
## Software components
Abstractly, the Constellation software comprises three core components:
1. The command-line interface (CLI) executable, which is run by the cluster administrator on their local machine.
2. The node images, which are run inside Confidential VMs (CVMs).
Among other, each node image contains a Linux kernel and a user mode program called Bootstrapper.
3. The Constellation service containers, which are run on Kubernetes.
There are three core services: KeyService, JoinService, and VerificationService.
## CLI: root of trust
The CLI executable is signed by Edgeless Systems.
To ensure non-repudiability for CLI releases, Edgeless Systems publishes corresponding signatures to the public ledger of the [Sigstore project](https://www.sigstore.dev/).
There's a [step-by-step guide](https://docs.edgeless.systems/constellation/workflows/verify-cli) on how to verify CLI signatures based on Sigstore.
The CLI contains the [measurements](https://github.com/edgelesssys/constellation/blob/edc0c7068ef4527efeaf584a2a35e0f51f58c426/internal/attestation/measurements/measurements_enterprise.go#L21) of the latest Constellation node image for all supported cloud platforms.
The CLI writes these measurements as part of the _attestation config_ to a cluster's config file with the ["config generate" command](https://docs.edgeless.systems/constellation/workflows/config).
Note that Constellation currently uses 16 TPM-based runtime measurements for each cloud platform.
The purpose and source of the measurements are described in the [next section](#remote-attestation-of-nodes).
In addition to the measurements, the attestation config contains expected patch levels for the CPU microcode and the X.509 certificate of the CPU vendor's remote attestation infrastructure.
An example of an attestation config is given [below](#attestation-config).
In case a different version of the node image is to be used, the corresponding measurements can be fetched using the CLI's ["config fetch-measurements" command](reference/cli#constellation-config-fetch-measurements).
This command downloads the measurements and the corresponding signature from Edgeless Systems from https://cdn.confidential.cloud.
See for example the following files corresponding to node image v2.16.3:
- [Measurements](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json)
- [Signature](https://cdn.confidential.cloud/constellation/v2/ref/-/stream/stable/v2.16.3/image/measurements.json.sig)
In addition to the attestation config, the CLI contains the following data in hardcoded form:
- The [long-term public key of Edgeless Systems](https://github.com/edgelesssys/constellation/blob/edc0c7068ef4527efeaf584a2a35e0f51f58c426/internal/constants/constants.go#L264) to verify the signature of downloaded measurements.
- The [hashes of the expected Kubernetes binaries](https://github.com/edgelesssys/constellation/blob/edc0c7068ef4527efeaf584a2a35e0f51f58c426/internal/versions/versions.go#L199).
- The [Helm charts used for the installation of services](https://github.com/edgelesssys/constellation/tree/main/internal/constellation/helm/charts), which include hashes of the respective containers.
Note that the Helm charts and the hashes are [generated at build time](https://github.com/edgelesssys/constellation/blob/main/internal/constellation/helm/imageversion/imageversion.go).
A future version of the CLI will provide a command to print the Helm charts.
## Cluster creation
When a cluster is [created](https://docs.edgeless.systems/constellation/workflows/create), the CLI interacts with the API of the respective infrastructure provider, for example Azure, and launches CVMs with the applicable node image.
These CVMs are called _nodes_.
On each node, the Bootstrapper is launched.
The CLI automatically selects one of the nodes as _first node_.
The CLI automatically verifies the first node's remote-attestation statement using the attestation config.
Details on remote attestation are given in the [next section](#remote-attestation-of-nodes).
Based on the remote-attestation statement, the CLI and the Bootstrapper running on the first node set up a temporary TLS connection between them.
We refer to this type of connection as "attested TLS" (aTLS).
This connection is mainly used for three things (see the the [interface definition](https://github.com/edgelesssys/constellation/blob/main/bootstrapper/initproto/init.proto) for a comprehensive list of exchanged data):
1. The CLI sends the hashes of the expected Kubernetes binaries to the first node.
2. The CLI generates the [master secret](architecture/old/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 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_ TPM register 15 with the unique ID of the cluster (`clusterID`).
More information can be found in the [Constellation documentation](https://docs.edgeless.systems/constellation/architecture/keys#cluster-identity).
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.
## Remote attestation of nodes
To identify themselves, nodes use the remote-attestation functionality of the underlying CVM platform.
Constellation supports Intel TDX and AMD SEV-SNP based platforms.
Abstractly, Intel TDX and AMD SEV-SNP hash the initial memory contents of the CVMs.
This hash is also called `launch digest`.
The launch digest is reflected in each remote-attestation statement that is requested by the software inside the CVM.
Abstractly, a remote-attestation statement `R` from a CVM looks as follows:
```
R = Sig-CPU(<launch digest>, <auxiliary data>, <payload>)
```
The `payload` is controlled by the software running inside the CVM.
In the case of a Constellation node, the `payload` is always the public key of the respective Bootstrapper running inside the CVM.
Thus, `R` can be seen as a certificate for that public key issued by the CPU.
Based on this, nodes establish attested TLS (aTLS) connections.
aTLS is used during [cluster creation](#cluster-creation) and when [growing a cluster](#cluster-growth).
### Measurements
In the ideal case, the underlying CVM platform does not inject any of its own software into a CVM.
In that case, a Constellation node image can contain its own firmware/UEFI.
This allows for the creation of node images for which the launch digest covers all defining parts of a node, including the firmware, the kernel, the kernel command line, and the disk image.
In this case, the launch digest is the only measurement that's required to verify the identity and integrity of a node.
### Measured Boot as fallback
However, currently, all supported CVM platforms (AWS, Azure, and GCP) inject custom firmware into CVMs.
Thus, in practice, Constellation relies on conventional [measured boot](https://docs.edgeless.systems/constellation/architecture/images#measured-boot) to reflect the identity and integrity of nodes.
In measured boot, in general, the software components involved in the boot process of a system are "measured" into the 16 registers of a Trusted Platform Module (TPM).
The values of these registers are also called "runtime measurements".
All supported CVM platforms provide TPMs to CVMs.
Constellation nodes use these to measure their boot process.
They include the 16 runtime measurements as `auxiliary data` in `R`.
On each CVM platform, runtime measurements are taken differently.
Details on this are given in the [Constellation documentation](https://docs.edgeless.systems/constellation/architecture/attestation#runtime-measurements).
With measured boot, Constellation only checks the 16 runtime measurements during the verification of a node's remote-attestation statement.
The launch digest is not considered, because it only covers the firmware injected by the CVM platform and may change whenever the CVM platform is updated.
Currently, on AWS and GCP the TPM implementation resides outside the CVM.
On Azure, the TPM implementation is part of the injected firmware and resides inside the CVM.
More information can be found in the [Constellation documentation](https://docs.edgeless.systems/constellation/overview/clouds).
## Kubernetes bootstrapping on the first node
The Bootstrapper on the first node downloads and verifies the Kubernetes binaries, using the hashes it received from the CLI.
These binaries include for example [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/), and [etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/).
With these, the Bootstrapper creates a single-node Kubernetes cluster.
Etcd is a distributed key-value store that Kubernetes uses to store configuration data for services.
The etcd agent runs on each control-plane node of a cluster.
The agents use mTLS for communication between them.
Etcd uses the Raft protocol (over mTLS) to distribute state between nodes.
All essential configuration data of a cluster is kept in etcd.
Initially, the Bootstrapper on the first node [writes](https://github.com/edgelesssys/constellation/blob/d65987cb15cf9ebdbbd2975f177937c1acbc90f8/bootstrapper/internal/kubernetes/kubernetes.go#L173) the hashes of the expected Kubernetes binaries to a specific key in etcd.
Next, the CLI connects to the Kubernetes API server (kube-apiserver) using the kubeconfig file it received from the Bootstrapper.
This results in an mTLS connection between the CLI and the Kubernetes API server.
The CLI uses this connection for two essential operations at the Kubernetes level:
1. It writes the attestation config to a specific key in etcd.
1. It executes the [hardcoded Helm charts](#cli-root-of-trust), which, most notably, install the three core services KeyService, JoinService, and VerificationService, the [constellation-node-operator](https://github.com/edgelesssys/constellation/tree/main/operators/constellation-node-operator), and a small number of standard services like Cilium and cert-manager.
The latter causes the first node to download, verify, and run the containers defined in the Helm charts.
The containers that are specific to Constellation are hosted at https://ghcr.io/edgelesssys.
After this, the Constellation cluster is operational on the first node.
## Cluster growth
Additional nodes can now join the cluster - either as control-plane nodes or as worker nodes.
For both, the process for joining the cluster is identical.
First, the Bootstrapper running on a _new node_ contacts the JoinService of the existing cluster.
The JoinService verifies the remote-attestation statement of the new node using the attestation config stored in etcd.
On success, an aTLS connection between the two is created, which is used mainly for the following (see the the [interface definition](https://github.com/edgelesssys/constellation/blob/main/joinservice/joinproto/join.proto) for a comprehensive list of exchanged data):
1. The new node sends a certificate signing request (CSR) for its _node certificate_ to the JoinService.
1. The JoinService issues a corresponding certificate with a lifetime of one year and sends it to the new node.
The JoinService uses the signing key of the Kubernetes cluster for this, which is [generated by kubeadm](https://kubernetes.io/docs/setup/best-practices/certificates/). Note that the lifetime of the node certificate is a best practice only, as Constellation relies on the untrusted infrastructure to provide time when validating certificates.
1. The JoinService sends a [kubeadm token](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/) to the new node.
1. The JoinService sends the hashes of the expected Kubernetes binaries to the new node.
1. The JoinService sends encryption key for the new node's local storage.
This key is generated and managed by the cluster's KeyService.
1. The JoinService sends the certificate of the cluster's control plane to the new node.
After this, the aTLS connection is closed and the node is marked as "initialized" in the same way as described [above](#cluster-creation).
The Bootstrapper downloads, verifies, and runs the given Kubernetes binaries.
Further, the Bootstrapper uses the kubeadm token to download the configuration of the cluster from the Kubernetes API server.
The kubeadm token is never used after this.
The kubelet on the new node uses its own node certificate and the certificate of the cluster's control plane (which the new node both received from the JoinService) to establish an mTLS connection with the cluster's Kubernetes API server.
Once connected, the new node registers itself as control-plane node or worker node of the cluster.
This process uses the standard Kubernetes mechanisms for adding nodes.
In Constellation, a virtual private network (VPN) exists between all nodes of a cluster.
This VPN is created with the help of Cilium.
To join this VPN, the new node generates WireGuard credentials for itself and writes the public key to etcd via the mTLS connection with the Kubernetes API server.
It also downloads the public keys of existing nodes from etcd.
Subsequently, the Cilium agents running on other nodes fetch the new node's public key from etcd as well.
Note that etcd communication between nodes is an exception: This traffic always goes via mTLS based on node certificates.
## Cluster upgrade
Whenever a cluster is [upgraded](https://docs.edgeless.systems/constellation/workflows/upgrade), the CLI connects to the Kubernetes API server and, essentially, updates the following data in etcd:
1. The attestation config
1. The hashes of the expected Kubernetes binaries
Further, the CLI applies updated Helm charts to update the cluster's services.
Again, these Helm charts are hardcoded in the CLI.
See the [implementation](https://github.com/edgelesssys/constellation/blob/d65987cb15cf9ebdbbd2975f177937c1acbc90f8/cli/internal/cmd/apply.go#L358) of the `apply()` function for a sequence diagram of all steps.
Subsequently, the constellation-node-operator replaces existing nodes with new ones.
New nodes go through the [usual process for joining the cluster](#cluster-growth).
## Examples
This section gives real life examples of key data structures and the corresponding commands to retrieve those.
### Attestation config
```bash
kubectl -n kube-system get cm join-config -o json
```
```json
{
"apiVersion": "v1",
"binaryData": {
"measurementSalt": "2A4Fzfdr/61XbJvk1PDqzh0R4rVnEujyXudsfgRZzUY="
},
"data": {
"attestationConfig": "{\"measurements\":{\"1\":{\"expected\":\"3695dcc55e3aa34027c27793c85c723c697d708c42d1f73bd6fa4f26608a5b24\",\"warnOnly\":true},\"11\":{\"expected\":\"f09cef0d077127fb26bc8d013fc09e13afbb70f0f734ced98f46666544998efe\",\"warnOnly\":true},\"12\":{\"expected\":\"0000000000000000000000000000000000000000000000000000000000000000\",\"warnOnly\":true},\"13\":{\"expected\":\"0000000000000000000000000000000000000000000000000000000000000000\",\"warnOnly\":true},\"14\":{\"expected\":\"0000000000000000000000000000000000000000000000000000000000000000\",\"warnOnly\":true},\"15\":{\"expected\":\"0000000000000000000000000000000000000000000000000000000000000000\",\"warnOnly\":true},\"2\":{\"expected\":\"3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969\",\"warnOnly\":true},\"3\":{\"expected\":\"3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969\",\"warnOnly\":true},\"4\":{\"expected\":\"e5020193148fbad0dbaf618fb3ef15665c72ff87a54e24b2d8f5bdf9719bb50b\",\"warnOnly\":true},\"6\":{\"expected\":\"3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969\",\"warnOnly\":true},\"8\":{\"expected\":\"0000000000000000000000000000000000000000000000000000000000000000\",\"warnOnly\":true},\"9\":{\"expected\":\"37ef16fd0ae8d2fb3b1914f0b8ff046e765b57fec6739d2ebf1fd4d182071437\",\"warnOnly\":true}},\"bootloaderVersion\":\"latest\",\"teeVersion\":\"latest\",\"snpVersion\":\"latest\",\"microcodeVersion\":\"latest\",\"amdRootKey\":\"-----BEGIN CERTIFICATE-----\\nMIIGYzCCBBKgAwIBAgIDAQAAMEYGCSqGSIb3DQEBCjA5oA8wDQYJYIZIAWUDBAIC\\nBQChHDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAICBQCiAwIBMKMDAgEBMHsxFDAS\\nBgNVBAsMC0VuZ2luZWVyaW5nMQswCQYDVQQGEwJVUzEUMBIGA1UEBwwLU2FudGEg\\nQ2xhcmExCzAJBgNVBAgMAkNBMR8wHQYDVQQKDBZBZHZhbmNlZCBNaWNybyBEZXZp\\nY2VzMRIwEAYDVQQDDAlBUkstTWlsYW4wHhcNMjAxMDIyMTcyMzA1WhcNNDUxMDIy\\nMTcyMzA1WjB7MRQwEgYDVQQLDAtFbmdpbmVlcmluZzELMAkGA1UEBhMCVVMxFDAS\\nBgNVBAcMC1NhbnRhIENsYXJhMQswCQYDVQQIDAJDQTEfMB0GA1UECgwWQWR2YW5j\\nZWQgTWljcm8gRGV2aWNlczESMBAGA1UEAwwJQVJLLU1pbGFuMIICIjANBgkqhkiG\\n9w0BAQEFAAOCAg8AMIICCgKCAgEA0Ld52RJOdeiJlqK2JdsVmD7FktuotWwX1fNg\\nW41XY9Xz1HEhSUmhLz9Cu9DHRlvgJSNxbeYYsnJfvyjx1MfU0V5tkKiU1EesNFta\\n1kTA0szNisdYc9isqk7mXT5+KfGRbfc4V/9zRIcE8jlHN61S1ju8X93+6dxDUrG2\\nSzxqJ4BhqyYmUDruPXJSX4vUc01P7j98MpqOS95rORdGHeI52Naz5m2B+O+vjsC0\\n60d37jY9LFeuOP4Meri8qgfi2S5kKqg/aF6aPtuAZQVR7u3KFYXP59XmJgtcog05\\ngmI0T/OitLhuzVvpZcLph0odh/1IPXqx3+MnjD97A7fXpqGd/y8KxX7jksTEzAOg\\nbKAeam3lm+3yKIcTYMlsRMXPcjNbIvmsBykD//xSniusuHBkgnlENEWx1UcbQQrs\\n+gVDkuVPhsnzIRNgYvM48Y+7LGiJYnrmE8xcrexekBxrva2V9TJQqnN3Q53kt5vi\\nQi3+gCfmkwC0F0tirIZbLkXPrPwzZ0M9eNxhIySb2npJfgnqz55I0u33wh4r0ZNQ\\neTGfw03MBUtyuzGesGkcw+loqMaq1qR4tjGbPYxCvpCq7+OgpCCoMNit2uLo9M18\\nfHz10lOMT8nWAUvRZFzteXCm+7PHdYPlmQwUw3LvenJ/ILXoQPHfbkH0CyPfhl1j\\nWhJFZasCAwEAAaN+MHwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSFrBrRQ/fI\\nrFXUxR1BSKvVeErUUzAPBgNVHRMBAf8EBTADAQH/MDoGA1UdHwQzMDEwL6AtoCuG\\nKWh0dHBzOi8va2RzaW50Zi5hbWQuY29tL3ZjZWsvdjEvTWlsYW4vY3JsMEYGCSqG\\nSIb3DQEBCjA5oA8wDQYJYIZIAWUDBAICBQChHDAaBgkqhkiG9w0BAQgwDQYJYIZI\\nAWUDBAICBQCiAwIBMKMDAgEBA4ICAQC6m0kDp6zv4Ojfgy+zleehsx6ol0ocgVel\\nETobpx+EuCsqVFRPK1jZ1sp/lyd9+0fQ0r66n7kagRk4Ca39g66WGTJMeJdqYriw\\nSTjjDCKVPSesWXYPVAyDhmP5n2v+BYipZWhpvqpaiO+EGK5IBP+578QeW/sSokrK\\ndHaLAxG2LhZxj9aF73fqC7OAJZ5aPonw4RE299FVarh1Tx2eT3wSgkDgutCTB1Yq\\nzT5DuwvAe+co2CIVIzMDamYuSFjPN0BCgojl7V+bTou7dMsqIu/TW/rPCX9/EUcp\\nKGKqPQ3P+N9r1hjEFY1plBg93t53OOo49GNI+V1zvXPLI6xIFVsh+mto2RtgEX/e\\npmMKTNN6psW88qg7c1hTWtN6MbRuQ0vm+O+/2tKBF2h8THb94OvvHHoFDpbCELlq\\nHnIYhxy0YKXGyaW1NjfULxrrmxVW4wcn5E8GddmvNa6yYm8scJagEi13mhGu4Jqh\\n3QU3sf8iUSUr09xQDwHtOQUVIqx4maBZPBtSMf+qUDtjXSSq8lfWcd8bLr9mdsUn\\nJZJ0+tuPMKmBnSH860llKk+VpVQsgqbzDIvOLvD6W1Umq25boxCYJ+TuBoa4s+HH\\nCViAvgT9kf/rBq1d+ivj6skkHxuzcxbk1xv6ZGxrteJxVH7KlX7YRdZ6eARKwLe4\\nAFZEAwoKCQ==\\n-----END CERTIFICATE-----\\n\",\"amdSigningKey\":\"\"}"
},
"kind": "ConfigMap",
"metadata": {
"creationTimestamp": "2024-09-25T11:11:50Z",
"name": "join-config",
"namespace": "kube-system",
"resourceVersion": "387",
"uid": "fdd0d5eb-cf58-4608-99c9-eede08895615"
}
}
```
### Hashes of Kubernetes binaries
```bash
kubectl -n kube-system get cm k8s-components-sha256-7b73c7675df78e5753b6e0fc86a9982127fd16141837599d5ce16df6bfe6a2a0 -o json
```
```json
{
"apiVersion": "v1",
"data": {
"cluster-version": "v1.29.8",
"components": "[{\"url\":\"https://github.com/containernetworking/plugins/releases/download/v1.4.0/cni-plugins-linux-amd64-v1.4.0.tgz\",\"hash\":\"sha256:c2485ddb3ffc176578ae30ae58137f0b88e50f7c7f2af7d53a569276b2949a33\",\"install_path\":\"/opt/cni/bin\",\"extract\":true},{\"url\":\"https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.29.0/crictl-v1.29.0-linux-amd64.tar.gz\",\"hash\":\"sha256:d16a1ffb3938f5a19d5c8f45d363bd091ef89c0bc4d44ad16b933eede32fdcbb\",\"install_path\":\"/run/state/bin\",\"extract\":true},{\"url\":\"https://storage.googleapis.com/kubernetes-release/release/v1.29.8/bin/linux/amd64/kubelet\",\"hash\":\"sha256:df6e130928403af8b4f49f1197e26f2873a147cd0e23aa6597a26c982c652ae0\",\"install_path\":\"/run/state/bin/kubelet\"},{\"url\":\"https://storage.googleapis.com/kubernetes-release/release/v1.29.8/bin/linux/amd64/kubeadm\",\"hash\":\"sha256:fe054355e0ae8dc35d868a3d3bc408ccdff0969c20bf7a231ae9b71484e41be3\",\"install_path\":\"/run/state/bin/kubeadm\"},{\"url\":\"https://storage.googleapis.com/kubernetes-release/release/v1.29.8/bin/linux/amd64/kubectl\",\"hash\":\"sha256:038454e0d79748aab41668f44ca6e4ac8affd1895a94f592b9739a0ae2a5f06a\",\"install_path\":\"/run/state/bin/kubectl\"},{\"url\":\"data:application/json;base64,W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9pbWFnZSIsInZhbHVlIjoicmVnaXN0cnkuazhzLmlvL2t1YmUtYXBpc2VydmVyOnYxLjI5LjhAc2hhMjU2OjZmNzJmYTkyNmM5YjA1ZTEwNjI5ZmUxYTA5MmZkMjhkY2Q2NWI0ZmRmZDBjYzdiZDU1Zjg1YTU3YTZiYTFmYTUifV0=\",\"install_path\":\"/opt/kubernetes/patches/kube-apiserver+json.json\"},{\"url\":\"data:application/json;base64,W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9pbWFnZSIsInZhbHVlIjoicmVnaXN0cnkuazhzLmlvL2t1YmUtY29udHJvbGxlci1tYW5hZ2VyOnYxLjI5LjhAc2hhMjU2OjZmMjdkNjNkZWQyMDYxNGM2ODU1NGI0NzdjZDdhNzhlZGE3OGE0OThhOTJiZmU4OTM1Y2Y5NjRjYTViNzRkMGIifV0=\",\"install_path\":\"/opt/kubernetes/patches/kube-controller-manager+json.json\"},{\"url\":\"data:application/json;base64,W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9pbWFnZSIsInZhbHVlIjoicmVnaXN0cnkuazhzLmlvL2t1YmUtc2NoZWR1bGVyOnYxLjI5LjhAc2hhMjU2OmRhNzRhNjY2NzVkOTVlMzllYzI1ZGE1ZTcwNzI5ZGE3NDZkMGZhMGIxNWVlMGRhODcyYWM5ODA1MTliYzI4YmQifV0=\",\"install_path\":\"/opt/kubernetes/patches/kube-scheduler+json.json\"},{\"url\":\"data:application/json;base64,W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL2NvbnRhaW5lcnMvMC9pbWFnZSIsInZhbHVlIjoicmVnaXN0cnkuazhzLmlvL2V0Y2Q6My41LjEyLTBAc2hhMjU2OjQ0YThlMjRkY2JiYTM0NzBlZTFmZWUyMWQ1ZTg4ZDEyOGM5MzZlOWI1NWQ0YmM1MWZiZWY4MDg2ZjhlZDEyM2IifV0=\",\"install_path\":\"/opt/kubernetes/patches/etcd+json.json\"}]"
},
"immutable": true,
"kind": "ConfigMap",
"metadata": {
"creationTimestamp": "2024-09-25T11:11:50Z",
"name": "k8s-components-sha256-7b73c7675df78e5753b6e0fc86a9982127fd16141837599d5ce16df6bfe6a2a0",
"namespace": "kube-system",
"resourceVersion": "356",
"uid": "6389c186-3bc8-4470-8af5-f6fed1addd69"
}
}
```

1
docs/docs/architecture/security/attestation.md Normal file
View File

@ -0,0 +1 @@
# Attestation

1
docs/docs/architecture/security/encrypted-networking.md Normal file
View File

@ -0,0 +1 @@
# Encrypted persistant storage

1
docs/docs/architecture/security/encrypted-persistant.md Normal file
View File

@ -0,0 +1 @@
# Encrypted networking

455
docs/sidebars.js
View File

@ -19,196 +19,196 @@ const sidebars = {
// But you can create a sidebar manually
docs: [
{
type: 'doc',
label: 'Introduction',
id: 'intro'
type: "doc",
label: "Introduction",
id: "intro",
},
{
type: 'category',
label: 'Basics',
type: "category",
label: "Basics",
link: {
type: 'generated-index',
type: "generated-index",
},
items: [
{
type: 'doc',
label: 'Confidential Kubernetes',
id: 'overview/confidential-kubernetes',
type: "doc",
label: "Confidential Kubernetes",
id: "overview/confidential-kubernetes",
},
{
type: 'doc',
label: 'Security benefits',
id: 'overview/security-benefits',
type: "doc",
label: "Security benefits",
id: "overview/security-benefits",
},
{
type: 'doc',
label: 'Product features',
id: 'overview/product',
type: "doc",
label: "Product features",
id: "overview/product",
},
{
type: 'doc',
label: 'Feature status of clouds',
id: 'overview/clouds',
type: "doc",
label: "Feature status of clouds",
id: "overview/clouds",
},
{
type: 'category',
label: 'Performance',
link: { type: 'doc', id: 'overview/performance/performance' },
type: "category",
label: "Performance",
link: { type: "doc", id: "overview/performance/performance" },
items: [
{
type: 'doc',
label: 'Compute benchmarks',
id: 'overview/performance/compute',
type: "doc",
label: "Compute benchmarks",
id: "overview/performance/compute",
},
{
type: 'doc',
label: 'I/O benchmarks',
id: 'overview/performance/io',
type: "doc",
label: "I/O benchmarks",
id: "overview/performance/io",
},
{
type: 'doc',
label: 'Application benchmarks',
id: 'overview/performance/application',
type: "doc",
label: "Application benchmarks",
id: "overview/performance/application",
},
]
],
},
{
type: 'doc',
label: 'License',
id: 'overview/license',
},
]
},
{
type: 'category',
label: 'Getting started',
link: {
type: 'generated-index',
},
items: [
{
type: 'doc',
label: 'Installation',
id: 'getting-started/install',
},
{
type: 'doc',
label: 'First steps (cloud)',
id: 'getting-started/first-steps',
},
{
type: 'doc',
label: 'First steps (local)',
id: 'getting-started/first-steps-local',
},
{
type: 'doc',
label: 'Cloud Marketplaces',
id: 'getting-started/marketplaces',
},
{
type: 'category',
label: 'Examples',
link: {
type: 'doc',
id: 'getting-started/examples',
},
items: [
{
type: 'doc',
label: 'Emojivoto',
id: 'getting-started/examples/emojivoto'
},
{
type: 'doc',
label: 'Online Boutique',
id: 'getting-started/examples/online-boutique'
},
{
type: 'doc',
label: 'Horizontal Pod Autoscaling',
id: 'getting-started/examples/horizontal-scaling'
},
{
type: 'doc',
label: 'Filestash with s3proxy',
id: 'getting-started/examples/filestash-s3proxy'
},
]
type: "doc",
label: "License",
id: "overview/license",
},
],
},
{
type: 'category',
label: 'Workflows',
type: "category",
label: "Getting started",
link: {
type: 'generated-index',
type: "generated-index",
},
items: [
{
type: 'doc',
label: 'Verify the CLI',
id: 'workflows/verify-cli',
type: "doc",
label: "Installation",
id: "getting-started/install",
},
{
type: 'doc',
label: 'Configure your cluster',
id: 'workflows/config',
type: "doc",
label: "First steps (cloud)",
id: "getting-started/first-steps",
},
{
type: 'doc',
label: 'Create your cluster',
id: 'workflows/create',
type: "doc",
label: "First steps (local)",
id: "getting-started/first-steps-local",
},
{
type: 'doc',
label: 'Scale your cluster',
id: 'workflows/scale',
type: "doc",
label: "Cloud Marketplaces",
id: "getting-started/marketplaces",
},
{
type: 'doc',
label: 'Upgrade your cluster',
id: 'workflows/upgrade',
type: "category",
label: "Examples",
link: {
type: "doc",
id: "getting-started/examples",
},
items: [
{
type: "doc",
label: "Emojivoto",
id: "getting-started/examples/emojivoto",
},
{
type: "doc",
label: "Online Boutique",
id: "getting-started/examples/online-boutique",
},
{
type: "doc",
label: "Horizontal Pod Autoscaling",
id: "getting-started/examples/horizontal-scaling",
},
{
type: "doc",
label: "Filestash with s3proxy",
id: "getting-started/examples/filestash-s3proxy",
},
],
},
],
},
{
type: "category",
label: "Workflows",
link: {
type: "generated-index",
},
items: [
{
type: "doc",
label: "Verify the CLI",
id: "workflows/verify-cli",
},
{
type: 'doc',
label: 'Expose a service',
id: 'workflows/lb',
type: "doc",
label: "Configure your cluster",
id: "workflows/config",
},
{
type: 'doc',
label: 'Install cert-manager',
id: 'workflows/cert-manager',
type: "doc",
label: "Create your cluster",
id: "workflows/create",
},
{
type: 'doc',
label: 'Install s3proxy',
id: 'workflows/s3proxy',
type: "doc",
label: "Scale your cluster",
id: "workflows/scale",
},
{
type: 'doc',
label: 'Terminate your cluster',
id: 'workflows/terminate',
type: "doc",
label: "Upgrade your cluster",
id: "workflows/upgrade",
},
{
type: 'doc',
label: 'Recover your cluster',
id: 'workflows/recovery',
type: "doc",
label: "Expose a service",
id: "workflows/lb",
},
{
type: 'doc',
label: 'Verify your cluster',
id: 'workflows/verify-cluster',
type: "doc",
label: "Install cert-manager",
id: "workflows/cert-manager",
},
{
type: 'doc',
label: 'Use persistent storage',
id: 'workflows/storage',
type: "doc",
label: "Install s3proxy",
id: "workflows/s3proxy",
},
{
type: 'doc',
label: 'Use the Terraform provider',
id: 'workflows/terraform-provider',
type: "doc",
label: "Terminate your cluster",
id: "workflows/terminate",
},
{
type: "doc",
label: "Recover your cluster",
id: "workflows/recovery",
},
{
type: "doc",
label: "Verify your cluster",
id: "workflows/verify-cluster",
},
{
type: "doc",
label: "Use persistent storage",
id: "workflows/storage",
},
{
type: "doc",
label: "Use the Terraform provider",
id: "workflows/terraform-provider",
},
// {
// type: 'doc',
@ -216,102 +216,155 @@ const sidebars = {
// id: 'workflows/trusted-launch',
// },
{
type: 'doc',
label: 'Consume SBOMs',
id: 'workflows/sbom',
type: "doc",
label: "Consume SBOMs",
id: "workflows/sbom",
},
{
type: 'doc',
label: 'Troubleshooting',
id: 'workflows/troubleshooting',
type: "doc",
label: "Troubleshooting",
id: "workflows/troubleshooting",
},
],
},
{
type: 'category',
label: 'Architecture',
type: "category",
label: "Architecture",
link: {
type: 'generated-index',
type: "generated-index",
},
items: [
{
type: 'doc',
label: 'Overview',
id: 'architecture/overview',
type: "doc",
label: "Overview",
id: "architecture/overview",
},
{
type: 'doc',
label: 'Cluster orchestration',
id: 'architecture/orchestration',
type: "category",
label: "Components",
items: [
{
type: "doc",
label: "CLI",
id: "architecture/components/cli",
},
{
type: "doc",
label: "Microservices",
id: "architecture/components/microservices",
},
{
type: "doc",
label: "Cryptographic keys and primitives",
id: "architecture/components/node-images",
},
],
},
{
type: 'doc',
label: 'Versions and support',
id: 'architecture/versions',
type: "category",
label: "Security",
items: [
{
type: "doc",
label: "Attestation",
id: "architecture/security/attestation",
},
{
type: "doc",
label: "Encrypted networking",
id: "architecture/security/encrypted-networking",
},
{
type: "doc",
label: "Encrypted persistant storage",
id: "architecture/security/encrypted-persistant",
},
],
},
{
type: 'doc',
label: 'Microservices',
id: 'architecture/microservices',
},
{
type: 'doc',
label: 'Attestation',
id: 'architecture/attestation',
},
{
type: 'doc',
label: 'Images',
id: 'architecture/images',
},
{
type: 'doc',
label: 'Keys and cryptographic primitives',
id: 'architecture/keys',
},
{
type: 'doc',
label: 'Encrypted persistent storage',
id: 'architecture/encrypted-storage',
},
{
type: 'doc',
label: 'Networking',
id: 'architecture/networking',
},
{
type: 'doc',
label: 'Observability',
id: 'architecture/observability',
type: "category",
label: "Depricated",
items: [
{
type: "doc",
label: "Key concepts",
id: "architecture/old/key-concepts",
},
{
type: "doc",
label: "Cluster orchestration",
id: "architecture/old/orchestration",
},
{
type: "doc",
label: "Versions and support",
id: "architecture/old/versions",
},
{
type: "doc",
label: "Microservices",
id: "architecture/old/microservices",
},
{
type: "doc",
label: "Attestation",
id: "architecture/old/attestation",
},
{
type: "doc",
label: "Images",
id: "architecture/old/images",
},
{
type: "doc",
label: "Keys and cryptographic primitives",
id: "architecture/old/keys",
},
{
type: "doc",
label: "Encrypted persistent storage",
id: "architecture/old/encrypted-storage",
},
{
type: "doc",
label: "Networking",
id: "architecture/old/networking",
},
{
type: "doc",
label: "Observability",
id: "architecture/old/observability",
},
],
},
],
},
{
type: 'category',
label: 'Reference',
type: "category",
label: "Reference",
link: {
type: 'generated-index',
type: "generated-index",
},
items: [
{
type: 'doc',
label: 'CLI',
id: 'reference/cli',
type: "doc",
label: "CLI",
id: "reference/cli",
},
{
type: 'doc',
label: 'Configuration migrations',
id: 'reference/migration',
type: "doc",
label: "Configuration migrations",
id: "reference/migration",
},
{
type: 'doc',
label: 'Terraform usage',
id: 'reference/terraform',
type: "doc",
label: "Terraform usage",
id: "reference/terraform",
},
{
type: 'doc',
label: 'SLSA adoption',
id: 'reference/slsa',
type: "doc",
label: "SLSA adoption",
id: "reference/slsa",
},
],
},