Greetings folks,

One project I have engaged with in the past, and sort of saddened it
didn't get more traction in the OpenStack community is Keylime. I
think the big missing piece is some means or mechanism to tie
OpenStack's view of instances able to be cross-referenced. Overall
there is a ton of security research and work which went into Keylime,
and I believe an integration path is one which would be most
beneficial and the fastest path to market.

-Julia

On Tue, Jan 27, 2026 at 7:33 AM Artem Goncharov
<artem.goncharov@gmail.com> wrote:
>
> Hi JP,
>
> As usual we are on the same wave. Some weeks ago I started digging into the same area. So far I have not found anything ready and therefore started some research and it seems that we have some cornerstones already supported by the platform. I believe it would be possible to build up a service like that based on the vTPM (https://docs.openstack.org/nova/latest/admin/emulated-tpm.html), SPIRE and most likely an additional custom component for the integration. Actually I was thinking about the problem from the next step point of view - how to provide the Keystone API key into the VM and thus came to the very same problem statement.
>
> Maybe somebody has already built a solution for the attestation. Otherwise it makes sense to start thinking deeper on that.
>
> Regards,
> Artem
>
> On Mon, 26 Jan 2026 at 22:04, Jean-Philippe Jung <jjung@redhat.com> wrote:
>>
>> Hi,
>>
>> As the work progresses for the support of confidential VMs on OpenStack (support for AMD SEV-SNP, Intel TDX, Arm CCA), is there any current effort/project to look at the key missing piece for Confidential Computing: Attestation.
>>
>> Attestation provides cryptographic proof that your code is actually running inside a genuine Trusted Execution Environment (TEE), not just someone claiming it is.
>>
>> Without attestation, confidential computing is meaningless—you'd be trusting the cloud provider's word that your data is protected, which defeats the entire purpose. Attestation generates a signed report from the hardware itself, containing measurements of the code, the TEE's identity, and proof the CPU is legitimate.
>>
>> This lets you verify before sending sensitive data that: the hardware is real, the enclave code hasn't been tampered with, and the environment matches your expectations. It's trust anchored in silicon, not promises.
>>
>> The Attestation service would have connections to at least to compute and storage, as the attestation service would be the final approver to release a VM decryption key after verifying that the hardware stack is unmodified and suitable to run an encrypted VM.
>>
>> Thank you,
>>
>> JP Jung
>>