OpenShift sandboxed containers, read on the node.
OpenShift sandboxed containers is the productised release of the Kata Containers runtime on Red Hat OpenShift Container Platform. The runtime installs through a cluster operator and runs sandboxed workloads inside lightweight virtual machines on bare metal worker nodes that meet the hardware virtualization requirement. The entitlement reads through the OpenShift platform line on the worker nodes that host the sandboxed workloads, and the audit posture turns on whether the dedicated sandboxed node pool is sized to the actual isolation requirement rather than provisioned defensively. The buyer side discipline reads sandboxed containers as a node pool scope decision, not as a cluster wide product.
Kata Containers as an operator, on a dedicated node pool.
Red Hat OpenShift sandboxed containers is the productised release of the Kata Containers runtime on Red Hat OpenShift Container Platform. The runtime installs through a cluster operator that targets a labelled node pool meeting the hardware virtualization requirement, and the sandboxed workloads run inside lightweight virtual machines on those nodes rather than as conventional container processes on the worker kernel1. The isolation model is the product. The performance overhead is the trade.
The reading in 2026 is that OpenShift sandboxed containers is included as a value added operator inside Red Hat OpenShift Container Platform on the clusters where it runs2. The platform line on the cluster cores absorbs the sandboxed runtime attribution, with no separate per sandboxed workload charge. The cluster cores carry the line whether the sandboxed runtime hosts ten workloads or three hundred.
The structural distinction that matters at the renewal table is the node pool. Sandboxed containers does not run on every worker node by default. The runtime requires bare metal worker nodes or specific hyperscaler instance types that expose nested virtualization to the guest kernel3. A buyer who deploys sandboxed containers stands up a labelled node pool that meets the hardware requirement and constrains the sandboxed workloads to that pool through node selectors and tolerations. The node pool sizing is the scope decision; the rest of the cluster is unaffected.
The defensive node pool that grew beyond the workload.
The most common exposure pattern across sandboxed containers engagements is the node pool sized defensively for a workload that did not materialise. A buyer plans a workload migration onto sandboxed containers for multi tenant isolation or for compliance driven workload separation, sizes the node pool against the projected migration, and stands up six or eight bare metal worker nodes to absorb the migration. The migration delivers a fraction of the projected workload across the year, and the node pool sits at the original size carrying the platform line on cores that the sandboxed workloads do not need.
The pattern often involves bare metal nodes that carry a higher per node core count than the average worker node in the cluster. A sandboxed node pool of six bare metal nodes with sixty four cores each carries three hundred and eighty four cores on the platform line. The same workload running on conventional containers across a shared worker pool might carry forty or sixty cores of attribution at the marginal cost of the workload. The arithmetic disfavours sandboxed containers unless the isolation requirement is real and the node pool is sized to the actual workload.
The mitigation is to right size the sandboxed node pool against the realised workload at the end of each quarter, decommission idle nodes, and document the isolation requirement that drove the deployment so the audit reading can verify the sizing rationale.
Isolation requirement and the bundle reading, together.
The isolation requirement that drives sandboxed containers is typically one of three: multi tenant workload isolation where tenants do not trust the shared worker kernel; regulated workload separation where compliance requirements specify a virtualization boundary; or untrusted code execution where the workload runs third party code that should not have kernel level access to other workloads on the node.
The bundle reading depends on which OpenShift tier the buyer signed. On the OpenShift Plus bundle, sandboxed containers is included for the bundle cluster scope and carries no incremental charge on those clusters. On the standalone OpenShift Container Platform tier the runtime is also included as a value added operator, but the bare metal node footprint may carry a different cost profile because bundles often price differently on bare metal than on virtualised worker pools.
A subscription assessment in the ninety days before renewal produces a node pool by isolation requirement inventory and reconciles the bundle reading against the bare metal node sizing. The reconciliation tends to surface either a node pool sized for a workload that did not arrive or an isolation requirement that is no longer load bearing because the workload it justified was retired.
Three counting traps on sandboxed node pools.
Three counting traps produce most of the exposure observed across sandboxed containers engagements in the trailing twelve months.
The first trap is the defensively sized node pool described in section two. Bare metal nodes carry high per node core counts, and an over provisioned pool reads as a large platform line attribution regardless of the actual sandboxed workload. The mitigation is quarterly right sizing aligned to the documented isolation requirement.
The second trap is the sandboxed operator left enabled on a cluster after the isolation workload was retired or migrated. The operator state on the cluster is the audit signal, and the cluster carries the sandboxed attribution until the operator is formally removed. A retired workload should trigger a cluster review that includes formal operator removal where the runtime is no longer needed.
The third trap is the workload that drifted off the sandbox. A workload deployed onto sandboxed containers for isolation can drift back onto a conventional runtime if the tolerations or node selectors are removed during an unrelated configuration change. The sandbox node pool then carries the platform line on cores that no longer host any sandboxed workload, and the original isolation rationale no longer holds. A documented isolation requirement, paired with a configuration drift check, closes the drift.
| Pattern | Frequency | Reading |
|---|---|---|
| Node pool sized to realised workload | 3 of 7 | Pays |
| Defensively sized pool, partial migration | 2 of 7 | Traps |
| Operator left enabled after workload retired | 1 of 7 | Traps |
| Workload drifted off sandbox via toleration change | 1 of 7 | Traps |
Reading sandboxed containers at the renewal.
OpenShift sandboxed containers is read through the platform line on the bare metal node pool that hosts the sandboxed runtime. The buyer who scoped the node pool defensively against a projected migration and did not right size as the migration materialised carries the platform line on cores that the sandboxed workload does not need. The buyer who right sizes quarterly and documents the isolation requirement reads the line at the size the workload actually demands.
The discipline at signature sets four protections that hold across the term. The sandboxed node pool size is named in the contract record. The isolation requirement that drives the deployment is documented and reviewed annually. The operator state on the cluster is captured in the quarterly operator inventory so a retired workload does not continue to carry the attribution. A configuration drift check verifies that workloads deployed for sandboxed runtime continue to land on the sandboxed node pool.
For the broader cross product reading, see the OpenShift practice hub, the serverless entitlement, the Service Mesh read, the ACS posture on the same clusters, and the DoD audit posture when sandboxed containers carries the workload isolation requirement for classified environments. For the engagement protocol, see contact.
Notes & references
- 1. Red Hat OpenShift sandboxed containers product page and operator catalog notes, accessed across 2025 and 2026. The product is the Red Hat supported release of the Kata Containers runtime, packaged as a cluster operator on Red Hat OpenShift Container Platform.
- 2. OpenShift sandboxed containers installs as a value added operator inside the OpenShift Container Platform entitlement on the clusters where it runs. The operator targets a labelled node pool that meets the hardware virtualization requirement.
- 3. The sandboxed runtime requires bare metal worker nodes or specific hyperscaler instance types that expose nested virtualization. The node pool sizing is the central scope decision.
- 4. Practice observation across seven OpenShift sandboxed containers engagements settled in the trailing twelve months. The most common exposure pattern is the defensively sized sandbox node pool that exceeded the actual isolation workload.
- 5. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.