Sandbox-check – Does your locked-down container reach cloud metadata?

Most sandbox checklists run on the host, asking if hardening flags like --cap-drop=ALL were set. However, inside real cloud VMs, container configurations and HTTP_PROXY setups still routinely leak cloud metadata. The new sandbox-check tool audits this isolation directly from inside the workload.

It tests whether untrusted code can reach cloud metadata endpoints, bypass HTTP_PROXY, or SSRF the proxy. The tool also checks for host service exposure, shared kernel surface escapes, unbounded cgroup exhaustion, and the reading of raw API keys from environment variables.

Deterministic exit codes

The tool fails closed with deterministic exit codes. An exit code of 0 indicates a pass. An exit code of 2 indicates a failure, while 3 signals warnings or inconclusive results. It explicitly outputs 'WARNINGS DETECTED / INCONCLUSIVE' when pass=0 and warn>0, never 'NO DETECTED LEAKS'.

Installation and usage

Users can install the precompiled binary, version v0.2.0, with a pinned release command. The installation script supports verifying build provenance via GitHub Artifact Attestations with the SANDBOX_CHECK_VERIFY_ATTESTATION=1 flag.

The tool can be run inside a sandbox to generate a human-readable isolation audit report or a structured JSON report for CI and automated harnesses. Users can also assert cross-tenant isolation against another sandbox IP:port on the same host.

For Kubernetes, a temporary SHA256-verified probe pod can be run in the target namespace. Alternatively, the static Linux binary can be copied directly into any running pod or container.

Example output reveals critical gaps

An example output for a hardened Docker container with the default bridge shows a critical failure. The tool detected that the cloud metadata endpoint 169.254.169.254:80 was exposed via HTTP GET, returning a 200 status code.

The audit also failed on proxy bypass attempts, including DNS tunneling via UDP port 53 and HTTP CONNECT tunnels to the IMDS. The summary reported 15 failures, 1 warning, and 1 info, resulting in an exit code of 2.

Scope and limitations

The tool has specific limitations. It cannot distinguish between a TCP connection refused and a firewall drop based on timing alone. It also has an environment-only secret scope, checking only process environment variable names.

Passing all sandbox-check probes verifies common guest-observable misconfigurations. It does not prove the absence of hypervisor or kernel CVEs, DNS-over-HTTPS abuse, or application vulnerabilities, and it does not replace an independent penetration test.