I think the situation is sort of complicated there. There was a deliberate pivot to mobilize the cloud native buzz. A huge plus though, is the validation the underlying design validation which has taken place. I would highly suggest we avoid creating everything from scratch and work to leverage technology which has already had an amount of engineering and validation work in it.
Another huge plus of key lime is a number of folks who have worked on it, are also OpenStack adjacent folks or have had some experience with our community in the past, so building collaboration there will likely be easier. At least, in theory.
-Julia
Hi,
I also stumbled upon Keylime and also have some sad feelings about it (starting at the very very sparse docs). I think it could be really part of the solution, but not sure how integral this part actually is.
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
>>