Notes on getting Sysbox working on a GKE cluster with zero public internet access, so Testcontainers based tests can run inside the same pipeline as everything else.
Part 1: Why It Matters
I’ve watched a handful of platform teams hit this same wall. They lock down GKE the way it’s supposed to be locked down: no public egress from any node or pod, every dependency routed through a small set of preconfigured virtual repositories in Google Artifact Registry that cover Docker, npm, and Maven. Security signs off. Compliance signs off. Everyone moves on.
Then the test team shows up and asks why their Testcontainers based integration suite won’t run in the pipeline.
Testcontainers is the default way teams run integration tests against real dependencies. Spin up a real Postgres. A real Kafka broker. Run the test against it. Tear it down when you’re done. It’s not a mock or an in-memory stand-in, which is exactly why it catches bugs that mocks hide. The problem is easy to state and annoying to actually solve: Testcontainers needs a real Docker daemon to talk to.
On a laptop, that’s nothing. Docker Desktop is right there. Inside a Kubernetes pod on a shared, locked-down cluster, it’s a much harder question, because a pod isn’t a VM. It shares a kernel with everything else scheduled on that node.
Two answers usually come up, and neither one is good.
First option: privileged: true, the Docker socket bind-mounted in from the host, maybe a full DinD sidecar running privileged. It works. It also gives a test container a fairly direct line to the host kernel, and if that container gets compromised or misbehaves, the blast radius isn’t contained anymore. Most security teams won’t approve this, and honestly, they’re right not to.
Second option: give up on running the tests in the pipeline at all. Push them to a separate, less locked-down environment, or worse, back onto individual developer laptops. That undoes the entire point. You’re right back to “passed on my machine, failed in CI” – the exact failure mode integration testing exists to kill.
Where Sysbox actually helps
Sysbox is an open source runtime that sidesteps both bad options. A container running under Sysbox gets its own Docker daemon inside a real, isolated Linux user namespace. No –privileged flag, no host root access. The test container sees what looks like an ordinary Docker host, while the node just sees one more unprivileged pod, no different from anything else scheduled on it.
That’s the property that actually gets this past a security review. Not a promise that the workload will behave, but a real kernel-level boundary.
Why this is worth the engineering effort
The value case, stated plainly: get Sysbox working on a locked-down GKE cluster and test teams run real Testcontainers based integration tests inside the same CI/CD pipeline as everything else, on infrastructure security already trusts. No exception requests. No separate environments to manage. No convincing anyone to sign off on a privileged pod.
There’s a second benefit that’s easy to overlook. Once the cluster has this capability, every team building test infrastructure just inherits it. Nobody has to go through the privileged container question team by team, project by project.
The next two parts get into how this actually gets built on a cluster with no internet egress: two runtime bugs that only show up in that kind of environment, and the exact checks that prove a real Java Testcontainers run worked end to end.
 | Anuj Tuli, Chief Technology Officer Anuj specializes in developing and delivering vendor-agnostic solutions that avoid the “rip-and-replace” of existing IT investments. He has worked on Cloud Automation, DevOps, Cloud Readiness Assessments, and Migration projects for healthcare, banking, ISP, telecommunications, government and other sectors. He leads the development and management of Cloud Automation IP (intellectual property) and related professional services. During his career, he held multiple roles in the Cloud and Automation, and DevOps domains. With certifications in AWS, VMware, HPE, BMC and ITIL, Anuj offers a hands-on perspective on these technologies. Like what you read? Follow Anuj on LinkedIn at https://www.linkedin.com/in/anujtuli/ |