mirror of
https://github.com/edgelesssys/constellation.git
synced 2024-09-07 18:12:01 +00:00
Make SEV-SNP the default attestation variant on GCP (#3267)
* Make SNP the default on GCP * fixup! Make SNP * fixup! Make SNP
This commit is contained in:
parent
4573f10884
commit
399376d3e3
7
.github/actions/terraform_apply/action.yml
vendored
7
.github/actions/terraform_apply/action.yml
vendored
@ -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
|
||||
|
6
.github/workflows/e2e-test-daily.yml
vendored
6
.github/workflows/e2e-test-daily.yml
vendored
@ -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
|
||||
|
2
.github/workflows/e2e-test-release.yml
vendored
2
.github/workflows/e2e-test-release.yml
vendored
@ -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:
|
||||
|
4
.github/workflows/e2e-test-weekly.yml
vendored
4
.github/workflows/e2e-test-weekly.yml
vendored
@ -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
|
||||
|
@ -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"
|
||||
|
@ -305,9 +305,24 @@ You may customize certain parameters for verification of the attestation stateme
|
||||
</tabItem>
|
||||
<tabItem value="gcp" label="GCP">
|
||||
|
||||
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.
|
||||
|
||||
</tabItem>
|
||||
<tabItem value="stackit" label="STACKIT">
|
||||
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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{}},
|
||||
}
|
||||
|
@ -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.
|
||||
|
@ -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 = ""
|
||||
|
@ -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()
|
||||
|
@ -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 {
|
||||
|
@ -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`
|
||||
|
||||
<a id="nestedatt--attestation--azure_firmware_signer_config"></a>
|
||||
|
@ -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.
|
||||
|
@ -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:
|
||||
|
@ -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"
|
||||
|
@ -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,
|
||||
|
Loading…
Reference in New Issue
Block a user