What Are Sandboxed Containers?<\/h2>\n
Sandboxed containers are a type of container runtime that provides an additional layer of security by isolating containers from the host operating system (OS) and other containers.<\/p>\n
You can also call it as virtualised containers.<\/p>\n
Here is how it works.<\/p>\n
Unlike traditional containers (e.g., Docker, which shares the host OS kernel), sandboxed containers use lightweight virtualization or other isolation mechanisms to fully isolate them.<\/p>\n
This prevents container breakout attacks. Meaning that a container can’t escape its limits and gets access to the host OS Kernel or other containers.<\/p>\n
This ensures stronger security for multi-tenant environments (when many users\/orgs share the same system.)<\/p>\n
Some popular sandboxed container runtimes include:<\/p>\n
- \n
- gVisor<\/strong><\/a> <\/strong>(Developed by Google) \u2013 A user-space kernel that intercepts syscalls to provide extra security.<\/li>\n
- Kata Containers<\/strong><\/a> <\/strong> \u2013 Runs each container inside a lightweight VM, ensuring strong kernel isolation.<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/blog.techiescamp.com\/content\/images\/2025\/02\/image-12.png\")
<\/figure>\nInstead of sharing the host kernel directly, these runtimes introduce an additional layer that limits direct access to system calls. <\/p>\n
It isolates the workloads much better than standard container runtimes.<\/p>\n
For example,<\/p>\n
- \n
- gVisor has its own “mini-kernel” (called Sentry<\/strong>) that runs in user space (not directly on the host OS). When an app inside the container makes a syscall, gVisor intercepts<\/strong> it and emulates<\/strong> (pretends to handle) it instead of letting it go directly to the host OS.<\/li>\n
- Kata runs containers in lightweight VMs. The VM kernel typically allows ~200-300 syscalls (similar to a normal Linux kernel). The app inside the container makes syscalls to the VM’s kernel, not the host OS kernel.<\/li>\n<\/ul>\n
Container Runtime and Host Kernel Access<\/h2>\n
To understand sandboxed containers, we first need to know how much access a typical container has to the host kernel.<\/p>\n
Most containers today run on container runtimes such as
containerd<\/code> orcri-o<\/code>.<\/p>\nLet\u2019s consider what happens when you run a basic container:<\/p>\n
- \n
- It uses the host\u2019s system calls directly.<\/li>\n
- It shares the same kernel version and capabilities.<\/li>\n
- It is controlled through Linux capabilities, which limit privileged operations.<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/blog.techiescamp.com\/content\/images\/2025\/02\/image-11.png\")
<\/figure>\nHowever, despite these controls, containers can still,<\/p>\n
- \n
- Make direct system calls (~300) to the kernel, which could be exploited if there are vulnerabilities.<\/li>\n
- Read kernel version and system information.<\/li>\n
- Access kernel modules and subsystems (though with some restrictions).<\/li>\n<\/ul>\n
This level of access poses a risk when running untrusted workloads, especially in multi-tenant environments like CI\/CD platforms.<\/p>\n
Performance Trade-offs<\/h2>\n
With good security benefits, sandboxed containers come with some performance trade-offs.<\/p>\n
Since sandboxed containers rely on user-space kernels, they may consume more CPU and memory compared to traditional containers.<\/p>\n
Unlike standard containers, which start almost instantly, sandboxed containers may take slightly longer to boot due to the added virtualization layer.<\/p>\n
Organizations that Use Sandboxed Containers<\/h2>\n
Following are some of the top organizations that use sandboxed containers in production:<\/p>\n
- \n
- OpenAI is using gVisor runtime to run some of its high-risk tasks.<\/li>\n
- Cloudflare uses gVisor for its building infrastructure<\/li>\n
- NVIDIA uses Kata Containers to support AI\/ML workloads<\/li>\n
- Blink is a DevOps platform that uses gVisor for the EKS Pods to run securely.<\/li>\n<\/ol>\n
Use Case<\/h2>\n
Let’s say you are building a SaaS-based CI\/CD platform like CircleCI or BuildKite, where other companies run their build pipelines.<\/p>\n
Let’s say this service lets users define their own build steps and run any Docker container they need for builds.<\/p>\n
Ultimately, these build jobs run as containers or pods inside your cluster, and the separation between companies is mostly logical. <\/p>\n
While companies are logically separated, they still share the same underlying system kernel.<\/strong><\/p>\n
Now, let\u2019s say someone on your team mistakenly allows privileged mode<\/strong> in pod security settings.<\/p>\n
This means a compromised build job could gain access to the host system. If that happens, one company\u2019s build could access another company\u2019s source code, secrets, or sensitive data.<\/p>\n
This is a huge security risk!<\/p>\n
So how do you avoid this?<\/p>\n
To prevent such risks, we need stronger isolation between builds. This is where Sandboxed Containers come into play.<\/p>\n
\n\ud83d\udca1<\/div>\nNote:<\/strong><\/b> The use case is just an example.<\/div>\n<\/div>\nShould You Use Sandboxed Containers?<\/h2>\n
If you’re running sensitive, multi-tenant workloads like:<\/p>\n
- \n
- CI\/CD services<\/li>\n<\/ul>\n
Serverless functions (e.g., AWS Lambda, Cloud Run)<\/p><\/blockquote>\n
- \n
- SaaS platforms where customers execute arbitrary code<\/li>\n<\/ul>\n
Then sandboxed containers are a great way to minimize risk and ensure better isolation.<\/p>\n
However, if your workloads run in a trusted environment (such as an internal microservices architecture), the overhead may not be worth it.<\/strong><\/p>\n
Conclusion<\/h2>\n
Although sandboxed containers have certain performance trade-offs, some enterprises use this technology to run their workflows securely.<\/p>\n
Companies that use sandboxed containers have made performance tweaks to make them work at almost the same speed as normal containers.<\/p>\n
Hope this blog serves as a primer on sandboxed containers.<\/p>\n
Want to Stay Ahead in DevOps & Cloud? Join the Free Newsletter Below.<\/p>\n
\n
- SaaS platforms where customers execute arbitrary code<\/li>\n<\/ul>\n
- CI\/CD services<\/li>\n<\/ul>\n
- Kata runs containers in lightweight VMs. The VM kernel typically allows ~200-300 syscalls (similar to a normal Linux kernel). The app inside the container makes syscalls to the VM’s kernel, not the host OS kernel.<\/li>\n<\/ul>\n
- Kata Containers<\/strong><\/a> <\/strong> \u2013 Runs each container inside a lightweight VM, ensuring strong kernel isolation.<\/li>\n<\/ul>\n