Feedback requested: VEP 222 - VSOCK network namespace confinement

[Felix Matouschek]

Hi all,

I'd like to get your feedback on a new proposal: VEP 222: VSOCK network namespace confinement.

This VEP proposes confining VSOCKs to network namespaces (local mode) to improve isolation. Based on early PR review, I am considering dropping the legacy, unisolated global mode entirely.

I'd love your input on this direction. Specifically, I want to know if dropping global mode would cause issues for existing use cases or environments. I am also looking for general feedback on the overall design and any edge cases or specific workloads I should keep in mind.

Please share your thoughts on the PR or in this thread.

Thanks,
Felix

[Roman Mohr]

Hi Felix,

On Wed, Mar 11, 2026 at 7:39 AM 'Felix Matouschek' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hi all,

I'd like to get your feedback on a new proposal: VEP 222: VSOCK network namespace confinement.

This VEP proposes confining VSOCKs to network namespaces (local mode) to improve isolation. Based on early PR review, I am considering dropping the legacy, unisolated global mode entirely.

I'd love your input on this direction. Specifically, I want to know if dropping global mode would cause issues for existing use cases or environments. I am also looking for general feedback on the overall design and any edge cases or specific workloads I should keep in mind.

Thank you for this email. This would cause us trouble. We have existing use-cases. While we don't use it for inter-vm communication (so appreciate the final outcome of the local namespace isolation), there is not a good way for a guest to know if the CA service is not there because a malicious attacker tries to emulate newer kubevirt, or if we run a new enough kubevirt version. The guest has no insight if local namespaces are used, so I would appreciate not just dropping it and phasing it out like root vs non-root VMs.

Best regards,

Roman

 

Please share your thoughts on the PR or in this thread.

Thanks,
Felix

--
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/cc306080-97aa-4b6f-9ad7-498a1e5d9265n%40googlegroups.com.

[Fox, Kevin M]

I've been playing round with vsock to export always up to date credentials from spire into the vm so it can join its own spire agent. I think this would break it. I'm open to alternatives though.

Thanks,
Kevin

________________________________________
From: 'Roman Mohr' via kubevirt-dev <kubevi...@googlegroups.com>
Sent: Wednesday, March 11, 2026 9:37 AM
To: Felix Matouschek
Cc: kubevirt-dev
Subject: Re: [kubevirt-dev] Feedback requested: VEP 222 - VSOCK network namespace confinement

Check twice before you click! This email originated from outside PNNL.

Hi Felix,

On Wed, Mar 11, 2026 at 7:39 AM 'Felix Matouschek' via kubevirt-dev <kubevi...@googlegroups.com<mailto:kubevi...@googlegroups.com>> wrote:
Hi all,

I'd like to get your feedback on a new proposal: VEP 222: VSOCK network namespace confinement.

This VEP proposes confining VSOCKs to network namespaces (local mode) to improve isolation. Based on early PR review, I am considering dropping the legacy, unisolated global mode entirely.

I'd love your input on this direction. Specifically, I want to know if dropping global mode would cause issues for existing use cases or environments. I am also looking for general feedback on the overall design and any edge cases or specific workloads I should keep in mind.

Thank you for this email. This would cause us trouble. We have existing use-cases. While we don't use it for inter-vm communication (so appreciate the final outcome of the local namespace isolation), there is not a good way for a guest to know if the CA service is not there because a malicious attacker tries to emulate newer kubevirt, or if we run a new enough kubevirt version. The guest has no insight if local namespaces are used, so I would appreciate not just dropping it and phasing it out like root vs non-root VMs.

Best regards,
Roman



Please share your thoughts on the PR or in this thread.

Thanks,
Felix

--
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<mailto:kubevirt-dev...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/cc306080-97aa-4b6f-9ad7-498a1e5d9265n%40googlegroups.com<https://groups.google.com/d/msgid/kubevirt-dev/cc306080-97aa-4b6f-9ad7-498a1e5d9265n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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<mailto:kubevirt-dev...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CA%2BNAZzxgotwWNxrhzmD8sZjDcFfCouwxMy4ZWFDcqnobJHc4dQ%40mail.gmail.com<https://groups.google.com/d/msgid/kubevirt-dev/CA%2BNAZzxgotwWNxrhzmD8sZjDcFfCouwxMy4ZWFDcqnobJHc4dQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Felix Matouschek]

Hi Roman,

On Wednesday, March 11, 2026 at 5:37:27 PM UTC+1 Roman Mohr wrote:

Hi Felix,

On Wed, Mar 11, 2026 at 7:39 AM 'Felix Matouschek' via kubevirt-dev <kubevi...@googlegroups.com> wrote:

Hi all,

I'd like to get your feedback on a new proposal: VEP 222: VSOCK network namespace confinement.

This VEP proposes confining VSOCKs to network namespaces (local mode) to improve isolation. Based on early PR review, I am considering dropping the legacy, unisolated global mode entirely.

I'd love your input on this direction. Specifically, I want to know if dropping global mode would cause issues for existing use cases or environments. I am also looking for general feedback on the overall design and any edge cases or specific workloads I should keep in mind.

Thank you for this email. This would cause us trouble. We have existing use-cases. While we don't use it for inter-vm communication (so appreciate the final outcome of the local namespace isolation), there is not a good way for a guest to know if the CA service is not there because a malicious attacker tries to emulate newer kubevirt, or if we run a new enough kubevirt version. The guest has no insight if local namespaces are used, so I would appreciate not just dropping it and phasing it out like root vs non-root VMs.

Also answered this on the PR:

You mean by leaving the global CA service intact and keeping support for both modes global and local, so that existing VMs with the global mode can still access the CA service, while VMs with local mode will not be able to do so anymore?

 

Thanks,

Felix

[Felix Matouschek]

On Wednesday, March 11, 2026 at 6:06:03 PM UTC+1 Fox, Kevin M wrote:

I've been playing round with vsock to export always up to date credentials from spire into the vm so it can join its own spire agent. I think this would break it. I'm open to alternatives though.

Thanks,
Kevin

Would you be able to use a Secret injected as a Volume via virtiofs instead?