Not All Pods Are Equal – Running Sandboxed Workloads (Kata)
Duration: ~15 minutes
Overview
A standard pod shares the worker’s Linux kernel. Namespaces, cgroups, seccomp, and SCCs shrink what that process can do; they do not give you a second kernel. Customers pick a sandboxed pod when a breakout to that shared kernel is an unacceptable business or tenancy risk—not because every microservice needs a VM.
Typical reasons to set runtimeClassName: kata on some workloads:
-
Untrusted or third-party code — CI jobs that build customer repos, plugins, student labs, or a vendor binary you have not fully audited. The pipeline stays on OpenShift; the job does not share the node kernel with production.
-
Multi-tenant / SaaS — more than one customer (or business unit) on the same nodes. A container escape should not become “read the neighbor’s secrets from the host.”
-
High-impact data — payment, health, or similarly sensitive processing where the isolation story has to survive a kernel-level container CVE, not only an SCC deny.
-
“I need privileges inside the workload, not on the node” — tools that expect a full guest (custom kernel modules, nested isolation) without putting
privilegedon the worker.
They do not sandbox everything. Kata starts slower and costs more CPU/memory than a runc pod. Pair it with the rest of the stack (SCC, NetworkPolicy, RHACS). Confidential computing (hardware memory encryption) is a later platform choice when the threat includes a privileged host—not a follow-on lab in this roadshow.
Why it matters
Standard containers share a kernel with the node. A breakout from a high-risk workload can reach everything else on that host. Sandboxed runtimes raise the wall when that risk is unacceptable.
What does it solve
-
Shared-kernel blast radius for untrusted or multi-tenant workloads
-
Weak isolation for CI runners or customer code
-
Ambiguity about when stronger runtime isolation is worth the cost
Your Mission
Run a sandboxed workload and contrast it with a normal pod so you know when stronger isolation is justified.
Prerequisites
-
Worker nodes with virtualization support (VT-x/AMD-V)
-
Cluster admin permissions
Click each step only if you need a hint.
Get the Sandboxed Containers CSV
Confirm the operator is installed before you create a Kata pod.
oc get csv -n openshift-sandboxed-containers 2>/dev/null | grep -i sandbox || echo "Install Sandboxed Containers Operator from OperatorHub"| A CSV line prints, or you get the install reminder. |
Get RuntimeClass kata
Pods select Kata with runtimeClassName: kata.
oc get runtimeclass | grep -i kata
A kata RuntimeClass is listed. If not, apply one in the next step.
|
Apply RuntimeClass kata if it is missing
Skip this if oc get runtimeclass already showed kata.
oc apply -f - <<'EOF'
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata
handler: kata
EOF
runtimeclass.node.k8s.io/kata created (or already exists).
|
Create project 201-09-s-sandbox
oc new-project 201-09-s-sandbox
Now using project "201-09-s-sandbox".
|
Run pod regular
This is the shared-kernel baseline.
oc run regular --image=registry.access.redhat.com/ubi9/ubi -- sleep 3600
pod/regular created. Wait until it is Running.
|
Apply pod kata-pod
runtimeClassName: kata is the isolation switch.
oc apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: kata-pod
spec:
runtimeClassName: kata
containers:
- name: app
image: registry.access.redhat.com/ubi9/ubi
command: ["sh","-c","uname -a; ps -ef; sleep 3600"]
EOF
pod/kata-pod created. Wait until it is Running (Kata can take longer to start).
|
Exec ps on pod regular
Shared-kernel pods often see more host-adjacent processes.
oc exec regular -- ps -ef | head| Note how many processes appear. You will compare this to Kata. |
Exec ps on pod kata-pod
Kata should show a thinner process list; the guest VM hides the node’s process table.
oc exec kata-pod -- ps -ef | head
Fewer host processes than regular.
|
Read the SCC annotation on kata-pod
Sandboxing does not replace SCC. Confirm which SCC still applied.
oc get pod kata-pod -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'
An SCC name prints (often restricted or similar). Kata is extra isolation on top.
|
Debrief
Kata (sandboxed) containers add a VM boundary for high-risk workloads—but they do not replace SCC, seccomp, quotas, or NetworkPolicy. Measure startup and CPU cost before rolling Kata out broadly; use it where isolation value outweighs overhead.
What breaks without this:
-
Shared-kernel assumptions alone → breakout impact is larger for untrusted code
-
Sandbox everywhere → operational overhead without risk-based selection
| RuntimeClass for Kata where justified, still stack platform hardening, and measure performance cost against sensitivity. |
| use selectively for untrusted or high-value isolation needs; keep the rest of the control stack. |
