diff --git a/docs/docs/overview/clouds.md b/docs/docs/overview/clouds.md index 1a6f14a4d..752a87da7 100644 --- a/docs/docs/overview/clouds.md +++ b/docs/docs/overview/clouds.md @@ -25,17 +25,17 @@ The following table summarizes the state of features for different infrastructur ## Microsoft Azure With its [CVM offering](https://docs.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview), Azure provides the best foundations for Constellation. -Regarding (3), Azure provides direct access to remote-attestation statements. +Regarding (3), Azure provides direct access to attestation statements. The firmware runs in an isolated domain inside the CVM and exposes a vTPM (5), but it's closed source (4). On SEV-SNP, Azure uses VM Privilege Level (VMPL) isolation for the separation of firmware and the rest of the VM; on TDX, they use TD partitioning. This firmware is signed by Azure. -The signature is reflected in the remote-attestation statements of CVMs. +The signature is reflected in the attestation statements of CVMs. Thus, the Azure closed-source firmware becomes part of Constellation's trusted computing base (TCB). ## Google Cloud Platform (GCP) The [CVMs Generally Available in GCP](https://cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview#technologies) are based on AMD SEV-ES or SEV-SNP. -Regarding (3), with their SEV-SNP offering Google provides direct access to remote-attestation statements. +Regarding (3), with their SEV-SNP offering Google provides direct access to attestation statements. However, regarding (5), attestation is partially based on the [Shielded VM vTPM](https://cloud.google.com/compute/shielded-vm/docs/shielded-vm#vtpm) for [measured boot](../architecture/attestation.md#measured-boot), which is a vTPM managed by Google's hypervisor. Hence, the hypervisor is currently part of Constellation's TCB. Regarding (4), the CVMs still include closed-source firmware. @@ -46,7 +46,7 @@ With it, Constellation would have a similar TCB and attestation flow as with the ## Amazon Web Services (AWS) Amazon EC2 [supports AMD SEV-SNP](https://aws.amazon.com/de/about-aws/whats-new/2023/04/amazon-ec2-amd-sev-snp/). -Regarding (3), AWS provides direct access to remote-attestation statements. +Regarding (3), AWS provides direct access to attestation statements. However, regarding (5), attestation is partially based on the [NitroTPM](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitrotpm.html) for [measured boot](../architecture/attestation.md#measured-boot), which is a vTPM managed by the Nitro hypervisor. Hence, the hypervisor is currently part of Constellation's TCB. Regarding (4), the [firmware is open source](https://github.com/aws/uefi) and can be reproducibly built. diff --git a/docs/versioned_docs/version-2.16/architecture/attestation.md b/docs/versioned_docs/version-2.16/architecture/attestation.md index bc7ada851..7dbfc9392 100644 --- a/docs/versioned_docs/version-2.16/architecture/attestation.md +++ b/docs/versioned_docs/version-2.16/architecture/attestation.md @@ -342,6 +342,7 @@ The [*VerificationService*](microservices.md#verificationservice) provides an en 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 + This section puts the aforementioned concepts together and illustrate how trust into a Constellation cluster is established and maintained. ### CLI and node images @@ -349,6 +350,7 @@ This section puts the aforementioned concepts together and illustrate how trust 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: + * [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) @@ -357,7 +359,8 @@ The CLI contains the long-term public key of Edgeless Systems to verify the sign ### 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: -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](../architecture/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. @@ -382,7 +385,7 @@ 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 diff --git a/docs/versioned_docs/version-2.17/architecture/attestation.md b/docs/versioned_docs/version-2.17/architecture/attestation.md index bc7ada851..7dbfc9392 100644 --- a/docs/versioned_docs/version-2.17/architecture/attestation.md +++ b/docs/versioned_docs/version-2.17/architecture/attestation.md @@ -342,6 +342,7 @@ The [*VerificationService*](microservices.md#verificationservice) provides an en 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 + This section puts the aforementioned concepts together and illustrate how trust into a Constellation cluster is established and maintained. ### CLI and node images @@ -349,6 +350,7 @@ This section puts the aforementioned concepts together and illustrate how trust 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: + * [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) @@ -357,7 +359,8 @@ The CLI contains the long-term public key of Edgeless Systems to verify the sign ### 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: -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](../architecture/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. @@ -382,7 +385,7 @@ 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 diff --git a/docs/versioned_docs/version-2.17/overview/clouds.md b/docs/versioned_docs/version-2.17/overview/clouds.md index a7b1361e8..752a87da7 100644 --- a/docs/versioned_docs/version-2.17/overview/clouds.md +++ b/docs/versioned_docs/version-2.17/overview/clouds.md @@ -25,29 +25,28 @@ The following table summarizes the state of features for different infrastructur ## Microsoft Azure With its [CVM offering](https://docs.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview), Azure provides the best foundations for Constellation. -Regarding (3), Azure provides direct access to remote-attestation statements. +Regarding (3), Azure provides direct access to attestation statements. The firmware runs in an isolated domain inside the CVM and exposes a vTPM (5), but it's closed source (4). On SEV-SNP, Azure uses VM Privilege Level (VMPL) isolation for the separation of firmware and the rest of the VM; on TDX, they use TD partitioning. This firmware is signed by Azure. -The signature is reflected in the remote-attestation statements of CVMs. +The signature is reflected in the attestation statements of CVMs. Thus, the Azure closed-source firmware becomes part of Constellation's trusted computing base (TCB). ## Google Cloud Platform (GCP) -The [CVMs Generally Available in GCP](https://cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview#amd_sev) are based on AMD SEV but don't have SNP features enabled. -CVMs with [SEV-SNP enabled are in public preview](https://cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview#amd_sev-snp). Regarding (3), with their SEV-SNP offering Google provides direct access to remote-attestation statements. +The [CVMs Generally Available in GCP](https://cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview#technologies) are based on AMD SEV-ES or SEV-SNP. +Regarding (3), with their SEV-SNP offering Google provides direct access to attestation statements. However, regarding (5), attestation is partially based on the [Shielded VM vTPM](https://cloud.google.com/compute/shielded-vm/docs/shielded-vm#vtpm) for [measured boot](../architecture/attestation.md#measured-boot), which is a vTPM managed by Google's hypervisor. Hence, the hypervisor is currently part of Constellation's TCB. Regarding (4), the CVMs still include closed-source firmware. -In the past, Intel and Google have [collaborated](https://cloud.google.com/blog/products/identity-security/rsa-google-intel-confidential-computing-more-secure) to enhance the security of TDX. -Recently, Google has announced a [private preview for TDX](https://cloud.google.com/blog/products/identity-security/confidential-vms-on-intel-cpus-your-datas-new-intelligent-defense?hl=en). -With TDX on Google, Constellation has a similar TCB and attestation flow as with the current SEV-SNP offering. +[TDX on Google](https://cloud.google.com/blog/products/identity-security/confidential-vms-on-intel-cpus-your-datas-new-intelligent-defense) is in public preview. +With it, Constellation would have a similar TCB and attestation flow as with the current SEV-SNP offering. ## Amazon Web Services (AWS) Amazon EC2 [supports AMD SEV-SNP](https://aws.amazon.com/de/about-aws/whats-new/2023/04/amazon-ec2-amd-sev-snp/). -Regarding (3), AWS provides direct access to remote-attestation statements. +Regarding (3), AWS provides direct access to attestation statements. However, regarding (5), attestation is partially based on the [NitroTPM](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitrotpm.html) for [measured boot](../architecture/attestation.md#measured-boot), which is a vTPM managed by the Nitro hypervisor. Hence, the hypervisor is currently part of Constellation's TCB. Regarding (4), the [firmware is open source](https://github.com/aws/uefi) and can be reproducibly built.