Obtain launch measurements
Get the SHA-384 launch digest to pin — from the digest published with an image, by recomputing it with sev-snp-measure, or by reading it off a live attestation report — and work out which c8s flag wants which party's digest.
A measurement is the SHA-384 launch digest of a confidential VM — a hash the TEE hardware
(AMD SEV-SNP or Intel TDX) computes over the exact launch state (firmware, guest kernel, and the
kernel command line, which embeds the dm-verity root hash of the rootfs). Every *measurements
flag in c8s takes one or more of these hex strings. Because a reproducible image always
yields the same digest, pinning it means "accept only this exact, audited image — nothing
else."
Three ways to get the value, best first.
Use the digest published with the image (recommended)
c8s guest images are reproducible and ship their predicted launch digest. The Kata guest
image's digest is published in its manifest.json and pinned via kata.guestImage.tag;
component CVM images publish theirs the same way. Pin the published digest for the exact image
version (tag) you deploy — since the build is reproducible, that value is "exactly this
audited code." This is the production path.
Recompute it with sev-snp-measure
To independently verify the published value (or for a custom image), recompute the expected
digest yourself with AMD's sev-snp-measure from
the launch components — the OVMF firmware, the guest vmlinuz, and the kernel cmdline (which
carries the dm-verity root_hash) — at the same vCPU count used at launch (c8s measures at
1 vCPU for a stable digest):
# illustrative — see the sev-snp-measure docs for the exact flags for your image
sev-snp-measure --mode snp --vcpus 1 \
--ovmf OVMF.fd \
--kernel vmlinuz \
--append "<KERNEL_CMDLINE_INCLUDING_ROOT_HASH>" \
--output-format hexA reproducible build yields the same digest that's in the manifest; a mismatch means the image
isn't what you think it is. (sev-snp-measure is AMD-specific; on Intel TDX the equivalent
launch values — the MRTD and RTMRs — are predicted with TDX's own tooling, but the
pin-the-published-digest workflow above is the same.) To use this as a post-deploy cross-check
— recompute, pin, then verify a live node reports the same digest — see
Independently recompute the measurement.
Read it from a live attestation report (inspect, then pin)
To see what a running component actually measures, read the launch_digest from its evidence:
get-cert --discovery-out discovery.json … writes the attestation evidence and measurement for
the issued certificate, and the attestation-api's verify result returns claims.launch_digest.
Use this to inspect what's running — but in production pin the published or recomputed
value above, not merely whatever a node reports, or you've only achieved trust-on-first-use.
Which flag wants which digest
Each flag wants the digest of a different party:
| Flag | Pin the launch digest of… |
|---|---|
cds.measurements (--measurements) | the workloads and peers allowed to attest to the CDS — and, reused, the inventories the CDS dials for sandbox digests |
ratlsMesh.measurements | the mesh peers allowed to connect |
--cds-measurements (get-cert, ratls-mesh cds mode, policy-monitor) and allowlist.pull.cds_measurements (nri-image-policy) | the CDS itself |
--measurements (c8s allowlist) | the endpoint the CLI connects to — tls-lb on the default public route, or the CDS on a direct URL |
--handoff-measurements (the chart reuses cds.measurements when cds.handoff.enabled) | peer CDS replicas allowed to receive the CA and allowlist |
measurements in c8s-verify | the user-facing LB enclave |
On a Node-as-CVM install, c8s install --measurements <M> fills the first two rows in one
pass — the node image's digest from its manifest.json — so the mesh is pinned from first boot
rather than accept-any-then-tighten. It is rejected with --cvm-mode=pod, where the components
that speak to the CDS are per-pod Kata guests measured separately. A --measurements entry that
is not valid hex fails CDS startup rather than silently unpinning the sandbox callback.
Measurements identify confidential VMs — per-pod CVMs (Pod-as-CVM) or a confidential node (Node-as-CVM). On a non-confidential host, components run as ordinary containers with no launch digest, so pinning only becomes meaningful once the node or pods are actually CVMs.
See also
- Verify a deployment — pin a digest and check a live component against it.
- The trust root — why the CDS refuses to pin by default, and what an unpinned mesh accepts.
- Threat model — why this is mandatory for production.