[tc] [all] [security] Attestation service for confidential VMs: any existing project?
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
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
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
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>
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
wrote: 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
The two current main projects for attestation are Keylime and Trustee. Trustee started more on the k8s side, but both project’s scope expanded and have some overlap, and also try to integrate with one another. JP From: Artem Goncharov <artem.goncharov@gmail.com> Date: Tuesday, January 27, 2026 at 10:48 To: Julia Kreger <juliaashleykreger@gmail.com> Cc: Jean-Philippe Jung <jjung@redhat.com>, <openstack-discuss@lists.openstack.org> Subject: Re: [tc] [all] [security] Attestation service for confidential VMs: any existing project? 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
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>
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
wrote: 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
One other last data point regarding Keylime. Some patches were already posted to Ironic in years past, however the author of the patches to Ironic pivoted their project assignments, and the patches stalled out in Gerrit. It likely wouldn’t be a huge lift to resurrect some of those patches and extend them further for the bare metal management cases. -Julia On Tue, Jan 27, 2026 at 8:00 AM Julia Kreger <juliaashleykreger@gmail.com> 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>
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
wrote: 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
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 >>
nova used to have support for "tursted compute" via openattestation but we had to rip out that integration when the upstream project broke there api and non of the folks that orgianlly worked on it stepped up to maintain it. https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools that was a long time ago but we ahve been brunt by this in the past so an effort to add it a gain woudl proably be held to a pretty high testing standard requireign fully tempest testing if we were to go there again the remvoal happend in 2017 https://review.opendev.org/c/openstack/nova/+/521659 after several years of no one maintaining it. i knwo several folks have been working on confidential computeign enhancement for nova in general so we are not against that but "remote attestation" is not on our project roadmap for the forseable future. local attestation with the vTPM might work but we have never tested that. attestation was not the primnary usecase we had when we added vtpm so that may or may not be supproted by qemus soft-tpm emulation On 27/01/2026 15:43, Julia Kreger 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
participants (5)
-
Artem Goncharov
-
Jean-Philippe Jung
-
JP Jung
-
Julia Kreger
-
Sean Mooney