Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2024-09-07 18:12:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Make SEV-SNP the default attestation variant on GCP (#3267)

Browse Source 
* Make SNP the default on GCP

* fixup! Make SNP

* fixup! Make SNP
This commit is contained in:
Thomas Tendyck 2024-07-22 13:29:27 +02:00 committed by GitHub
parent 4573f10884
commit 399376d3e3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
21 changed files with 72 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.github/actions/terraform_apply/action.yml vendored
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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

6
cli/internal/cmd/init_test.go
View File

@ -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"

28
docs/docs/architecture/attestation.md
View File

@ -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

15
docs/docs/overview/clouds.md
View File

@ -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.

2
docs/docs/reference/cli.md
View File

@ -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

7
docs/versioned_docs/version-2.16/architecture/attestation.md
View File

@ -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

7
docs/versioned_docs/version-2.17/architecture/attestation.md
View File

@ -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

15
docs/versioned_docs/version-2.17/overview/clouds.md
View File

@ -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.

2
internal/attestation/variant/variant.go
View File

@ -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{}},
}

2
internal/config/config.go
View File

@ -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.

4
internal/config/config_doc.go
View File

@ -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 = ""

8
internal/config/config_test.go
View File

@ -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()

2
internal/config/validation.go
View File

@ -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 {

4
terraform-provider-constellation/docs/data-sources/attestation.md
View File

@ -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>

2
terraform-provider-constellation/docs/data-sources/image.md
View File

@ -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.

2
terraform-provider-constellation/docs/resources/cluster.md
View File

@ -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:

2
terraform-provider-constellation/examples/full/gcp/main.tf
View File

@ -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"

2
terraform-provider-constellation/internal/provider/shared_attributes.go
View File

@ -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,