[ops][nova][ironic] Attestation interest or tooling?
Greetings Operators, During the next PTG, Nova[0] and Ironic[1] are expected to have some attestation discussions. Of course, attestation means different things when you’re talking about a compute node or a bare metal as a service node. Different use cases and models! Obviously, it’s not the early 2010s when original discussions of attestation started to stir. The regulatory landscape is shifting in ways which reinforces the need for improving the verification of the lower levels of the hardware and OS runtime. In order to really beneficial discussions, the community could really use some operator insights as it relates to Attestation! - What Attestation tools are you using? How much are you measuring? Just PCR0-7, or more including critical OS/file contents? - If you have a mandate or need, but are not quite there, what are you considering doing? - What would be preferred responses should a node’s measurement be identified by an attestation service as failing measurement? - How much information do operators think they need OpenStack services to surface as it relates to making informed decisions with attestation state? If we can get some thoughts from operators to the list, it would be most beneficial and ensure teams have increased context going into discussions. If all else fails, please feel free to join us during the PTG[2]! -Julia [0]: https://etherpad.opendev.org/p/nova-2026.2-ptg [1]: https://etherpad.opendev.org/p/ironic-ptg-2026.2 <https://etherpad.opendev.org/p/ironic-ptg-2026.2#L260> [2]: https://etherpad.opendev.org/p/nova-2026.2-ptg
On 16/04/2026 14:43, Julia Kreger wrote:
Greetings Operators,
During the next PTG, Nova[0] and Ironic[1] are expected to have some attestation discussions. Of course, attestation means different things when you’re talking about a compute node or a bare metal as a service node. or for a vm booted on a compute node taht the usecase that was prviously targeted in nova. attestation of vms booted on compute nodes. i dont quite recall if it requried the host to also be atested but yes it means a lot of thing to a lot of diffent folks i know the kata comunctiy were also looking at how can attestation be extended to thing like gpu as well.
Different use cases and models!
Obviously, it’s not the early 2010s when original discussions of attestation started to stir. The regulatory landscape is shifting in ways which reinforces the need for improving the verification of the lower levels of the hardware and OS runtime.
nova actually implemented support for it then the openstastatoin project changed ther apis which broke it and it took a few year to remove it agian so if we are to reopen this topic i very much wnat to make sure aht we have a plan to test it on or normal testing runtimes in the first party ci wiht a devstack plugin to deploy an opensouce attestation server that is well maintained and stable so that we do not repate the same mistakes we had in the past. i don't have any option on what tools beyond, opensource, easy to deploy in our ci (with devstack) and well maintained and vendor neutral/standard compliment if that is a thing in this space for some definition of all of the above.
In order to really beneficial discussions, the community could really use some operator insights as it relates to Attestation!
- What Attestation tools are you using? How much are you measuring? Just PCR0-7, or more including critical OS/file contents? - If you have a mandate or need, but are not quite there, what are you considering doing? - What would be preferred responses should a node’s measurement be identified by an attestation service as failing measurement? - How much information do operators think they need OpenStack services to surface as it relates to making informed decisions with attestation state?
If we can get some thoughts from operators to the list, it would be most beneficial and ensure teams have increased context going into discussions. If all else fails, please feel free to join us during the PTG[2]!
-Julia
[0]: https://etherpad.opendev.org/p/nova-2026.2-ptg [1]: https://etherpad.opendev.org/p/ironic-ptg-2026.2 <https://etherpad.opendev.org/p/ironic-ptg-2026.2#L260> [2]: https://etherpad.opendev.org/p/nova-2026.2-ptg
On Thu, Apr 16, 2026 at 7:18 AM Sean Mooney <smooney@redhat.com> wrote:
On 16/04/2026 14:43, Julia Kreger wrote:
Greetings Operators,
During the next PTG, Nova[0] and Ironic[1] are expected to have some attestation discussions. Of course, attestation means different things when you’re talking about a compute node or a bare metal as a service node. or for a vm booted on a compute node taht the usecase that was prviously targeted in nova. attestation of vms booted on compute nodes. i dont quite recall if it requried the host to also be atested but yes it means a lot of thing to a lot of diffent folks i know the kata comunctiy were also looking at how can attestation be extended to thing like gpu as well.
Most likely through PCR2 or PRC7 might do it, but if your changing values it could be problematic in runtime. Ultimately all going to depend on how its wired up and if the TPM can reach into the card at all. I do want to clarify. I'm not focused on measurement of the workloads/instances, but ideally you do want to measure hypervisors if you're measuring workloads. Building assurance in depth of controls. That being said, workloads are also workloads and tenants may have entirely different needs. I think the key for hypervisors is about having traits which exist, for an instance to be able to scheduled on to only "attested" nodes. Ideally, that also means we might want to have a default trait removal on service startup and expect $something to manage adding such back. Should be a fun discussion!
Different use cases and models!
Obviously, it’s not the early 2010s when original discussions of attestation started to stir. The regulatory landscape is shifting in ways which reinforces the need for improving the verification of the lower levels of the hardware and OS runtime.
nova actually implemented support for it then the openstastatoin project changed ther apis which broke it and it took a few year to remove it agian
Yeah, I think OpenAttestation never really got good traction and now their own github says: go look at trustvc.io. I think a key is going to be "keep things lightweight" and simple, but maybe someone has something fully baked we could all discuss. The only way to find out is to have that discussion. :) I know some vendors ship Keylime, and I'm rather interested in that due to pre-existing adjacency/engagement with OpenStack, but we really all need more data points if possible.
so if we are to reopen this topic i very much wnat to make sure aht we have a plan to test it on or normal testing runtimes in the first party ci wiht a devstack plugin to deploy an opensouce attestation server that is well maintained and stable so that we do not repate the same mistakes we had in the past.
I'm super hesitant of even going that far because of the complexity. Do we have vtpms is a whole other headache. But, it all depends on what the community reaches as consensus.
i don't have any option on what tools beyond, opensource, easy to deploy in our ci (with devstack) and well maintained and vendor neutral/standard compliment if that is a thing in this space for some definition of all of the above.
In order to really beneficial discussions, the community could really use some operator insights as it relates to Attestation!
- What Attestation tools are you using? How much are you measuring? Just PCR0-7, or more including critical OS/file contents? - If you have a mandate or need, but are not quite there, what are you considering doing? - What would be preferred responses should a node’s measurement be identified by an attestation service as failing measurement? - How much information do operators think they need OpenStack services to surface as it relates to making informed decisions with attestation state?
If we can get some thoughts from operators to the list, it would be most beneficial and ensure teams have increased context going into discussions. If all else fails, please feel free to join us during the PTG[2]!
-Julia
[0]: https://etherpad.opendev.org/p/nova-2026.2-ptg [1]: https://etherpad.opendev.org/p/ironic-ptg-2026.2 <https://etherpad.opendev.org/p/ironic-ptg-2026.2#L260> [2]: https://etherpad.opendev.org/p/nova-2026.2-ptg
participants (2)
-
Julia Kreger
-
Sean Mooney