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 sopra
le primitive di isolamento di Linux (ad esempio firejail, AppArmor, ecc.).gVisor adotta un terzo approccio distinto, fornendo molti dei vantaggi 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, utilizzarli per eseguire codice non attendibile o potenzialmente malevolo senza un isolamento aggiuntivo non è una buona idea. Sebbene l'utilizzo di un singolo kernel condiviso consenta efficienza e guadagni in termini di prestazioni, significa anche che l'escape dal container è possibile con una singola vulnerabilità.
gVisor è un kernel applicativo per i container. Limita la superficie del kernel host accessibile all'applicazione pur consentendo all'applicazione di accedere a tutte le funzionalità che si aspetta. A differenza della maggior parte dei kernel, gVisor non presuppone o 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 deve essere 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 sono resi disponibili a un container.
La documentazione 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 utilizzare
bazel direttamente, oppure digitare make help per i target standard.
Assicurati che le seguenti dipendenze siano installate:
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 è raccomandato a causa del sovraccarico 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, 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. Viene mantenuto un branch
go sintetico compatibile con gli strumenti go standard per
comodità. Questo è utile per pacchetti e librerie esterni che dipendono dai
sottopacchetti di gVisor (ad esempio il networking in spazio utente tramite Netstack) per importare il codice Go di gVisor
nei loro progetti Go.
Seleziona questo branch esplicitamente con la query del branch go. @latest risolve
master, che richiede Bazel e non è compatibile con gli strumenti Go standard:
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 in modalità best effort, e
lo sviluppo diretto su questo branch non è supportato. Lo sviluppo dovrebbe avvenire sul
branch master, che viene poi riflesso nel branch go.
Consulta GOVERNANCE.md per informazioni sulla governance del progetto.
Consulta ADOPTERS.md per un elenco degli utenti e adottanti di produzione noti.
La mailing list gvisor-users e la mailing list gvisor-dev sono buoni punti di partenza per domande e discussioni.
Consulta SECURITY.md.
Consulta Contributing.md.