diff --git a/.github/actions/terraform_apply/action.yml b/.github/actions/terraform_apply/action.yml index 5340dae5b..885950ac9 100644 --- a/.github/actions/terraform_apply/action.yml +++ b/.github/actions/terraform_apply/action.yml @@ -26,10 +26,9 @@ runs: "gcpSEVES") attestationVariant="gcp-sev-es" ;; - # TODO(msanft): Enable once stable GCP SEV-SNP images exist. - # "gcpSEVSNP") - # attestationVariant="gcp-sev-snp" - # ;; + "gcpSEVSNP") + attestationVariant="gcp-sev-snp" + ;; *) echo "Unknown attestation variant: $(yq '.attestation | keys | .[0]' constellation-conf.yaml)" exit 1 diff --git a/.github/workflows/e2e-test-daily.yml b/.github/workflows/e2e-test-daily.yml index 97d8afce9..55e9ccb1f 100644 --- a/.github/workflows/e2e-test-daily.yml +++ b/.github/workflows/e2e-test-daily.yml @@ -49,12 +49,6 @@ jobs: attestationVariant: ["gcp-sev-es", "gcp-sev-snp", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] refStream: ["ref/main/stream/debug/?", "ref/release/stream/stable/?"] test: ["sonobuoy quick"] - exclude: - # TODO(v2.18 msanft): Remove exclude rule for GCP SEV-SNP stable once images exist. - - kubernetesVersion: "1.28" - attestationVariant: "gcp-sev-snp" - refStream: "ref/release/stream/stable/?" - test: "sonobuoy quick" runs-on: ubuntu-22.04 permissions: id-token: write diff --git a/.github/workflows/e2e-test-release.yml b/.github/workflows/e2e-test-release.yml index 778c6c4e9..8f8f8a7e4 100644 --- a/.github/workflows/e2e-test-release.yml +++ b/.github/workflows/e2e-test-release.yml @@ -404,7 +404,7 @@ jobs: max-parallel: 1 matrix: fromVersion: ["v2.17.0"] - attestationVariant: ["gcp-sev-es", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] + attestationVariant: ["gcp-sev-snp", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] name: Run upgrade tests secrets: inherit permissions: diff --git a/.github/workflows/e2e-test-weekly.yml b/.github/workflows/e2e-test-weekly.yml index b56a104d0..42b351a8b 100644 --- a/.github/workflows/e2e-test-weekly.yml +++ b/.github/workflows/e2e-test-weekly.yml @@ -413,7 +413,7 @@ jobs: max-parallel: 1 matrix: fromVersion: ["v2.17.0"] - attestationVariant: ["gcp-sev-es", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] + attestationVariant: ["gcp-sev-snp", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] name: Run upgrade tests secrets: inherit permissions: @@ -491,7 +491,7 @@ jobs: strategy: fail-fast: false matrix: - attestationVariant: ["gcp-sev-es", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] + attestationVariant: ["gcp-sev-snp", "azure-sev-snp", "azure-tdx", "aws-sev-snp"] permissions: id-token: write contents: read diff --git a/cli/internal/cmd/init_test.go b/cli/internal/cmd/init_test.go index ad2a95be5..ccad3eb30 100644 --- a/cli/internal/cmd/init_test.go +++ b/cli/internal/cmd/init_test.go @@ -535,9 +535,9 @@ func defaultConfigWithExpectedMeasurements(t *testing.T, conf *config.Config, cs conf.Provider.GCP.Project = "test-project" conf.Provider.GCP.Zone = "test-zone" conf.Provider.GCP.ServiceAccountKeyPath = "test-key-path" - conf.Attestation.GCPSEVES.Measurements[4] = measurements.WithAllBytes(0x44, measurements.Enforce, measurements.PCRMeasurementLength) - conf.Attestation.GCPSEVES.Measurements[9] = measurements.WithAllBytes(0x11, measurements.Enforce, measurements.PCRMeasurementLength) - conf.Attestation.GCPSEVES.Measurements[12] = measurements.WithAllBytes(0xcc, measurements.Enforce, measurements.PCRMeasurementLength) + conf.Attestation.GCPSEVSNP.Measurements[4] = measurements.WithAllBytes(0x44, measurements.Enforce, measurements.PCRMeasurementLength) + conf.Attestation.GCPSEVSNP.Measurements[9] = measurements.WithAllBytes(0x11, measurements.Enforce, measurements.PCRMeasurementLength) + conf.Attestation.GCPSEVSNP.Measurements[12] = measurements.WithAllBytes(0xcc, measurements.Enforce, measurements.PCRMeasurementLength) zone = "europe-west3-b" instanceType = "n2d-standard-4" diskType = "pd-ssd" diff --git a/docs/docs/architecture/attestation.md b/docs/docs/architecture/attestation.md index bc7ada851..8f12b5851 100644 --- a/docs/docs/architecture/attestation.md +++ b/docs/docs/architecture/attestation.md @@ -305,9 +305,24 @@ You may customize certain parameters for verification of the attestation stateme -On GCP, AMD SEV-ES is used to provide runtime encryption to the VMs. -The hypervisor-based vTPM is used to establish trust in the VM via [runtime measurements](#runtime-measurements). -There is no additional configuration available for GCP. +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 + + 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 + + This certificate is the root of trust for verifying the SEV-SNP certificate chain. + +* 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. @@ -342,6 +357,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 +365,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 +374,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 +400,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/docs/overview/clouds.md b/docs/docs/overview/clouds.md index a7b1361e8..752a87da7 100644 --- a/docs/docs/overview/clouds.md +++ b/docs/docs/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. diff --git a/docs/docs/reference/cli.md b/docs/docs/reference/cli.md index a728474e7..6a911034e 100644 --- a/docs/docs/reference/cli.md +++ b/docs/docs/reference/cli.md @@ -78,7 +78,7 @@ constellation config generate {aws|azure|gcp|openstack|qemu|stackit} [flags] ### Options ``` - -a, --attestation string attestation variant to use {aws-sev-snp|aws-nitro-tpm|azure-sev-snp|azure-tdx|azure-trustedlaunch|gcp-sev-es|gcp-sev-snp|qemu-vtpm}. If not specified, the default for the cloud provider is used + -a, --attestation string attestation variant to use {aws-sev-snp|aws-nitro-tpm|azure-sev-snp|azure-tdx|azure-trustedlaunch|gcp-sev-snp|gcp-sev-es|qemu-vtpm}. If not specified, the default for the cloud provider is used -h, --help help for generate -k, --kubernetes string Kubernetes version to use in format MAJOR.MINOR (default "v1.29") -t, --tags strings additional tags for created resources given a list of key=value 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. diff --git a/internal/attestation/variant/variant.go b/internal/attestation/variant/variant.go index e71a51480..abe70fcaf 100644 --- a/internal/attestation/variant/variant.go +++ b/internal/attestation/variant/variant.go @@ -55,7 +55,7 @@ const ( var providerAttestationMapping = map[cloudprovider.Provider][]Variant{ cloudprovider.AWS: {AWSSEVSNP{}, AWSNitroTPM{}}, cloudprovider.Azure: {AzureSEVSNP{}, AzureTDX{}, AzureTrustedLaunch{}}, - cloudprovider.GCP: {GCPSEVES{}, GCPSEVSNP{}}, + cloudprovider.GCP: {GCPSEVSNP{}, GCPSEVES{}}, cloudprovider.QEMU: {QEMUVTPM{}}, cloudprovider.OpenStack: {QEMUVTPM{}}, } diff --git a/internal/config/config.go b/internal/config/config.go index b6533022b..5aefb05b3 100644 --- a/internal/config/config.go +++ b/internal/config/config.go @@ -281,7 +281,7 @@ type AttestationConfig struct { // GCP SEV-ES attestation. GCPSEVES *GCPSEVES `yaml:"gcpSEVES,omitempty" validate:"omitempty"` // description: | - // GCP SEV-SNP attestation. + // GCP SEV-SNP attestation. GCPSEVSNP *GCPSEVSNP `yaml:"gcpSEVSNP,omitempty" validate:"omitempty"` // description: | // QEMU tdx attestation. diff --git a/internal/config/config_doc.go b/internal/config/config_doc.go index cdca2733f..d26af1643 100644 --- a/internal/config/config_doc.go +++ b/internal/config/config_doc.go @@ -428,8 +428,8 @@ func init() { AttestationConfigDoc.Fields[6].Name = "gcpSEVSNP" AttestationConfigDoc.Fields[6].Type = "GCPSEVSNP" AttestationConfigDoc.Fields[6].Note = "" - AttestationConfigDoc.Fields[6].Description = "description: |\n GCP SEV-SNP attestation.\n" - AttestationConfigDoc.Fields[6].Comments[encoder.LineComment] = "description: |" + AttestationConfigDoc.Fields[6].Description = "GCP SEV-SNP attestation." + AttestationConfigDoc.Fields[6].Comments[encoder.LineComment] = "GCP SEV-SNP attestation." AttestationConfigDoc.Fields[7].Name = "qemuTDX" AttestationConfigDoc.Fields[7].Type = "QEMUTDX" AttestationConfigDoc.Fields[7].Note = "" diff --git a/internal/config/config_test.go b/internal/config/config_test.go index 5278136ac..c18e5d835 100644 --- a/internal/config/config_test.go +++ b/internal/config/config_test.go @@ -466,7 +466,7 @@ func TestValidate(t *testing.T) { gcp.ServiceAccountKeyPath = "test-key-path" cnf.Provider = ProviderConfig{} cnf.Provider.GCP = gcp - cnf.Attestation.GCPSEVES.Measurements = measurements.M{ + cnf.Attestation.GCPSEVSNP.Measurements = measurements.M{ 0: measurements.WithAllBytes(0x00, measurements.Enforce, measurements.PCRMeasurementLength), } cnf.NodeGroups = map[string]NodeGroup{ @@ -624,11 +624,11 @@ func TestConfig_UpdateMeasurements(t *testing.T) { { // GCP conf := Default() conf.RemoveProviderAndAttestationExcept(cloudprovider.GCP) - for k := range conf.Attestation.GCPSEVES.Measurements { - delete(conf.Attestation.GCPSEVES.Measurements, k) + for k := range conf.Attestation.GCPSEVSNP.Measurements { + delete(conf.Attestation.GCPSEVSNP.Measurements, k) } conf.UpdateMeasurements(newMeasurements) - assert.Equal(newMeasurements, conf.Attestation.GCPSEVES.Measurements) + assert.Equal(newMeasurements, conf.Attestation.GCPSEVSNP.Measurements) } { // QEMU conf := Default() diff --git a/internal/config/validation.go b/internal/config/validation.go index fab69ff29..4ea1576b2 100644 --- a/internal/config/validation.go +++ b/internal/config/validation.go @@ -250,7 +250,7 @@ func translateNoAttestationError(ut ut.Translator, fe validator.FieldError) stri } func registerNoAttestationError(ut ut.Translator) error { - return ut.Add("no_attestation", "{0}: No attestation has been defined (requires either awsSEVSNP, awsNitroTPM, azureSEVSNP, azureTDX, azureTrustedLaunch, gcpSEVES, or qemuVTPM)", true) + return ut.Add("no_attestation", "{0}: No attestation has been defined (requires either awsSEVSNP, awsNitroTPM, azureSEVSNP, azureTDX, azureTrustedLaunch, gcpSEVES, gcpSEVSNP, or qemuVTPM)", true) } func translateNoDefaultControlPlaneGroupError(ut ut.Translator, fe validator.FieldError) string { diff --git a/terraform-provider-constellation/docs/data-sources/attestation.md b/terraform-provider-constellation/docs/data-sources/attestation.md index b1b8891c0..ede4dc189 100644 --- a/terraform-provider-constellation/docs/data-sources/attestation.md +++ b/terraform-provider-constellation/docs/data-sources/attestation.md @@ -32,8 +32,8 @@ data "constellation_attestation" "test" { * `aws-nitro-tpm` * `azure-sev-snp` * `azure-tdx` - * `gcp-sev-es` * `gcp-sev-snp` + * `gcp-sev-es` * `qemu-vtpm` - `csp` (String) CSP (Cloud Service Provider) to use. (e.g. `azure`) See the [full list of CSPs](https://docs.edgeless.systems/constellation/overview/clouds) that Constellation supports. @@ -83,8 +83,8 @@ Read-Only: * `aws-nitro-tpm` * `azure-sev-snp` * `azure-tdx` - * `gcp-sev-es` * `gcp-sev-snp` + * `gcp-sev-es` * `qemu-vtpm` diff --git a/terraform-provider-constellation/docs/data-sources/image.md b/terraform-provider-constellation/docs/data-sources/image.md index f0b37455a..7933e93fc 100644 --- a/terraform-provider-constellation/docs/data-sources/image.md +++ b/terraform-provider-constellation/docs/data-sources/image.md @@ -31,8 +31,8 @@ data "constellation_image" "example" { * `aws-nitro-tpm` * `azure-sev-snp` * `azure-tdx` - * `gcp-sev-es` * `gcp-sev-snp` + * `gcp-sev-es` * `qemu-vtpm` - `csp` (String) CSP (Cloud Service Provider) to use. (e.g. `azure`) See the [full list of CSPs](https://docs.edgeless.systems/constellation/overview/clouds) that Constellation supports. diff --git a/terraform-provider-constellation/docs/resources/cluster.md b/terraform-provider-constellation/docs/resources/cluster.md index d62f8aa4b..2e03b2c0e 100644 --- a/terraform-provider-constellation/docs/resources/cluster.md +++ b/terraform-provider-constellation/docs/resources/cluster.md @@ -110,8 +110,8 @@ Required: * `aws-nitro-tpm` * `azure-sev-snp` * `azure-tdx` - * `gcp-sev-es` * `gcp-sev-snp` + * `gcp-sev-es` * `qemu-vtpm` Optional: diff --git a/terraform-provider-constellation/examples/full/gcp/main.tf b/terraform-provider-constellation/examples/full/gcp/main.tf index 12913be67..a6c2d09ab 100644 --- a/terraform-provider-constellation/examples/full/gcp/main.tf +++ b/terraform-provider-constellation/examples/full/gcp/main.tf @@ -17,7 +17,7 @@ locals { kubernetes_version = "vX.Y.Z" microservice_version = "vX.Y.Z" csp = "gcp" - attestation_variant = "gcp-sev-es" + attestation_variant = "gcp-sev-snp" region = "europe-west3" zone = "europe-west3-b" project_id = "constellation-331613" diff --git a/terraform-provider-constellation/internal/provider/shared_attributes.go b/terraform-provider-constellation/internal/provider/shared_attributes.go index 0a8c6a72d..e1cc4e1dd 100644 --- a/terraform-provider-constellation/internal/provider/shared_attributes.go +++ b/terraform-provider-constellation/internal/provider/shared_attributes.go @@ -31,8 +31,8 @@ func newAttestationVariantAttributeSchema(t attributeType) schema.Attribute { " * `aws-nitro-tpm`\n" + " * `azure-sev-snp`\n" + " * `azure-tdx`\n" + - " * `gcp-sev-es`\n" + " * `gcp-sev-snp`\n" + + " * `gcp-sev-es`\n" + " * `qemu-vtpm`\n", Required: isInput, Computed: !isInput,