The Secure Way

Sandboxing untrusted code, the secure way

gVisor, pods with no network, and running other people's code without handing them your cluster.

8 guides

Detecting and stopping sandbox abuse, the secure waySandboxes get abused for mining, scanning and probing your cluster. Alert on Hubble drop and egress metrics and CPU at limit, keep evidence, then cut access.
Exec-only access to sandboxes, the secure wayLet users into their own sandbox pod with kubectl exec and nothing else: per-pod RBAC, create-only exec, no port-forward or nodes/proxy, and an audit trail.
Giving learners root in a sandbox safely, the secure wayHands-on labs need root, and learners will try everything with it. Contain root with gVisor or user namespaces, isolate learners, cap resources, and set a deadline.
gVisor for untrusted workloads on Kubernetes, the secure wayA gVisor RuntimeClass protects only pods that name it; the rest silently run on runc. Pin sandbox nodes, require the class by policy, prove each pod is sandboxed.
Logging sandbox egress with Hubble, the secure wayHubble shows sandbox egress live, then forgets it within minutes. Export sandbox egress flows with DNS names to a file and ship them off the node for review.
One pod per code execution, the secure wayA code-execution feature is a remote shell with a nice API. Run every execution in a fresh sandboxed pod, and pin what the service may create by admission policy.
Pods with no network at all, the secure wayA deny-all NetworkPolicy does nothing if your CNI ignores it, and it may spare open connections. Cut pod networking with Cilium deny rules or gVisor, then test it.
Running untrusted repositories in an isolated job, the secure wayBuilding or testing a stranger's repository runs their code with your job's rights. Use one sandboxed Job per run: no credentials, one allowed host, hard limits.

T Academy

Every guide here is taught hands-on in H2-CSPE Secure Platform Engineering: a real host in your browser, and every objective checked on the machine.

Start free