google/gvisorユーザースペースのアプリケーションカーネルを介してコンテナをサンドボックス化し、システムコールをインターセプトしてホストカーネルへのアクセスを制限し、OCIランタイムを通じてDocker/Kubernetesと統合します。
gVisor は、実行中のアプリケーションとホストオペレーティングシステムの間に強力な分離レイヤーを提供します。これは Linux ライクなインターフェースを実装するアプリケーションカーネルです。Linux とは異なり、メモリ安全な言語（Go）で書かれており、ユーザー空間で動作します。
gVisor には runsc と呼ばれる Open Container Initiative (OCI) ランタイムが含まれており、既存のコンテナツールと簡単に連携できます。runsc ランタイムは Docker や Kubernetes と統合されているため、サンドボックス化されたコンテナを簡単に実行できます。
seccomp-bpf）ではなく、Linux の分離プリミティブのラッパー（例: firejail、AppArmor など）でもありません。gVisor は明確に異なる第 3 のアプローチを採用しており、VM の多くのセキュリティ上の利点を提供しつつ、通常のユーザー空間アプリケーションの低いリソースフットプリント、高速な起動、柔軟性を維持します。
コンテナはサンドボックスではありません。コンテナはアプリケーションの開発、パッケージ化、デプロイの方法を革命的に変えましたが、追加の分離なしに信頼できない、あるいは潜在的に悪意のあるコードを実行するためにコンテナを使用することは良い考えではありません。単一の共有カーネルを使用することで効率性とパフォーマンスの向上が可能になりますが、それは単一の脆弱性でコンテナエスケープが可能になることも意味します。
gVisor はコンテナ用のアプリケーションカーネルです。アプリケーションが期待するすべての機能へのアクセスを提供しながら、アプリケーションがアクセスできるホストカーネルの表面を制限します。ほとんどのカーネルとは異なり、gVisor は固定された物理リソースのセットを想定したり要求したりしません。代わりに、既存のホストカーネル機能を活用し、通常のプロセスとして動作します。言い換えれば、gVisor は Linux を通じて Linux を実装しています。
gVisor は、外部の脅威に対してコンテナを強化したり、追加の整合性チェックを提供したり、サービスのアクセス範囲を制限したりする技術やツールと混同すべきではありません。コンテナにどのようなデータが利用可能になるかについては、常に注意を払うべきです。
クイックスタートガイドを含むユーザードキュメントと技術アーキテクチャは gvisor.dev で確認できます。
gVisor は x86_64 と ARM64 でビルドできます。他のアーキテクチャは将来利用可能になる可能性があります。
これらの手順では、bazel やその他のビルド依存関係はビルドコンテナにラップされています。bazel を直接使用することも、標準的なターゲットについては make help と入力することも可能です。
以下の依存関係がインストールされていることを確認してください：
runsc、containerd-shim-runsc-v1 containerd シム、および runsc が自身の隣の gvisor-bin/ ディレクトリに見つけることを期待するいくつかのサイドカーバイナリを含むリリース tarball をビルドし、それを /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-bz2
標準のテストスイートを実行するには、次を使用できます:
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 経由のユーザー空間ネットワーキング）に依存する外部パッケージやライブラリが、gVisor の Go コードを自身の 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 を参照してください。
既知の本番ユーザーと採用者の一覧については ADOPTERS.md を参照してください。
質問や議論の出発点としては、gvisor-users メーリングリスト と gvisor-dev メーリングリスト が適しています。
SECURITY.md を参照してください。
Releases を参照してください。
Contributing.md を参照してください。