im not familar with keylime but the previous work was to supprot Openattestation https://wiki.openstack.org/wiki/OpenAttestation https://github.com/OpenAttestation/OpenAttestation which became https://github.com/Open-Attestation/open-attestation which is also now defunct as of october the suggested https://github.com/trustvc/trustvc as the replacement bu ti agree we should not try to build an attestation service in openstack and shoudl instead try an intergate with an exsting one if this effort is revived. keylime being a cncf project may also be a benifit esplically if its already establised in teh k8s comunity there also appare to be 2 diffent level of attestation at play first attestation of the physical host where a server is used as a hypervior the second is attestation inside the guests server instace whtere that is a vm in the case fo libvirt or a physical server in the case of ironic in the former case the attestation serrver woudl be part of the dataceneter netwrok fabic and woudl be manged by the cloud admin for there onw usecases in the second case teh attestation server may be deploy by the end user so that they can verify the attestation ectra. the tenant enabled usecase has a diffent trust domain and intergration flow. which of the two cases are you most interested in? i assume the former based on VMs in the title. but im not sure what would be reuqired of nova to confiure qemu/libvirt to enable attestation fo the vms. is the intent to allow a bring your own model for the attestation server or is the expectation that that is provide by the cloud operator. the problem with the latter apprcoh is if you didnt trust your CSP to begin with attesting to a server they provide does not help with that trust. On 27/01/2026 16:00, Julia Kreger wrote:
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
On Tue, Jan 27, 2026 at 7:48 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:
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.
Artem
On Tue, 27 Jan 2026 at 16:44, Julia Kreger <juliaashleykreger@gmail.com> wrote:
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 >>