Gain stronger pod isolation on Microsoft Azure Red Hat OpenShift with OpenShift sandboxed containers

If you are running containerized workloads on Red Hat OpenShift, then you already benefit from industry-leading process isolation. Security context constraints (SCC) restrict what pods can do, SELinux enforces mandatory access controls, cgroups limit resource consumption, and many permissive Linux capabilities are dropped by default. That said, all of these controls still operate on a shared host kernel. For the majority of workloads, this is perfectly fine. But when you are running untrusted code especially with privileged containers, you can use OpenShift sandboxed containers for an additional layer of assurance.

What are OpenShift sandboxed containers?

Available on Microsoft Azure Red Hat OpenShift, OpenShift sandboxed containers give you hypervisor-backed workload isolation, where each pod runs inside its own lightweight virtual machine (VM) with a dedicated kernel, layered on top of the already included OpenShift security controls.

In this post, we provide an overview on what OpenShift sandboxed containers do, how it works on Microsoft Azure, and when you should consider adopting it for your workloads.

What does "sandboxed" mean for your containers?

In a traditional container setup, your workloads all share the host's Linux kernel. Think of it as choosing a hostel or a hotel. In a hostel, one person's bad behavior can affect the whole room. With OpenShift sandboxed containers, each sandboxed pod gets its own dedicated kernel inside a lightweight VM, which is more like having your own hotel room with solid walls. You still reside in the same building and share the lobby, but what happens inside each room is completely contained.

OpenShift sandboxed containers are built on Kata Containers, an open source project that runs each pod inside its own lightweight VM. If a workload is compromised, the blast radius is confined to that transient VM (which has almost no other software installed), rather than spreading to the host or neighboring pods. In effect, you get the simplicity of containers with the isolation guarantees of virtual machines.

In figure 1, you can see a conceptual representation of the difference between a regular pod and a pod utilizing OpenShift sandboxed containers.

Figure 1: In a standard configuration, workloads share a host's kernel. With OpenShift sandboxed containers, pods run in a lightweight VM, isolated from other processes.

When should you use sandboxed containers?

OpenShift and Red Hat Enterprise Linux (RHEL) already provide significant security protections for containerized workloads. For the majority of workloads, these controls are sufficient. Where OpenShift sandboxed containers adds value is in situations where you may be required to run untrusted code.

For example, if you are developing with new or unfamiliar libraries, or running untrusted code that you have not been able to fully inspect or patch, then OpenShift sandboxed containers lets you do so without risking the host or neighboring workloads. The same applies to privileged containers requiring elevated capabilities on a shared kernel. Additionally, AI and agent workloads present a growing case for sandboxing, because they may generate and execute unreviewed code at runtime, follow non-deterministic execution paths, or be susceptible to prompt injection attacks.

What does this mean for your existing Microsoft Azure Red Hat OpenShift security posture?

Microsoft Azure Red Hat OpenShift supports OpenShift sandboxed containers, which means you can adopt VM-level pod isolation today without having to build or manage the isolation infrastructure yourself. The OpenShift sandboxed containers operator handles installation, configuration, and lifecycle management. It is deployed using the standard operator framework, configures the runtime using CRI-O handlers, and sets up the appropriate RuntimeClass, all managed declaratively through a KataConfig custom resource.

Importantly, this VM-level isolation does not replace the security controls that OpenShift and RHEL already provide. Instead, it layers on top. All of the OpenShift and RHEL security controls, such as SCCs, SELinux, cgroups, and so on, continue to apply exactly as before. The VM boundary acts as an additional containment layer beneath these existing controls, and your operational patterns all continue to work the same way.

Along with this, resource containment gets stronger. A sandboxed pod cannot consume more CPU or memory than its VM is allocated, and it can only access devices explicitly passed through to it. An errant container can not reach beyond its VM boundary to grab additional host resources or interfere with other pods on the node. 

Naturally, this raises the question of whether every pod should be sandboxed. Since each sandboxed pod runs in its own VM, this leads to unnecessary resource utilization and is best left for workloads where stronger isolation is genuinely needed.  

Get started

To get started with OpenShift sandboxed containers on Microsoft Azure Red Hat OpenShift, install the OpenShift sandboxed containers operator from OperatorHub in your Microsoft Azure Red Hat OpenShift cluster. Create a KataConfig custom resource and configure the runtime, and then add runtimeClassName to the pod spec of any workload you want to isolate. That's it! The operator takes care of provisioning the peer pod VMs through the Microsoft Azure API and managing their lifecycle.

Find out more

Microsoft Azure Red Hat OpenShift supports OpenShift sandboxed containers, meaning you can adopt VM-level pod isolation today without having to build or manage the infrastructure yourself. We've worked to make this as simplified as possible where a managed operator handles the lifecycle, a single line in your pod spec enables isolation, and your existing OpenShift tools and workflows continue to work exactly as they do now.

With an increasingly hostile threat landscape, further accelerated by AI, organizations are strengthening controls across the software supply chain and looking for stronger workload isolation. VM-level isolation addresses this need, and with OpenShift sandboxed containers on Microsoft Azure Red Hat OpenShift, you can adopt it on a managed platform that's ready to go. If you're running untrusted, privileged, or multi-tenant workloads on Microsoft Azure Red Hat OpenShift, then we encourage you to try it out.

Here are some resources to help you get started:

• Deploying OpenShift Sandboxed Containers on Microsoft Azure
• The Dawn of OpenShift Sandboxed Containers: Overview
• Red Hat OpenShift sandboxed containers: Peer-pods solution overview