
Изолирует контейнеры через прикладное ядро в пользовательском пространстве, которое перехватывает системные вызовы, ограничивает доступ к ядру хоста и интегрируется с Docker/Kubernetes через OCI runtime.

gVisor обеспечивает надёжный уровень изоляции между работающими приложениями и операционной системой хоста. Это прикладное ядро, реализующее Linux-подобный интерфейс. В отличие от Linux, оно написано на безопасном для памяти языке (Go) и работает в пользовательском пространстве.
gVisor включает среду выполнения Open Container Initiative (OCI) под названием runsc, которая упрощает работу с существующими контейнерными инструментами. Среда выполнения runsc интегрируется с Docker и Kubernetes, что упрощает запуск изолированных контейнеров.
seccomp-bpf) и не обёртка над примитивами изоляции Linux (например, firejail, AppArmor и т. д.).gVisor использует особый третий подход, обеспечивая многие преимущества виртуальных машин с точки зрения безопасности, сохраняя при этом меньшее потребление ресурсов, быстрый запуск и гибкость обычных пользовательских приложений.
Контейнеры — это не песочница. Хотя контейнеры произвели революцию в том, как мы разрабатываем, упаковываем и разворачиваем приложения, использовать их для запуска недоверенного или потенциально вредоносного кода без дополнительной изоляции — не лучшая идея. Использование единого общего ядра даёт преимущества в эффективности и производительности, но также означает, что побег из контейнера возможен при наличии одной уязвимости.
gVisor — это прикладное ядро для контейнеров. Оно ограничивает поверхность ядра хоста, доступную приложению, но при этом предоставляет приложению доступ ко всем ожидаемым функциям. В отличие от большинства ядер, gVisor не предполагает и не требует фиксированного набора физических ресурсов; вместо этого он использует существующую функциональность ядра хоста и работает как обычный процесс. Другими словами, gVisor реализует Linux средствами Linux.
gVisor не следует путать с технологиями и инструментами для усиления защиты контейнеров от внешних угроз, обеспечения дополнительных проверок целостности или ограничения области доступа для сервиса. Всегда следует внимательно относиться к тому, какие данные предоставляются контейнеру.
Пользовательская документация и техническая архитектура, включая краткие руководства по началу работы, доступны на gvisor.dev.
gVisor собирается на x86_64 и ARM64. Другие архитектуры могут стать доступны в будущем.
Для целей этих инструкций bazel и другие зависимости сборки упакованы в контейнер для сборки. Можно использовать bazel напрямую или ввести make help для получения стандартных целей.
Убедитесь, что установлены следующие зависимости:
Соберите release-архив (tarball), содержащий runsc, containerd-шим containerd-shim-runsc-v1 и несколько вспомогательных бинарных файлов (sidecar), которые runsc ожидает найти в каталоге gvisor-bin/ рядом с собой, затем распакуйте его в /usr/local/bin:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
Чтобы собрать конкретные библиотеки или бинарные файлы, можно указать цель:
make build TARGETS="//pkg/tcpip:tcpip"
Использовать Bazel напрямую не рекомендуется из-за дополнительных накладных расходов, но для начала:
После настройки зависимостей использование Bazel аналогично Makefile:
bazel build -c opt //debian:gvisor-release-tar
Для запуска стандартных наборов тестов можно использовать:
make unit-tests
make tests
Чтобы запустить конкретные тесты, можно указать цель:
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
Некоторые пакеты поддерживают запуск тестов непосредственно в macOS. На момент написания gVisor требует bazel 8, который можно установить через homebrew:
brew install bazel@8
# You can then run the tests, e.g.:
$(brew --prefix bazel@8)/bin/bazel test --macos_sdk_version=$(xcrun --show-sdk-version) -- //tools/nogo/... //tools/check{aligned,const,escape,linkname,locks,unsafe}/...
go getЭтот проект использует bazel для сборки и управления зависимостями. Для удобства поддерживается синтетическая ветка go, совместимая со стандартными инструментами go. Это полезно для внешних пакетов и библиотек, которые зависят от подпакетов gVisor (например, пользовательский сетевой стек через Netstack), чтобы импортировать Go-код gVisor в свои проекты на Go.
Выбирайте эту ветку явно с помощью запроса ветки go. @latest указывает на master, который требует Bazel и не совместим со стандартными инструментами Go:
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
ПРИМЕЧАНИЕ: Сборки runsc из этой ветки не поддерживаются. Для работы gVisor и runsc требуются несколько бинарных файлов (некоторые из них даже не написаны на Go). Ветка go поддерживается по мере возможностей, и прямая разработка в этой ветке не поддерживается. Разработка должна вестись в ветке master, которая затем переносится в ветку go.
См. GOVERNANCE.md с информацией об управлении проектом.
Список рассылки gvisor-users и список рассылки gvisor-dev — хорошие отправные точки для вопросов и обсуждений.
См. SECURITY.md.
См. Contributing.md.