Confidential computing working-group agenda
18 views
Skip to first unread message
Aseef Imran
Mar 3, 2026, 7:33:24 AMMar 3
to Vladik Romanovsky, kubevirt-dev, Stefano Garzarella, Javier Cano Cano, Itamar Holder, German Maglione, Roman Mohry, Matias Ezequiel Vara Larsen, Mikko Ylinen, Zhenchao Liu
Hi everyone,
The next Confidential Computing WG meeting is scheduled for Tuesday, March 10⋅11:00am – 12:00pm EST on the KubeVirt calendar, however it is currently marked as "tentatively cancelled".
Now that in https://github.com/kubevirt/kubevirt/pull/15958 the PR adding attestation for TDX is merged, I was hoping to discuss and converge on some remaining questions as we head into the beta phase for TDX. I don't know if the meeting is marked as cancelled because we do not have any discussion topics, but if so, there are a few matters I was hoping to discuss. Discussing them over the mailing list is also acceptable to me.
These open questions are formalized in https://github.com/kubevirt/enhancements/pull/220/changes. Just for your convenience, I am copying and pasting these open questions from this PRs below:
- Decide whether to keep the `confidentialCompute.tdx.attestion.qgsSocketPath`
configuration option to custom QGS path locations or to remove it in favor of
a default location (i.e. `/var/run/tdx-qgs/qgs.socket`).
- Decide whether to enforce the existance of QGS on the KubeVirt side (i.e use
of the `confidentialCompute.tdx.attestation.enforced` field) and if so whether
it makes sense to extend these enforcements to support per-VMI enforcements (as
opposed to only cluster-wide).
In addition to this, the following design-level consideration should also be
revisited:
- Decide whether TDX detection should be removed from node-labeller (since the
device plugin already achieves this purpose) or whether it should be kept for
either consistency with SEV-SNP or for user-friendliness.
Finally, we must revisit whether to assume that KubeVirt will have exclusive
access to the TDX or if we want to support the use case of non-KubeVirt components
launching TDX VMs. Answering this question will impact the following topics:
- The TDX device counting mechanism as at the moment it assumes that KubeVirt will
have exclusive access to the TDX hardware.
- Permission configuration for the QGS socket is currently the cluster-admin's
responsibility. We should revisit the permission model for the QGS socket and
decide whose responsibility permission configuration should be and whether
KubeVirt can assume that it has exclusive access to the socket.
configuration option to custom QGS path locations or to remove it in favor of
a default location (i.e. `/var/run/tdx-qgs/qgs.socket`).
- Decide whether to enforce the existance of QGS on the KubeVirt side (i.e use
of the `confidentialCompute.tdx.attestation.enforced` field) and if so whether
it makes sense to extend these enforcements to support per-VMI enforcements (as
opposed to only cluster-wide).
In addition to this, the following design-level consideration should also be
revisited:
- Decide whether TDX detection should be removed from node-labeller (since the
device plugin already achieves this purpose) or whether it should be kept for
either consistency with SEV-SNP or for user-friendliness.
Finally, we must revisit whether to assume that KubeVirt will have exclusive
access to the TDX or if we want to support the use case of non-KubeVirt components
launching TDX VMs. Answering this question will impact the following topics:
- The TDX device counting mechanism as at the moment it assumes that KubeVirt will
have exclusive access to the TDX hardware.
- Permission configuration for the QGS socket is currently the cluster-admin's
responsibility. We should revisit the permission model for the QGS socket and
decide whose responsibility permission configuration should be and whether
KubeVirt can assume that it has exclusive access to the socket.
I'm hoping to converge on a definitive answer to these questions in order to get a more clear direction for Beta after which we hope to minimize any additional API changes. Thanks for reading.
[P.S. if I missed CCing anyone please feel free to CC them as well]
Best regards,
Aseef
Matias Ezequiel Vara Larsen
Mar 4, 2026, 1:34:55 PMMar 4
to Aseef Imran, Vladik Romanovsky, kubevirt-dev, Stefano Garzarella, Javier Cano Cano, Itamar Holder, German Maglione, Roman Mohry, Mikko Ylinen, Zhenchao Liu
Hello Aseef,
On Tue, Mar 3, 2026 at 1:33 PM Aseef Imran <aim...@redhat.com> wrote:
>
> Hi everyone,
>
> The next Confidential Computing WG meeting is scheduled for Tuesday, March 10⋅11:00am – 12:00pm EST on the KubeVirt calendar, however it is currently marked as "tentatively cancelled".
>
> Now that in https://github.com/kubevirt/kubevirt/pull/15958 the PR adding attestation for TDX is merged, I was hoping to discuss and converge on some remaining questions as we head into the beta phase for TDX. I don't know if the meeting is marked as cancelled because we do not have any discussion topics, but if so, there are a few matters I was hoping to discuss. Discussing them over the mailing list is also acceptable to me.
>
Thanks for all the work you did to get that merged!
> These open questions are formalized in https://github.com/kubevirt/enhancements/pull/220/changes. Just for your convenience, I am copying and pasting these open questions from this PRs below:
> - Decide whether to keep the `confidentialCompute.tdx.attestion.qgsSocketPath`
> configuration option to custom QGS path locations or to remove it in favor of
> a default location (i.e. `/var/run/tdx-qgs/qgs.socket`).
> - Decide whether to enforce the existance of QGS on the KubeVirt side (i.e use
> of the `confidentialCompute.tdx.attestation.enforced` field) and if so whether
> it makes sense to extend these enforcements to support per-VMI enforcements (as
> opposed to only cluster-wide).
I have a feeling that we will figure out these open questions after
people start using it and complain. For example, if most people are
using the default location, we can remove it as a parameter. I think
this is also true for the enforced field.
Matias.
On Tue, Mar 3, 2026 at 1:33 PM Aseef Imran <aim...@redhat.com> wrote:
>
> Hi everyone,
>
> The next Confidential Computing WG meeting is scheduled for Tuesday, March 10⋅11:00am – 12:00pm EST on the KubeVirt calendar, however it is currently marked as "tentatively cancelled".
>
> Now that in https://github.com/kubevirt/kubevirt/pull/15958 the PR adding attestation for TDX is merged, I was hoping to discuss and converge on some remaining questions as we head into the beta phase for TDX. I don't know if the meeting is marked as cancelled because we do not have any discussion topics, but if so, there are a few matters I was hoping to discuss. Discussing them over the mailing list is also acceptable to me.
>
> These open questions are formalized in https://github.com/kubevirt/enhancements/pull/220/changes. Just for your convenience, I am copying and pasting these open questions from this PRs below:
> - Decide whether to keep the `confidentialCompute.tdx.attestion.qgsSocketPath`
> configuration option to custom QGS path locations or to remove it in favor of
> a default location (i.e. `/var/run/tdx-qgs/qgs.socket`).
> - Decide whether to enforce the existance of QGS on the KubeVirt side (i.e use
> of the `confidentialCompute.tdx.attestation.enforced` field) and if so whether
> it makes sense to extend these enforcements to support per-VMI enforcements (as
> opposed to only cluster-wide).
people start using it and complain. For example, if most people are
using the default location, we can remove it as a parameter. I think
this is also true for the enforced field.
Matias.
Andrew Burden
Mar 5, 2026, 9:29:20 AMMar 5
to Matias Ezequiel Vara Larsen, Aseef Imran, Vladik Romanovsky, kubevirt-dev, Stefano Garzarella, Javier Cano Cano, Itamar Holder, German Maglione, Roman Mohry, Mikko Ylinen, Zhenchao Liu
Hi all,
Just to answer part of this: The next CoCo meeting is marked as tentatively cancelled because it coincides with the KubeVirt v1.9 unconference. Last time we cancelled it but I wanted to leave the entry there just in case something like this arose.
Just to answer part of this: The next CoCo meeting is marked as tentatively cancelled because it coincides with the KubeVirt v1.9 unconference. Last time we cancelled it but I wanted to leave the entry there just in case something like this arose.
If there are topics folks wish to discuss:
1. We can run a session as part of the unconference to cover it. You can put the session topic on the unconference notepad to be voted on.
2. We can run the CoCo meeting regardless at the regular time; just be aware that core KubeVirt members will likely be at the unconference.
2. We can run the CoCo meeting regardless at the regular time; just be aware that core KubeVirt members will likely be at the unconference.
Cheers,
Andrew
--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CAHYGQ0zpfTO9WVhnS97t09CC%2BmenQCE%2BMjahqYRWPCmaxWgkQA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages