Incorrect docs: verifying third-party clusters with CLI

[cdata]

Issue description

The docs found at https://docs.edgeless.systems/constellation/workflows/verify-cluster#custom-arguments claim that any cluster can be verified with two pieces of information: the IP of the VerificationService and the cluster's clusterID. However, this is not true; the CLI gives the following error:

Error: loading config file: unable to find constellation-conf.yaml - use `constellation config generate` to generate it first

As an aside: we would like to enable third-parties to perform a verification step against our cluster. Is it feasible to do this, and if so how should we do it?

Steps to reproduce the behavior

1. Set up a cluster and make the VerificationService visible on the network
2. In a separate workspace, run constellation verify -e $THE_SERVICE_IP --cluster-id $THE_CLUSTER_ID

Version

Version: v2.16.4 (Enterprise build; see documentation for license agreement) GitCommit: 9603dcd09e96475a7378cc4ec7b0126a2d0a5ed5 GitTreeState: clean BuildDate: 2024-05-14T13:30:56 GoVersion: go1.22.3 X:nocoverageredesign Compiler: bazel/gc Platform: linux/amd6

Constellation Config

N/A

[daniel-weisse]

the CLI gives the following error

constellation verify requires a config file to obtain the measurements and configuration to verify the cluster with, as described in the featch measurements section at the start of the page. There is actually a bug in the CLI however, which requires you to also have a correctly initialized constellation-state.yaml file in your working directory. This should not be necessary when setting the --endpoint and --cluster-id flags I'll update the docs to reflect this also in the "custom arguments" section and fix the relevant code section.

we would like to enable third-parties to perform a verification step against our cluster. Is it feasible to do this, and if so how should we do it?

You first need to establish with what goal the third party is verifying your cluster. Since Constellation does not lock out the operator of the cluster (you), the operator is essentially free to do anything to an existing and initialized cluster. This means the third party has to trust you first and foremost when connecting to the cluster. If this is not given, any additional verification of the cluster through the Constellation CLI or services is essentially meaningless.

If this trust is given, but the third party wants to go the extra mile, they can use constellation verify. It is also possible to directly interact with the REST or gRPC endpoints of the VerificationService to obtain attestation statements. Though this is not documented and we do not currently offer a public API for this.

[cdata]

Thank you for the prompt response and action on this issue @daniel-weisse !

If this trust is given, but the third party wants to go the extra mile, they can use constellation verify.

At this stage we are evaluating the product so it is satisfying to us to hypothesize that this is the trust scenario.

It is also possible to directly interact with the REST or gRPC endpoints of the VerificationService to obtain attestation statements.

In time we hope to experiment with this path for verification, under the hypothetical scenario that our own verification tool is sufficiently trusted to warrant it.

Though this is not documented and we do not currently offer a public API for this.

Thank you for clarifying this point. Can you comment on the stability of the current REST / gRPC endpoints?

[daniel-weisse]

We have not committed ourselves to any API stability beyond stable upgrade paths from one minor version to the next, which is also why the endpoints aren't documented on our docs website and we haven't published any SDKs for this. But since the VerificationService is a rather simple application, the response structure of gRPC and REST endpoint are unlikely to change (both just return byte strings). What may however change without notice is the data encoded inside the response. (for example, parts of it will change with the next minor release)

Since the response of the VerificationService contains a lot more information than just an AMD SEV-SNP or Intel TDX quote, if the only goal of your third party is to verify they are running inside a confidential VM, you may find it easier to write your own small application, which issues and attests a SEV-SNP or TDX quote using the go-sev-guest or go-tdx-guest libraries, which we also use in our code base.

I would again like to emphasize that the verify command mostly serves an illustrative purpose, and your third party won't get any meaningful security out of using it to verify your cluster, since they already have to trust you, the operator, to mess with their applications. At which point they might as well trust you that the cluster is running in a confidential VM.