google/gvisorユーザースペースのアプリケーションカーネルを介してコンテナをサンドボックス化し、システムコールをインターセプトしてホストカーネルへのアクセスを制限し、OCIランタイムを通じてDocker/Kubernetesと統合します。
gVisor は、実行中のアプリケーションとホストオペレーティングシステムの間に強力な分離レイヤーを提供します。これは Linux ライクなインターフェース を実装したアプリケーションカーネルです。Linux とは異なり、メモリ安全な言語（Go）で書かれており、ユーザースペースで動作します。
gVisor には runsc と呼ばれる Open Container Initiative (OCI) ランタイムが含まれており、既存のコンテナツールとの連携が容易です。runsc ランタイムは Docker や Kubernetes と統合されており、サンドボックス化されたコンテナを簡単に実行できます。
seccomp-bpf）ではなく、Linux の分離プリミティブのラッパー（例: firejail、AppArmor など）でもありません。gVisor は明確な第三のアプローチを取ります。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 を参照してください。
Contributing.md を参照してください。