--- title: Extend zero trust workload identity manager to virtual... description: Containers on Red Hat OpenShift can receive automatic cryptographic identities via the zero trust workload identity manager, but VM workloads cannot — because... canonical: https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Extend zero trust workload identity manager to virtual machines with Red Hat OpenShift Virtualization | daily.dev og:description: Containers on Red Hat OpenShift can receive automatic cryptographic identities via the zero trust workload identity manager, but VM workloads cannot — because... og:url: https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr og:image: https://api.daily.dev/og/posts/GOZhe2Tfr.png og:image:alt: Extend zero trust workload identity manager to virtual machines with Red Hat OpenShift Virtualization og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Extend zero trust workload identity manager to virtual machines with Red Hat OpenShift Virtualization **[Red Hat Developer](https://daily.dev/sources/rhdev)** · 10 min read · 0 upvotes · 0 comments ## Summary Containers on Red Hat OpenShift can receive automatic cryptographic identities via the zero trust workload identity manager, but VM workloads cannot — because Unix domain sockets can't be shared into a guest OS. This tutorial bridges that gap using VSOCK (a kernel-level VM-to-host communication channel) combined with a dedicated in-VM SPIRE agent. The SPIRE agent inside the VM connects to the cluster's SPIRE server through a socat-based VSOCK-to-TCP tunnel, enabling per-process SPIFFE identity issuance using Unix UID-based workload attestation. Redis and PostgreSQL running inside a RHEL 9 VM each receive unique, short-lived X.509 SVIDs (120s and 180s TTL respectively) that rotate automatically. The tutorial covers enabling VSOCK feature gates on OpenShift, deploying the host-side bridge pod, configuring the in-VM SPIRE agent, attesting the agent with a join token, and registering workloads. Production considerations include replacing join_token attestation with x509pop, automating registration via spire-controller-manager, and managing bridges with systemd and Ansible. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why can't a SPIRE agent on the host issue SVID identities to workloads running inside a KubeVirt VM? A SPIRE agent on the host cannot reach inside the VM guest OS because the Unix socket it exposes exists only in the host kernel's filesystem. Even though the VM runs inside a virt-launcher pod, the guest OS has its own kernel, filesystem, and process table. The virt-launcher pod itself can receive an identity, but individual processes inside the VM cannot be attested from outside. _Teams running mixed OpenShift workloads track zero-trust identity patterns like this on daily.dev._ ### Why use VSOCK instead of TCP to connect an in-VM SPIRE agent to the SPIRE server on OpenShift? VSOCK is invisible to IP routing, port scanning, and network-based attacks, making it more secure than TCP over the pod network. Each VM gets a unique context ID (CID), preventing VMs from snooping on each other. A TCP connection over the cluster's virtual network would be visible to anything on that network, creating interception and spoofing opportunities that VSOCK eliminates entirely. _Developers hardening VM-to-host communication channels find relevant security architecture discussions on daily.dev._ ### How do I give individual applications inside a KubeVirt VM separate SPIFFE identities using SPIRE? Run a dedicated SPIRE agent inside the VM configured with the Unix WorkloadAttestor plugin. Register each application with a selector based on its Unix UID — for example, Redis at UID 994 and PostgreSQL at UID 26. The agent verifies caller UID via SO_PEERCRED on the Unix socket, which cannot be spoofed by userspace, and issues each process its own X.509 SVID with a distinct SPIFFE ID. _Engineers building per-workload identity policies across containers and VMs follow this space on daily.dev._ ## Similar posts on daily.dev - [Zero trust observability: Integrating OpenTelemetry with workload identity manager](https://daily.dev/posts/zero-trust-observability-integrating-opentelemetry-with-workload-identity-manager-vk50fxrme) · Red Hat Developer · 0 upvotes · 0 comments - [Federated identity across the hybrid cloud using zero trust workload identity manager](https://daily.dev/posts/federated-identity-across-the-hybrid-cloud-using-zero-trust-workload-identity-manager-bulq9b2ok) · Red Hat Developer · 0 upvotes · 0 comments - [The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE](https://daily.dev/posts/the-machine-with-many-faces-post-exploitation-identity-misuse-in-spiffe-spire-yl2muroxy) · Unit 42 · 0 upvotes · 0 comments - [How to Implement Zero-Trust Workload Identity in Kubernetes with SPIFFE, SPIRE, and Cilium](https://daily.dev/posts/how-to-implement-zero-trust-workload-identity-in-kubernetes-with-spiffe-spire-and-cilium-8lgssuaqb) · freeCodeCamp · 2 upvotes · 0 comments - [Integrate zero trust workload identity manager with Red Hat OpenShift GitOps](https://daily.dev/posts/integrate-zero-trust-workload-identity-manager-with-red-hat-openshift-gitops-ff1b862my) · Red Hat Developer · 0 upvotes · 0 comments --- [View this post on daily.dev](https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Extend zero trust workload identity manager to virtual machines with Red Hat OpenShift Virtualization","url":"https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr"},"datePublished":"2026-08-12T03:04:48.405Z","dateModified":"2026-08-12T03:05:23.638Z","description":"Containers on Red Hat OpenShift can receive automatic cryptographic identities via the zero trust workload identity manager, but VM workloads cannot — because...","image":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","thumbnailUrl":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","isAccessibleForFree":true,"articleSection":"Red Hat Developer","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Red Hat Developer","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/2a8895f3216c4900bdc455585a4ad3e4","url":"https://daily.dev/sources/rhdev"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Red Hat Developer","item":"https://daily.dev/sources/rhdev"},{"@type":"ListItem","position":3,"name":"Extend zero trust workload identity manager to virtual machines with Red Hat OpenShift Virtualization"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/extend-zero-trust-workload-identity-manager-to-virtual-machines-with-red-hat-openshift-virtualizatio-gozhe2tfr#faq","mainEntity":[{"@type":"Question","name":"Why can't a SPIRE agent on the host issue SVID identities to workloads running inside a KubeVirt VM?","acceptedAnswer":{"@type":"Answer","text":"A SPIRE agent on the host cannot reach inside the VM guest OS because the Unix socket it exposes exists only in the host kernel's filesystem. Even though the VM runs inside a virt-launcher pod, the guest OS has its own kernel, filesystem, and process table. The virt-launcher pod itself can receive an identity, but individual processes inside the VM cannot be attested from outside. Teams running mixed OpenShift workloads track zero-trust identity patterns like this on daily.dev."}},{"@type":"Question","name":"Why use VSOCK instead of TCP to connect an in-VM SPIRE agent to the SPIRE server on OpenShift?","acceptedAnswer":{"@type":"Answer","text":"VSOCK is invisible to IP routing, port scanning, and network-based attacks, making it more secure than TCP over the pod network. Each VM gets a unique context ID (CID), preventing VMs from snooping on each other. A TCP connection over the cluster's virtual network would be visible to anything on that network, creating interception and spoofing opportunities that VSOCK eliminates entirely. Developers hardening VM-to-host communication channels find relevant security architecture discussions on daily.dev."}},{"@type":"Question","name":"How do I give individual applications inside a KubeVirt VM separate SPIFFE identities using SPIRE?","acceptedAnswer":{"@type":"Answer","text":"Run a dedicated SPIRE agent inside the VM configured with the Unix WorkloadAttestor plugin. Register each application with a selector based on its Unix UID — for example, Redis at UID 994 and PostgreSQL at UID 26. The agent verifies caller UID via SO_PEERCRED on the Unix socket, which cannot be spoofed by userspace, and issues each process its own X.509 SVID with a distinct SPIFFE ID. Engineers building per-workload identity policies across containers and VMs follow this space on daily.dev."}}]} ```