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 forte 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 gira nello spazio utente.
gVisor include un runtime Open Container Initiative (OCI) chiamato runsc che semplifica il lavoro con gli strumenti container esistenti. Il runtime runsc si integra con Docker e Kubernetes, rendendo semplice eseguire container in sandbox.
seccomp-bpf), né un wrapper sulle primitive di isolamento di Linux (ad es. firejail, AppArmor, ecc.).gVisor adotta un distinto terzo approccio, offrendo molti vantaggi di sicurezza delle VM pur mantenendo il ridotto impatto sulle risorse, l'avvio rapido e la flessibilità delle normali applicazioni nello spazio utente.
I container non sono una sandbox. Sebbene i container abbiano rivoluzionato il modo di sviluppare, impacchettare e distribuire le applicazioni, usarli per eseguire codice non fidato o potenzialmente dannoso senza un isolamento aggiuntivo non è una buona idea. Se da un lato l'uso di un unico kernel condiviso consente guadagni in efficienza e prestazioni, dall'altro significa che una singola vulnerabilità può permettere la fuga dal container.
gVisor è un kernel applicativo per 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; sfrutta invece le funzionalità esistenti del kernel host e gira come un normale processo. In altre parole, gVisor implementa Linux tramite Linux.
gVisor non va confuso con tecnologie e strumenti progettati per indurire i container contro minacce esterne, fornire ulteriori controlli di integrità o limitare l'ambito di accesso di un servizio. Bisogna sempre prestare attenzione a quali dati vengono resi disponibili a un container.
La documentazione utente e l'architettura tecnica, incluse le guide di avvio rapido, sono disponibili su gvisor.dev.
gVisor compila su x86_64 e ARM64. Altre architetture potrebbero diventare disponibili in futuro.
Ai fini di queste istruzioni, bazel e le altre dipendenze di build sono racchiusi in un container di build. È possibile usare bazel direttamente, oppure digitare make help per i target standard.
Assicurati che le seguenti dipendenze siano installate:
Crea 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"
Usare Bazel direttamente non è consigliato a causa dell'overhead aggiuntivo, ma per iniziare:
Dopo aver configurato le dipendenze, l'uso di Bazel è simile al Makefile:
bazel build -c opt //debian:gvisor-release-tar
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 in cui scriviamo, gVisor richiede bazel 8, che puoi installare tramite homebrew:
brew install bazel@8
# Puoi quindi eseguire i test, ad es.:
$(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 usa bazel per compilare e gestire le dipendenze. Per comodità viene mantenuto un ramo sintetico go compatibile con gli strumenti go standard. È utile per pacchetti e librerie esterne che dipendono dai sottopacchetti di gVisor (ad es. networking nello spazio utente tramite Netstack) per importare codice Go di gVisor nei propri progetti Go.
Seleziona questo ramo esplicitamente con la query del ramo 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 ramo non sono supportate. gVisor e runsc richiedono diversi binari (alcuni dei quali non sono nemmeno scritti in Go) per funzionare. Il ramo go è supportato al meglio delle possibilità, e lo sviluppo diretto su questo ramo non è supportato. Lo sviluppo dovrebbe avvenire sul ramo master, che viene poi rispecchiato nel ramo go.
Vedi GOVERNANCE.md per informazioni sulla governance del progetto.
La mailing list gvisor-users e la mailing list gvisor-dev sono buoni punti di partenza per domande e discussioni.
Vedi SECURITY.md.
Vedi Contributing.md.