Not All Pods Are Equal – Running Sandboxed Workloads (Kata)
Duration: ~20 minutes
Overview
Advanced workload restriction (runtime isolation enhancements).
Run a workload with sandboxed containers and contrast isolation trade-offs against standard pods.
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 the right defense—not just a novelty.
Prerequisites
-
Worker nodes with virtualization support (VT-x/AMD-V)
-
Cluster admin permissions
Click each step only if you need a hint.
Operator Presence
oc get csv -n openshift-sandboxed-containers 2>/dev/null | grep -i sandbox || echo "Install Sandboxed Containers Operator from OperatorHub"RuntimeClass
oc get runtimeclass | grep -i kata || cat <<'EOF' | oc apply -f -
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata
handler: kata
EOFNamespace & Baseline Pod
oc new-project 201-10-s-sandbox
oc run regular --image=registry.access.redhat.com/ubi9/ubi -- sleep 3600Kata Pod
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"]
EOFCompare Isolation
oc exec regular -- ps -ef | head
oc exec kata-pod -- ps -ef | headKata pod process list should show fewer host processes; underlying hypervisor isolation applies.
Check SCC annotation:
oc get pod kata-pod -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'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
Controls that matter: RuntimeClass for Kata where justified, still stack platform hardening, and measure performance cost against sensitivity.
Quick facts: use selectively for untrusted or high-value isolation needs; keep the rest of the control stack.
