google/gvisorIsola in sandbox i container tramite un kernel applicativo in spazio utente che intercetta le chiamate di sistema, limita l'accesso al kernel dell'host e si integra con Docker/Kubernetes tramite un runtime OCI.
gVisor fornisce un solido livello di isolamento tra le applicazioni in esecuzione e il sistema operativo host. È un kernel applicativo che implementa un'interfaccia simile a Linux. A differenza di Linux, è scritto in un linguaggio memory-safe (Go) e viene eseguito nello spazio utente.
gVisor include un runtime Open Container Initiative (OCI) chiamato runsc
che semplifica l'utilizzo con gli strumenti per container esistenti. Il runtime runsc
si integra con Docker e Kubernetes, rendendo semplice l'esecuzione di container
in sandbox.
seccomp-bpf), né un wrapper sulle
primitive di isolamento di Linux (ad es. firejail, AppArmor, ecc.).gVisor adotta un terzo approccio distinto, offrendo molti dei vantaggi in termini di sicurezza delle VM mantenendo un'impronta di risorse ridotta, un avvio rapido e la flessibilità delle normali applicazioni in spazio utente.
I container non sono una sandbox. Sebbene i container abbiano rivoluzionato il modo in cui sviluppiamo, impacchettiamo e distribuiamo le applicazioni, usarli per eseguire codice non attendibile o potenzialmente malevolo senza un isolamento aggiuntivo non è una buona idea. Sebbene l'uso di un unico kernel condiviso consenta efficienza e guadagni in prestazioni, significa anche che l'evasione dal container è possibile con una singola vulnerabilità.
gVisor è un kernel applicativo per i container. Limita la superficie del kernel host accessibile all'applicazione pur continuando a dare all'applicazione accesso a tutte le funzionalità che si aspetta. A differenza della maggior parte dei kernel, gVisor non presuppone né richiede un insieme fisso di risorse fisiche; invece, sfrutta le funzionalità esistenti del kernel host e viene eseguito come un normale processo. In altre parole, gVisor implementa Linux per mezzo di Linux.
gVisor non va confuso con tecnologie e strumenti per rafforzare i container contro minacce esterne, fornire controlli di integrità aggiuntivi o limitare l'ambito di accesso per un servizio. Bisogna sempre prestare attenzione a quali dati vengono resi disponibili a un container.
La documentazione per l'utente e l'architettura tecnica, incluse le guide di avvio rapido, sono disponibili su gvisor.dev.
gVisor si compila su x86_64 e ARM64. Altre architetture potrebbero diventare disponibili in futuro.
Ai fini di queste istruzioni, bazel e altre dipendenze di build
sono racchiuse in un container di build. È possibile usare
bazel direttamente, oppure digitare make help per i target standard.
Assicurati che siano installate le seguenti dipendenze:
Compila un tarball di release contenente runsc, lo shim containerd containerd-shim-runsc-v1
e alcuni binari sidecar che runsc si aspetta di trovare in una
directory gvisor-bin/ accanto a sé, quindi estrailo in /usr/local/bin:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
Per compilare librerie o binari specifici, puoi specificare il target:
make build TARGETS="//pkg/tcpip:tcpip"
L'uso diretto di Bazel non è consigliato a causa dell'overhead aggiuntivo, ma per iniziare:
Dopo aver configurato le dipendenze, usare Bazel è simile al Makefile:
bazel build -c opt //debian:gvisor-release-tar-bz2
Per eseguire le suite di test standard, puoi usare:
make unit-tests
make tests
Per eseguire test specifici, puoi specificare il target:
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
Alcuni pacchetti supportano l'esecuzione dei test direttamente su macOS. Al momento della stesura di questo documento, gVisor richiede bazel 8, che puoi installare tramite 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 getQuesto progetto utilizza bazel per compilare e gestire le dipendenze. Per comodità viene mantenuto un branch go sintetico compatibile con gli strumenti standard di go. Ciò è utile per i pacchetti e le librerie esterne che dipendono dai sottopacchetti di gVisor (ad esempio il networking in userspace tramite Netstack) per importare il codice Go di gVisor nei propri progetti Go.
Seleziona esplicitamente questo branch con la query del branch go. @latest risolve su master, che richiede Bazel e non è compatibile con gli strumenti standard di Go:
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
NOTA: le build di runsc da questo branch non sono supportate. gVisor e
runsc richiedono diversi binari (alcuni dei quali non sono nemmeno scritti in Go)
per funzionare. Il branch go è supportato con il massimo impegno possibile, e
lo sviluppo diretto su questo branch non è supportato. Lo sviluppo dovrebbe avvenire sul
branch master, che viene poi riflesso nel branch go.
Vedi GOVERNANCE.md per informazioni sulla governance del progetto.
Vedi ADOPTERS.md per un elenco degli utenti e degli adottanti in produzione conosciuti.
La gvisor-users mailing list e la gvisor-dev mailing list sono buoni punti di partenza per domande e discussioni.
Vedi SECURITY.md.
Vedi Releases.
Vedi Contributing.md.