Super Swarm

Super Swarm is a cloud whose compute nodes are confidential VMs. This page covers only what you need in order to reason about the router; it is not the Swarm documentation.

A cloud

A Swarm cloud is a set of confidential VMs running a Kubernetes distribution, addressed through one gateway. Workloads deploy into a cluster space inside it. Each cloud has its own certificate authority, and that authority runs inside a confidential VM of its own.

That last point is what makes the chain close. The authority's X.509 certificate carries the hardware evidence of the VM that holds it: the attestation report, the report's commitment to the certificate's own public key, and the launch measurement of the image it booted. A verifier that has never seen this cloud before can therefore decide whether to trust its certificate authority from the hardware up, rather than from a certificate someone pasted.

What a deployment publishes

Every deployment publishes a signed document at https://<its hostname>/.well-known/swarm-evidence, served by the platform gateway. It contains:

• the certificate chain, ending at that cloud's attested authority;
• a JSON Web Signature over a snapshot of the deployment: every container image by digest, and the configuration they run with;
• the fingerprint of the TLS certificate that hostname serves;
• an issuedAt timestamp, re-signed every few minutes.

The SHA-256 of the canonical snapshot is the evidence digest: the identity of one deployment, as deployed. Change an image or a parameter and the digest changes.

What is rendered is what is attested. A deployment is produced from a definition of the application and the parameters chosen when it is deployed, and that rendered result is what the snapshot covers. There is no step where a human adds something afterwards that the evidence does not mention.

The measurement registry

A launch measurement identifies an image, but on its own it does not say whose image it is. Super Protocol publishes signatures over the measurements of the VM images it builds, in the public sp-vm repository. A verifier rebuilds the measurement from the published build artefacts, checks that it reproduces what the hardware signed, and then checks that Super Protocol signed that value.

The signing key is pinned inside the verifier rather than fetched, so the registry location can move without weakening the check. A measurement the registry has never signed is not a failure of the hardware report: it is what a local or test build looks like, and Test or unsigned builds covers that case.

Where the boundary is

The confidentiality boundary is the cluster space, not an individual process. Inside one deployment, components talk to each other over the cluster network in the clear, and that is sound precisely because the whole space is inside the environment and the whole space is covered by one snapshot. Between deployments, nothing is implied: a separate deployment is a separate boundary with its own evidence, even on the same cloud.

Who cannot read what runs inside: the cloud operator, the host operating system, other tenants, and Super Protocol.

Next: the router as a Swarm application.