QA
Senior LevelDocker & Deployment

How do Sandboxed Runtimes (gVisor, Kata Containers) differ from standard OCI runc runtimes?

❓ Interview Prompt: Compare gVisor (user-space kernel Sentry), Kata Containers (microVM isolation), and runc (standard namespaces) for multi-tenant security isolation.

Standard containers use Linux namespaces for isolation, but still share the host kernel — one kernel vulnerability exposes all containers. Sandboxed runtimes add an additional isolation layer.

gVisor (Google):

gVisor runs an intercepting user-space kernel called Sentry between the container process and the host kernel.

•
Container system calls go to Sentry, not the host kernel.
•
Sentry is a Go application implementing ~240 Linux syscalls.
•
Syscalls not implemented by Sentry never reach the host kernel — massively reduced attack surface.
•
Trade-off: ~10–20% performance overhead; not all Linux syscalls supported (some POSIX-heavy apps break).
•
Integration: Kubernetes runtimeClassName: gvisor.

Kata Containers:

Kata Containers boot a lightweight microVM (QEMU/Firecracker) per pod — each pod runs inside its own VM with a dedicated kernel.

•
Full VM isolation — a kernel exploit in a pod's VM cannot affect other pods.
•
Performance: Near-native for CPU workloads; ~10% overhead for network/storage (I/O goes through virtio).
•
Boot time: 1–2 seconds (vs. milliseconds for runc).
•
Integration: Works with containerd via kata-runtime shim; Kubernetes runtimeClassName: kata-containers.

When to Use:

•
runc: Standard trusted workloads — internal microservices.
•
gVisor: Untrusted user code, multi-tenant SaaS, FaaS platforms.
•
Kata: Maximum isolation for financial/healthcare data, government workloads, hostile tenant environments.

Code Implementation Example

yaml
# RuntimeClass definitions — register sandboxed runtimes in Kubernetes
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc          # gVisor's OCI runtime handler name
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-containers
handler: kata-qemu      # Kata QEMU microVM handler
---
# Pod selecting gVisor sandbox runtime
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor   # or: kata-containers
  containers:
    - name: app
      image: user-submitted-code:latest
      securityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true
💡RuntimeClass selects gVisor or Kata per-pod — untrusted code runs in user-space kernel (gVisor) or dedicated microVM (Kata).
🎯 Interview Key Takeaway

gVisor intercepts syscalls via user-space kernel (Sentry); Kata runs each pod in a microVM. Both provide kernel-level isolation beyond standard namespaces — use for untrusted/multi-tenant workloads.

#gVisor#Kata Containers#Sandboxed Runtimes#Security Isolation#Senior
Back to all Docker & Deployment Questions→

More Docker & Deployment Interview Questions

Beginner LevelDocker & Deployment

How do Docker Multi-Stage Builds minimize image size and improve security?

Beginner LevelDocker & Deployment

What is the difference between a Docker Container and a Virtual Machine (VM)?

Beginner LevelDocker & Deployment

What is the difference between a Docker Image and a Docker Container?