runsc

runsc
Name	runsc
Title	runsc
Developer	Google
Released	2017
Programming language	Go
Operating system	Linux
Platform	Linux
License	Apache License 2.0

runsc

runsc is an OCI-compatible runtime implementing the gVisor sandbox for containerized workloads. It mediates system calls between containerized applications and the Linux kernel via a userspace kernel, aiming to provide strong isolation for untrusted code while remaining compatible with existing container ecosystems. runsc is used in production by cloud platforms and research projects to reduce attack surface and improve multi-tenant isolation for workload execution.

Overview

runsc implements a user-space kernel for container isolation, integrating with container runtimes and orchestration systems such as Docker, Kubernetes, Containerd, CRI-O, and Google Kubernetes Engine. It translates container system calls into a controlled set of operations managed by the gVisor Sentry and integrates with low-level facilities like seccomp, chroot, and Namespaces (Linux) to minimize direct kernel exposure. runsc is distributed under the Apache License 2.0 and is written primarily in Go (programming language). It targets Linux distributions commonly used in cloud infrastructure, including Debian, Ubuntu, CentOS, and Alpine Linux.

History and Development

runsc was developed by engineers at Google as part of the gVisor project, originating from internal efforts to harden multi-tenant services such as Google App Engine and Google Cloud Platform. Early public releases and demonstrations occurred around 2017, with source code and collaboration facilitated through GitHub repositories. Over time, runsc received contributions and evaluation from organizations including IBM, Red Hat, Microsoft, and academic groups at institutions like MIT and Stanford University. It has been showcased at conferences such as KubeCon, USENIX, and Black Hat USA and discussed in publications at venues like USENIX Security Symposium.

Architecture and Design

The architecture centers on a userspace kernel component called the Sentry, written in Go (programming language), which implements core kernel abstractions such as process management, file systems, network stacks, and IPC. runsc uses a layered design: the Sentry intercepts syscalls from the sandboxed application and maps them to emulated services or proxies to kernel-backed implementations via mechanisms like Virtual File System proxies and shims similar to gRPC patterns. For networking, runsc can integrate with virtual networking provided by CNI (Container Network Interface), IPTables, and virtual device frameworks inspired by TUN/TAP and VLAN technologies. Storage interactions can be mediated through implementations compatible with OverlayFS, aufs, and kernel-backed filesystems used by Docker and Overlay2.

Compatibility and Standards Compliance

runsc aims for compatibility with the Open Container Initiative runtime specification and the OCI Runtime Specification and integrates with the Container Runtime Interface used by Kubernetes. It supports standard image formats such as Docker image, and leverages tooling like Buildah, Podman, and Skopeo for image manipulation and distribution. Interoperability testing has involved projects like Conformance tests within Kubernetes and integration with Cloud Native Computing Foundation hosted components. runsc respects POSIX-like interfaces where feasible while documenting deviations to standards where userspace emulation imposes constraints.

Security Features

runsc provides defense-in-depth features including syscalls interception, reduced kernel attack surface, and fine-grained sandboxing comparable to technologies like seccomp, AppArmor, SELinux, and gVisor itself. It isolates namespaces, enforces capabilities constraints aligned with Linux capabilities, and employs memory safety strategies by leveraging Go (programming language) memory management. runsc has been evaluated under threat models similar to adversary scenarios described in CVE disclosures and vendor advisories from Google Security Blog. It has been subject to third-party audits by security firms and academic researchers from University of California, Berkeley and ETH Zurich.

Performance and Use Cases

Performance trade-offs reflect emulation overhead versus isolation benefits; microbenchmarks compare runsc to native runc and hypervisor-based solutions like KVM and Firecracker. Typical use cases include multi-tenant platform-as-a-service offerings exemplified by Google App Engine, ephemeral build environments used by Jenkins and GitLab CI, and secure execution of untrusted functions similar to AWS Lambda and Azure Functions. runsc is suitable for workloads prioritizing isolation over raw I/O throughput, and is often evaluated alongside sandboxing technologies such as gVisor, gVisor-sandbox, and project implementations in OpenStack testbeds.

Deployment and Integration

Operators deploy runsc with orchestration platforms such as Kubernetes by configuring the container runtime class and runtime handlers and integrating with image registries like Google Container Registry, Docker Hub, and Quay.io. CI/CD pipelines in Jenkins, GitLab, and CircleCI have example templates to exercise runsc sandboxes. Integration with observability stacks such as Prometheus, Grafana, and Fluentd is common for monitoring. Cloud providers including Google Cloud Platform offer managed options and reference architectures demonstrating runsc deployment patterns.

Community and Governance

runsc development occurs in open-source repositories hosted on GitHub and contributors include engineers from Google, independent contributors, and corporate partners like Intel and NVIDIA for platform support. Governance follows a model where maintainers and committers review patches, discuss roadmap items at events such as KubeCon and in fora like CNCF working groups. The project maintains issue trackers, design documents, and contribution guidelines to coordinate work among compiler and runtime researchers, systems engineers, and cloud operators.

Category:Container runtimes