How can I build end-to-end trust for confidential VMs (AMD SEV-SNP and partly Intel TDX) where secrets are released only after attestation?
Goal:
build end-to-end trust for confidential VMs (AMD SEV-SNP and partly Intel TDX) where secrets are released only after attestation.
Context:
- Private cloud on KVM/QEMU (OpenStack), with some workloads also running in a public cloud as confidential VMs.
- Secrets are stored in HashiCorp Vault. We want the application to receive keys/tokens only after successful remote VM attestation (and ideally also validate the boot/kernel/early init state).
- Problem 1: after host updates (microcode/kernel/QEMU), the set of measurements/parameters starts to “drift”, and the policy becomes either too permissive or everything breaks.
- Problem 2: for some guest images, remote attestation is available sometimes and unavailable other times (depending on the image version). As a result, the same provisioning pipeline produces different outcomes.
Constraints:
- We cannot rely on “trust the cloud/admins” as an assumption.
- We cannot solve this by manually issuing secrets.
- We need a solution that can be expressed as a policy and automated.
Question: how do you implement the chain “boot → attestation report → verification → secret release” in practice so that (a) host updates don’t break everything, (b) guest images don’t turn the process into a lottery, and (c) the policy remains auditable and maintainable?
I’m looking for concrete fields/signals worth pinning in the policy and an approach to versioning that policy.
Answers
Anna Müller
If everything feels like it’s “drifting”, start with a diagnostic cut: you can’t stabilize policy until you know which evidence fields change and why.
Practical sequence:
Log raw evidence and the verification result (signed by whom, which certificate chains, which fields passed/failed). This is needed for policy reproducibility, not just observation.
Classify changes:
changes due to host updates (microcode, hypervisor, firmware);
changes due to the guest (kernel, initramfs, agent);
changes due to launch configuration (parameters, features).
Pick “anchor” fields that must be stable within one policy version:
TEE type/mode;
debug/unsafe indicators;
minimum TCB;
image identity/signature (if you can verify one).
Keep the Policy Manageable:
Everything else is either a lower-bound requirement (minimum versions) or excluded from admission checks, otherwise the system becomes unmanageable.
Katharina Schmidt
Adding to Anna Müller’s diagnostics: it helps to store an explicit “diff” between two successful evidence sets for the same workload before/after a host update. Then you quickly see what actually changes: TCB, signatures, feature bits, microcode identifiers. After that, it’s easier to decide whether a field should be a policy anchor, a lower-bound, or excluded from admission. Without this, people usually try to “guess” the policy and end up with either constant denials or an overly permissive allow.
Markus Becker
Adding what usually matters in real SEV-SNP/TDX pipelines: it’s less about Vault and more about correct evidence interpretation and update discipline.
1. Hard-fail on “unsafe mode” indicators.
If the attestation report exposes debug/unsafe/minimal-protection flags, treat them as hard failures. Otherwise you can get “attestation pass” while your threat model is no longer valid.
2. Host updates: don’t chase hashes, enforce patch levels.
After CPU/hypervisor patches, the risk profile changes. If your policy is TCB >= X and
hypervisor/microcode not below Y, you avoid breaking on every measurement change while keeping control.
In practice: maintain a matrix CVE → minimum microcode/kernel/QEMU versions → platform-policy version.
3. “Guest images shouldn’t be a lottery.”
The stable approach is to maintain your own catalog of “signed” (or at least version-pinned) images where you know:
which attestation drivers/agents are present;
how the image obtains evidence (which agent);
how you derive measurements (if you do).
If an external image doesn’t guarantee remote attestation support for a specific version, it does not meet the requirements for
critical secret release.
4. Side channels and default VM isolation.
There have been repeated cases where “VM isolation” needs additional host mitigations (for example, protections around branch predictors
on VMEXIT). That affects what you consider a sufficient platform-policy. If you ignore those updates,
“confidential” becomes “slightly better than normal”, not what the workload expects.
Stefan Fischer
+1 to Markus Becker on lower bounds and the “CVE → minimum versions” matrix. We initially tried pinning “exact measurements” and got constant false denials after microcode updates. We switched to:
After that, host updates stopped breaking secret release, but dropping below required patch levels blocks access predictably (policy fail due to “below minimum”), not randomly due to mismatched measurements.
Julia Wagner
If the requirement is “secrets only after attestation” and you want updates not to break secret release every time, the most practical approach is to split the policy into two layers and version them independently.
Split policy into “platform” and “workload”.
Don’t try to pin everything that changes during host updates.
A common mistake is stuffing the policy with values that inevitably change with microcode/hypervisor updates.
That leads to either constant breakage or a policy that “allows everything”, which is equivalent to disabling control.
Instead, pin a minimally sufficient set of signals and use “lower bounds” (minimum TCB/microcode/host versions)
rather than exact values, if your threat model allows it.
Policy versioning.
In Vault, mark secrets with requirements like platform-policy >= N and workload-policy == M
(or allowlist M1…Mk), so secrets are not released to “random” images.
The “guest image lottery” can only be solved with an allowlist and an image contract.
If some images don’t reliably support remote attestation, that’s not a “minor inconvenience”; it’s a trust-chain defect.
Your policy should treat those images as ineligible for high-sensitivity secrets. In practice: separate image classes,
separate Vault roles, different privileges.
Jonas Weber
I implemented separate platform-policy and workload-policy as Julia Wagner suggested. The “lottery” cause became obvious: some failing deployments used Ubuntu 25.04, and on that image our agent could not obtain a valid attestation report (logs: “feature not supported / remote attestation unavailable”). On Ubuntu 24.04 LTS the same pipeline succeeds.
Conclusion: we do need an image allowlist and separate Vault roles. Otherwise it’s not a “drifting policy” but “drifting image support”, which the policy should correctly block.