Security work is different from most computing in one big way. You need environments you can trust completely, use once, and delete without a trace.
A malware analyst running a sample needs an environment the sample cannot escape from, either to the host or to other workloads. When the analysis is done, that environment has to be gone, with no leftover state that could carry contamination into the next job. Stopping it or archiving it does not cut it.
A vulnerability researcher probing a target network needs an isolated workspace with specific tools, specific network access rules, and a way to tear the whole thing down when the engagement ends. Then they need to stand the same environment back up for the next engagement without dragging along anything from the last one.
A red team running an internal exercise needs target environments that behave like production, enough of them to run real scenarios, and total isolation from actual production.
Every one of these needs fast, cheap, disposable, isolated environments, and lots of them. Here is how we build that on Kubernetes with KubeVirt.
Why VMs instead of containers
Containers share a kernel with the host. For most workloads that is fine. For security work with malware, exploits, or deliberately vulnerable software, a shared kernel is a real risk. A clever sample can try a kernel escape. A misconfigured container can expose host resources. The isolation is softer than it looks.
VMs isolate more strongly. The guest kernel is separate from the host kernel, so a kernel exploit in the guest does not touch the host. The VM sees virtualized hardware, and there is no shared kernel to escape through.
KubeVirt lets you run VMs as Kubernetes workloads. You get VM-level isolation with the things Kubernetes is good at: fast provisioning, declarative config, automatic cleanup, resource limits, and network policies. A VM becomes as easy to spin up and tear down as a container, with much stronger isolation.
You stop thinking of a VM as a server you maintain and start thinking of it like any other workload you launch and throw away.
Malware analysis
A malware analysis environment has specific needs. It needs a full OS install, often Windows, because most malware targets Windows. It needs network isolation so the analysis VM cannot reach the real network. It needs snapshots so you can get back to a clean state fast. And it needs to be destroyed completely when the analysis is over.
With KubeVirt on Orion, an analyst opens the Orion Workspace catalog and clicks the malware analysis environment card. Orion provisions a Windows VM with the analysis tools already installed, network policies that block all external traffic except the logging endpoint, and a snapshot of the clean state stored in Longhorn.
The analyst runs the sample. When they are done, they write the report, save any artifacts they need to the secure output storage, and terminate the VM. The VM disk is deleted and the resources go back to the pool. The next analyst gets a fresh VM from the same template.
If the sample causes trouble mid-analysis, the analyst can roll back to the clean snapshot in under a minute. There is nothing to rebuild and no fresh install to wait on.
Vulnerability research
A vulnerability researcher running a bug bounty program or a security assessment needs controlled network access to specific targets, cut off from everything else on the infrastructure.
The Kubernetes network policy layer handles this precisely. Each research workspace is a namespace with its own network policies. For example, the researcher’s VM and its supporting tool containers can reach the listed target IPs and ports and nothing else on the internal network. If the assessment ends or the scope changes, the network policies update right away.
Several researchers can work at the same time on different targets in separate namespaces with completely separate network policies. One researcher’s workspace cannot reach another researcher’s targets, so the network layer rules out cross-contamination between engagements.
Each engagement’s storage is scoped to its namespace. Evidence, tool configs, and notes live in that namespace’s storage. When the engagement closes, the namespace is deleted and the storage goes with it. Nothing carries into the next engagement.
Red team exercises
Red team exercises need realistic targets. You cannot run a realistic exercise against production. You need a copy that behaves like production and is completely cut off from it.
KubeVirt lets you run a fleet of VMs that mirror your production environment, with the same OS versions, the same application stack, and the same network layout, all inside an isolated namespace with no connection to real production systems.
For an exercise with twenty target systems, Orion provisions twenty VMs from the right templates in under five minutes. The red team gets realistic targets. The blue team gets realistic activity to detect and respond to. When the exercise ends, the whole VM fleet shuts down and nothing carries over.
The AI agent layer adds automated red team activity that looks like a real attacker. An agent with a set of security tools can be set up to probe targets, try privilege escalation, and generate activity the blue team has to tell apart from automated noise. The blue team gets to practice against real volume and variety without red team staff generating every action by hand.
SOC analysts
Security operations center analysts lose a lot of time switching between tools: SIEM dashboards, threat intelligence feeds, packet captures, and sandboxes for suspicious files. Each tool is its own system, often with its own login, its own context, and its own tribal knowledge.
Orion’s workload catalog can put all of those tools in one place. An analyst opens their catalog and sees a SIEM dashboard, a threat intel workspace, a packet analysis environment, and a malware sandbox. They launch what the current investigation needs. When they close the investigation, they terminate the workloads.
AI agents can speed up triage. An agent connected to the SIEM can watch alert queues, sort alerts by severity and type, pull the relevant threat intelligence for each one, and hand the highest-priority items to a human analyst with the context already gathered. The analyst spends their time on decisions instead of data gathering.
What this takes to set up
The foundation is KubeVirt on a Kubernetes cluster with Orion running the workload layer. Orion already ships KubeVirt VM support. The security-specific setup is mostly network policies, storage scoping, and preparing VM templates.
The VM templates are where the real investment goes. Good templates for malware analysis, research workspaces, and realistic target environments take time to get right, and they pay off on every use after that. Orion’s template system lets you version and update them without disturbing workloads that are already running.
If you are looking at this architecture, start with one use case and one template. Prove the workflow, then expand. Once the infrastructure is in place, the pattern carries over to the next use case.
See how Orion handles security operations workloads. Get a Demo
Anthony Genova is a product engineer at Juno Innovations, building the automation stack and agent frameworks that run on top of Orion.
WRITTEN BY
Anthony Genova
Anthony Genova builds the things that make Orion work. As a product engineer at Juno Innovations, he has spent years writing the automation stack, agent frameworks, and infrastructure tooling that run on top of Kubernetes so researchers, developers, and creative teams do not have to think about what is underneath. Before Juno, he worked across software engineering and systems integration. He writes about agentic systems, workload automation, and the infrastructure patterns that make AI actually useful in production.