--- id: e62d78ef5850c982dbddc9d3ff9134ae author: Lemon Mint title: 'gvx: Linux Containers, Docker és Kubernetes futtatása egyetlen unprivileged folyamatban' description: 'Az gvx technikai áttekintése: egy biztonságmegerősített, többplatformos konténerfuttató és Go SDK, amely a gVisor felhasználói térben működő kernelre épül, és Linux-konténereket, Docker-in-Docker környezeteket, valamint többcsomópontos, magas rendelkezésreállású (HA) Kubernetes-fürtöket futtat biztonságosan egyetlen, privilégiumok nélküli folyamatban Windows, macOS és Linux rendszereken.' language: hu date: 2026-11-06T12:02:56.008516536Z path: /blog/posts/gvx-cross-platform-linux-containers-z48916d01 go_package: z.gfire.dev/gvx go_repourl: https://github.com/gfire-sigs/gvx.git category: lowlevel --- ## Bevezetés: Biztonsággal megerősített konténerek root jogosultság és host daemonok nélkül Linux konténerek, `docker build` vagy Kubernetes futtatása fejlesztői gépen, CI futtatón vagy többbérlős felhőcsomóponton általában kényelmetlen biztonsági kompromisszumra kényszerít: - **Linuxon** a szabványos OCI futtatókörnyezetek (`runc`, `crun`, `runsc`) vagy `root` jogosultságot igényelnek, vagy a host `/var/run/docker.sock` elérhetővé tételét, vagy `--privileged` (`CAP_SYS_ADMIN`) használatát, vagy olyan felhasználói névtereket (`unshare(CLONE_NEWUSER)`), amelyek kibővítik a host kernel támadási felületét. - **Windowson** és **macOS-en** a konténermotorok (`Docker Desktop`, `Podman Machine`, `Lima`, `OrbStack`) teljes Linux virtuális gépkernelt indítanak a WSL2, a Hyper-V vagy a `Virtualization.framework` keretében, és ebben a virtuális gépben állandó háttérfolyamatot (daemont) futtatnak. **[gvx](https://github.com/gfire-sigs/gvx)** (a `rungv` CLI és a `z.gfire.dev/gvx/pkg/gvx` Go SDK) **biztonságos, nulla jogosultságot igénylő alternatívát** nyújt. A Google **gVisor** felhasználói térben futó Linux kerneljének (`Sentry`) és felhasználói térben futó hálózati veremének (`netstack`) upstreamből követhető elágazásaként felépítve a `gvx` módosítatlan `linux/amd64` és `linux/arm64` ELF64 binárisokat és OCI konténereket futtat közvetlenül **egyetlen, jogosultság nélküli, saját magát zároló host folyamaton belül** Windowson, macOS-en és Linuxon. > **Biztonsági garancia (háromgyűrűs mélységi védelem)**: A `gvx` soha nem gyengíti a host operációs rendszer biztonsági határait, soha nem telepít kernel-illesztőprogramot, és soha nem igényel `root`, `sudo`, `--privileged` jogot a hoston vagy `CLONE_NEWUSER` használatát. Mielőtt egyetlen vendég utasítást végrehajtana, a `gvx` lezárja saját host folyamatát Windows Restricted Tokens és Job Objects, macOS Seatbelt (`deny default`), vagy Linux `PR_SET_NO_NEW_PRIVS` + BPF `seccomp` segítségével. Minden vendég rendszerhívás, a virtuális `UID 0` jogosultságok, a csatolások (`VFS2`) és a hálózati táblák (`netstack`) szigorúan a memóriabiztos Go `Sentry` kernelen belül vannak korlátozva. | Futtatókörnyezet | Host OS | Hideg indítás | Memórialábnyom | Admin vagy `sudo` szükséges | Háttérben futó VM daemon | Közvetlen OCI image futtatás | | :------------------------- | :---------------------------------------------------- | -------------: | -------------: | :-------------------------- | :----------------------- | :--------------------------- | | **`gvx` (`whpx` / `hvf`)** | Windows (`amd64`, `arm64`) és macOS (`arm64`) | `~20 ms` | `~30 MiB` | Nem | Nem | Igen | | **`gvx` (`systrap`)** | Windows (`amd64`, `arm64`) és Linux (`amd64`, `arm64`) | `~25 és 65 ms között` | `~31 MiB` | Nem | Nem | Igen | | **WSL2 / Docker Desktop** | Windows és macOS | `800 és 2500 ms között` | `> 512 MiB` | Igen (kezdeti beállítás) | Igen | Daemon szükséges | | **QEMU (teljes rendszer)** | Windows és macOS | `1500 és 4000 ms között` | `> 256 MiB` | Nem | Nem | Lemezkép szükséges | Linux VM kernel nem indul el Windowson vagy macOS-en. Nem fut háttérfolyamat a hoston. A host operációs rendszeren nincs szükség `root`, `sudo`, felhasználói névterekre (`CLONE_NEWUSER`), `mount(2)`, `TUN`/`TAP` illesztőprogramokra vagy `CAP_NET_ADMIN` jogosultságokra. Ebben a jogosultság nélküli folyamatban a `gvx` futtatja a **Docker-in-Docker (`docker:dind`)**, a `docker build`, a `docker compose` és a **többcsomópontos, magas rendelkezésre állású Kubernetes (`k3s` beágyazott `etcd`-vel és `Calico` CNI-vel)** rendszert. --- ## Konténer életciklus és háromgyűrűs host-lezárás Minden `gvx` sandbox egy jogosultság nélküli host folyamaton belül fut, és háromfázisú életciklust érvényesít: előzetesen megnyitja az összes szükséges host fájlleírót és socketet, lezárja a host OS folyamatát a `pkg/hostlockdown` segítségével, majd belép a folyamaton belüli `Sentry` végrehajtási ciklusba. ![gvx konténer életciklus és host önlezárás](/assets/images/gvx/gvx-lifecycle-lockdown.png) Mielőtt a vezérlést átadná az első vendég utasításnak, a `gvx` előzetesen megnyitja a gyorsítótárazott `.erofs` image réteg-fájlleírókat, az `.ext4` kötetfájl-fájlleírókat, a `/workspace` `*os.Root` kezelőt és a host hálózati socketeket, majd meghívja a `hostlockdown.Apply()` függvényt: 1. **Windows NT (`lockdown_windows.go`)**: Meghívja az `AdjustTokenPrivileges` függvényt `SE_PRIVILEGE_REMOVED` jelzővel, hogy a jogosultságokat helyben eltávolítsa, majd `DISABLE_MAX_PRIVILEGE` korlátozott megszemélyesítési tokent köt Low integritási szinten (`S-1-16-4096`), a folyamatot egy névtelen Job Objecthez rendeli `JOB_OBJECT_LIMIT_ACTIVE_PROCESS = 1` beállítással (ami blokkolja bármely gyermekfolyamat létrehozását), és a `SetProcessMitigationPolicy` segítségével engedélyezi a `DisallowWin32kSystemCalls = 1` beállítást. 2. **macOS XNU (`lockdown_darwin.go`)**: Beállítja az `RLIMIT_NPROC = 0` értéket, és alkalmaz egy Seatbelt profilt (`sandbox_init_with_parameters`), amely a `(version 1)(deny default)` profilból indul, és blokkolja a `process-fork`, `process-exec*` műveleteket és minden új host fájlmegnyitást. 3. **Linux (`lockdown_linux.go` + `pkg/gvx/syscallfilter_linux.go`)**: Beállítja a `PR_SET_NO_NEW_PRIVS` értéket, és telepíti a Sentry BPF `seccomp` engedélyezési listáját minden szálra (`SECCOMP_FILTER_FLAG_TSYNC`), explicit `EPERM` szabályokkal a `execve`, `execveat`, `clone`, `openat` és `socket` hívásokhoz. --- ## Platformfüggetlen rendszerhívás-elfogás és 4 KB-os lapozás (`pkg/sentry/platform`) A Linux ELF64 binárisok 4 KB (`0x1000`) memórialap-szemcsézettséget feltételeznek a `mmap(MAP_FIXED)` szegmensleképezésekhez. Ezzel szemben a Windows `VirtualAlloc` és `MapViewOfFile3` 64 KB (`0x10000`) igazítást kényszerít ki, az Apple Silicon macOS (`darwin/arm64`) pedig 16 KB (`0x4000`) host lapokat használ. Ráadásul minden operációs rendszernek más mechanizmusra van szüksége ahhoz, hogy elfogja a Linux `SYSCALL` (`amd64`) és `SVC #0` (`arm64`) utasításokat Linux virtuális gép indítása nélkül. A `gvx` mindkét problémát megoldja négy végrehajtási háttérrendszeren keresztül, amelyek a `pkg/sentry/platform.Context` interfészt valósítják meg: ![gvx platform rendszerhívás-elfogás és 4KB-os lapozás mechanikája](/assets/images/gvx/gvx-platform-syscalls.png) ### 1. Windows hardveres motor: `platform/whpx` (`WinHvPlatform.dll`) `windows/amd64` és `windows/arm64` esetén a `platform/whpx` könnyű hypervisor partíciót hoz létre a `WHvCreatePartition` segítségével anélkül, hogy vendég OS kernelt indítana: - **64 KB-ról 4 KB-ra váltó leválasztó**: A `whpx` a `pgalloc.MemoryFile` minden 64 MiB-os arénáját egyszer regisztrálja a partícióval a `WHvMapGpaRange` segítségével. A későbbi `MapFile` és `Unmap` hívások csak a partíción belüli vendég lapTáblákat módosítják, így a Windows 64 KB-os allokációs szemcsézettsége ellenére pontos 4 KB-os `R/W/X` jogosultságokat érvényesítenek. - **Nulla API-s regiszterkiegyenlítés a `CommPage` segítségével**: - `amd64` esetén a vendég Ring-3 `SYSCALL` egy partíción belüli Ring-0 `MSR_LSTAR` csonkba (`stubgen_x86.go`) lép, amely a gyorsúti rendszerhívás GPR-jait (`RAX, RDI, RSI, RDX, R10, R8, R9, RIP, RSP`) egy megosztott 4 KB-os `CommPage`-be menti, majd végrehajtja a `HLT` utasítást, hogy kilépjen a `WHvRunVirtualProcessor` függvényből. - `arm64` esetén a vendég EL0 `SVC #0` az EL1 vektorokba lép (`stubgen_a64.go`), a `X0..X8, SP_EL0, ELR_EL1, PSTATE` regisztereket a `CommPage`-be menti, majd a nulla GPA-ról, amelyhez nincs memória rendelve, tölt be adatot, hogy memóriakilépést váltson ki a Sentryhez való visszatéréshez. ### 2. macOS hardveres motor: `platform/hvf` (`Hypervisor.framework`) Apple Silicon (`darwin/arm64`) gépeken a `platform/hvf` a konténerszálakat a `Hypervisor.framework` vCPU-jaiban (`hv_vm_create`, `hv_vcpu_run`) futtatja: - **Kétszintű, 4 KB-os lapokon át történő 16 KB-os MMU fordítás**: A Stage-2 (`hv_vm_map`) egyszer, 16 KB-os host lap szemcsézettséggel képezi le az 1 GiB-os memóriafájl-darabokat az Intermediate Physical Address (IPA) térbe, `HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC` jogosultságokkal. A vCPU-n belül az EL1 `bluepill` csonk (`bluepill_arm64.go`) beállítja a `TCR_EL1.TG0 = 0b00` értéket (4 KB-os granula) a `TTBR0_EL1`-ben, és pontos `R-X` vagy `RW-` (`UXN=1`) jogosultságú 4 KB-os Stage-1 lapTábla-bejegyzéseket tölt fel. Mivel az ARM64 MMU a Stage-1 és Stage-2 jogosultságok metszetét érvényesíti, a hardver pontos 4 KB-os határokon csapdába ejti a jogosultsági hibákat. - **Rendszerhívás-csapda**: A vendég EL0 `SVC #0` az EL1 `VBAR_EL1`-hez kerül, a regisztereket a megosztott 4 KB-os `CommPage`-be menti, és végrehajtja a `HVC #0` utasítást, hogy a `hv_vcpu_run` függvényből visszatérjen a Go Sentry szálhoz. ### 3. Windows felhasználói módú tartalék: `platform/systrap` (`winsystrap`) Ha a hardveres virtualizáció nem érhető el (például beágyazott felhőgépeken), a `winsystrap` a vendégkódot felhasználói módban futtatja `windows/amd64` és `windows/arm64` esetén: - **Hardveres `CR3` / `TTBR0_EL1` izoláció**: A vendégszálak izolált csonk-alfolyamatokban futnak, amelyeket egy generált 1 KB-os végrehajtható fájlból (`stubimage_xplat.go`) indítanak, és amelyeket Low-Integrity token és Job Object korlátoz. - **Helyben történő bináris javítás és `winSysmsg` IPC**: `amd64` esetén a javító (`patcher_amd64_xplat.go`) a 2 bájtos `syscall` (`0f 05`) utasításokat 5 bájtos `jmp rel32` ugrásokra cseréli (vagy `CC 90` töréspont-csapdákra, ha nem áll rendelkezésre 5 bájtos ablak), amelyek egy gyorsúti szigetre mutatnak. `arm64` esetén az `svc #0` utasítást egy `B` elágazással javítja egy szigetrés felé. A sziget a regisztereket a megosztott `winSysmsg` lapra menti, és a `WaitOnAddress` és `WakeByAddressSingle` segítségével szinkronizál a Sentryvel, míg a nem javított csapdák és lapHibák egy Windows Debug Objecten (`WaitForDebugEventEx`) állnak meg. ### 4. Linux felhasználói módú motor: `platform/systrap` `linux/amd64` és `linux/arm64` esetén a `systrap` olyan vendégszálakat (`sysmsg`) futtat, amelyek a vendég rendszerhívásokat a `SECCOMP_RET_TRAP` (`SIGSYS`) segítségével csapdába ejtik, és a `syscall` helyeket bináris javítással egy `SYS_FUTEX`-szel szinkronizált, megosztott memóriás trampolinba (`sysmsg`) irányítják, míg egy csonk `syscallThread` (`syscall_thread.go`) a `SECCOMP_RET_USER_NOTIF` (`_RUN_SECCOMP_LOOP`) segítségével hajtja végre a címtér-műveleteket (`mmap`, `munmap`, `clone`). Amikor a `gvx` egy külső `gVisor` (`runsc`) sandboxon belül fut, ahol az egyetlen `SECCOMP_FILTER_FLAG_NEW_LISTENER` hely `EBUSY` értéket ad vissza, a `gvx` automatikusan átvált a `syscallThread`-re egy megosztott memóriás futex ciklusra (`_RUN_SYSCALL_LOOP`), ahogy azt a [sorozat 3. része](/blog/posts/docker-in-docker-inside-gvisor-with-gvx-z48916d03) részletezi. --- ## Hogyan képezi le a `gvx` a vendég Linux rendszerhívásokat virtuális alrendszerekre és host handle-ökre Miután a platformmotor elfogta a vendég `SYSCALL` (`amd64`) vagy `SVC #0` (`arm64`) utasítást, és a vendég regisztereket a 4 KB-os megosztott lapra (`CommPage`, `sysmsg` vagy `winSysmsg`) írta, a vezérlés visszatér a Go `Sentry` task goroutine-hoz (`pkg/sentry/kernel/task_syscall.go`). Ahelyett, hogy a Linux rendszerhívásokat a mögöttes host OS kernelnek továbbítaná, a `Task.doSyscall()` elmenti az eredeti regiszterállapotot (`SyscallSaveOrig()`), kiértékeli a vendégen belüli BPF `seccomp` szűrőket és `ptrace` megállásokat, majd a `linux.AMD64` vagy `linux.ARM64` (`pkg/sentry/syscalls/linux/linux64.go`, mintegy 370 Linux rendszerhívást lefedve) segítségével a rendszerhívás számát négy belső tartományba irányítja: ![Hogyan képezi le a gvx a vendég Linux rendszerhívásokat alrendszerekre és a host OS-re](/assets/images/gvx/gvx-syscall-mapping.png) | Rendszerhívás-tartomány | Reprezentatív vendég Linux rendszerhívások | Belső `gvx` alrendszer (`pkg/sentry`) | Host OS határinterakció (`hostlockdown` után) | | :--- | :--- | :--- | :--- | | **A. Folyamat, névtér, csatolás és szinkronizáció** | `clone`, `execve`, `unshare`, `setns`, `mount`, `umount2`, `pivot_root`, `setuid`, `capset`, `futex`, `epoll_wait`, `pipe2` | `kernel.Task`, virtuális hitelesítő adatok, futex tábla és memóriabeli `VFS2` (`procfs`, `sysfs`, `cgroupfs` v2, `tmpfs`, `overlayfs`) | **Nulla host rendszerhívás** (100%-ban memóriabeli Go állapot; a host OS számára teljesen láthatatlan) | | **B. Virtuális memória (`MM`)** | `mmap`, `munmap`, `mremap`, `mprotect`, `brk`, `madvise`, `memfd_create` | `mm.MemoryManager` (4 KB-os VMA fa) és `pgalloc.MemoryFile` | Kétirányú 4 KB-os lapTábla-frissítések a `WHvMapGpaRange`, a `hv_vm_map` + `TTBR0_EL1`, vagy csonk `mmap`/`mprotect` hívásokon keresztül | | **C. Fájl és tárolás (`VFS2`)** | `openat`, `pread64`, `pwrite64`, `getdents64`, `statx`, `renameat2`, `setxattr`, `mknod`, `inotify_add_watch` | `vfs.VirtualFilesystem` csatolási táblázat útválasztója (`fsimpl/erofs`, `fsimpl/ext4lite`, `fsimpl/hostfs` v2) | Kétirányú `pread`/`pwrite` egyetlen rögzített `.erofs` FD-n vagy 1 `.ext4` FD-n, vagy hatókörön belüli relatív bejárások a `*os.Root`-on | | **D. Hálózat és Netfilter** | `socket`, `bind`, `listen`, `connect`, `sendmsg`, `recvmsg`, `netlink`, `setsockopt(IPT_SO_SET_REPLACE)` | Felhasználói térbeli `pkg/tcpip` (`lo`, `eth0`, `docker0`, `veth`, `vxlan`, `wireguard`, `ipset`, `iptables-legacy`) | A sandboxon belüli forgalom **nulla host rendszerhívást** használ; a külső forgalom `net.Dial`/`net.Listen` (`-net=nat`) hívásokra vagy 1 UDP socketre (`-net=wg`) képeződik le | Amikor a kezelő `(rval, ctrl, err)` értéket ad vissza, a `Task.doSyscallInvoke()` minden hibát negatív Linux `errno` értékké alakít (`-ExtractErrno(err, sysno)`), visszaírja a visszatérési értéket a megosztott regiszterlapra (`amd64`-on `RAX`, `arm64`-on `X0`), és folytatja a vendég végrehajtását. --- ## Tárolás (`VFS2`) és kétsávos felhasználói térbeli hálózat (`netstack`) Minden vendég fájl- és hálózati művelet a Go `Sentryn` belül történik, három `VFS2` fájlrendszeren és két `pkg/netbackend` sávon keresztül: ![gvx VFS2 tárolómotorok és kétsávos netstack](/assets/images/gvx/gvx-storage-netstack.png) | Tárolómotor | Csatolási szerepe a `gvx`-ben | Mögöttes host erőforrás | Host `openat` / `NtCreateFile` hívások futásidőben | Windows Defender (`WdFilter.sys`) fájlonkénti vizsgálatai | | :--- | :--- | :--- | ---: | ---: | | **`fsimpl/erofs`** | Csak olvasható OCI image alsó rétegei | Rétegenként egy `.erofs` fájl | `0` | `0` | | **`fsimpl/ext4lite`** | Névvel ellátott kötetek (`-v name:/path`) | Kötetenként egy `.ext4` fájl | `0` | `0` | | **`fsimpl/hostfs` v2** | Host munkaterület (`-workspace`, `-v /host:/guest`) | Rögzített `*os.Root` host könyvtár | Gyorsítótár nélküli megnyitásonként `O(depth)` | Host fájlonként lezáráskor `1` | ### Miért fontos az `ext4lite` Docker, adatbázisok és csomagkezelők számára Tízezer számra menő konténerfájlok kibontása vagy írása közvetlenül Windows NTFS-re vagy macOS APFS-re antivírus minifilter vizsgálatokat (`WdFilter.sys`), kis- és nagybetű-ütközéseket és hiányzó POSIX bővített attribútumokat eredményez. A `pkg/sentry/fsimpl/ext4lite` egy tisztán Go nyelvű `ext4` fájlrendszert valósít meg egyetlen előzetesen megnyitott host fájlban (`%LOCALAPPDATA%\gvx\cache\volumes\.ext4` Windowson, `~/Library/Caches/gvx/volumes/.ext4` macOS-en vagy `~/.cache/gvx/volumes/.ext4` Linuxon), a következőkkel: - **4 KiB-os blokkok és 16 MiB-os dinamikus blokkcsoportok (`meta_bg`)**: Dinamikusan nő anélkül, hogy ritka fájl allokációs torlódás lépne fel (`fallocate` Linuxon, `fcntl(F_PREALLOCATE)` macOS-en, `FileAllocationInfo` Windowson), és tisztán leválasztáskor tömöríti a használaton kívüli végső csoportokat. - **JBD2 rendezett módú napló (inode 8)**: Atomi tranzakció-véglegesítés CRC-32 ellenőrző összegekkel és visszavonási blokkokkal, valamint `fsckLite` helyreállítás. - **`overlayfs` felső réteg támogatás**: Implementálja a `trusted.overlay.*` és `security.capability` bővített attribútumokat, a karakter-eszköz törléseket (`0:0`), a `d_type` könyvtárbejegyzés-jelentést és a `RENAME_EXCHANGE` műveletet. --- ## Gyakorlati munkafolyamatok: Docker Engine, Kubernetes (`k3s` + `Calico`) és Go SDK ### A `rungv` telepítése: SLSA-attesztált előre fordított kiadások vagy `go install` Letölthet egy előre fordított `rungv` archívumot a `linux/amd64`, `linux/arm64`, `darwin/arm64`, `windows/amd64` vagy `windows/arm64` platformokhoz a [GitHub Releases](https://github.com/gfire-sigs/gvx/releases) oldalról (mindegyiket a SLSA kiadási folyamat építette, Sigstore eredetigazoló csomaggal és `SHA256SUMS` fájllal), vagy közvetlenül telepítheti a forráskódból a `go install` segítségével: ```sh # A lehetőség: Előre fordított kiadás letöltése és a SLSA build eredet ellenőrzése gh attestation verify rungv-v0.2.0-linux-amd64.tar.gz --repo gfire-sigs/gvx \ --signer-workflow gfire-sigs/gvx/.github/workflows/release.yml \ --source-ref refs/tags/v0.2.0 --deny-self-hosted-runners shasum -a 256 -c SHA256SUMS --ignore-missing tar -xzf rungv-v0.2.0-linux-amd64.tar.gz # B lehetőség: Közvetlen telepítés Go-val (Linux / Windows) CGO_ENABLED=0 go install z.gfire.dev/gvx/cmd/rungv@latest ``` > macOS-en (`darwin/arm64`) az előre fordított kiadási archívum már alá van írva a `com.apple.security.hypervisor` jogosultsággal (az `xattr -d com.apple.quarantine rungv` parancs törli a böngészős karantént). Ha helyben, `go install` vagy `go build` segítségével építi a binárist macOS-en, írja alá a bináris fájlt a `codesign --sign - --entitlements entitlements.plist --force $(which rungv)` paranccsal. ### 1. Jogosultság nélküli Docker Engine futtatása (`docker:dind`) A [`docs/docker-engine.md`](https://github.com/gfire-sigs/gvx/blob/main/docs/docker-engine.md) útmutatót követve egy módosítatlan `docker:dind` konténert futtathat a `rungv` alatt Windowson, macOS-en vagy Linuxon, és a host `docker` CLI-vel vezérelheti: ```sh # 1. Hozza létre a host könyvtárat az átirányított Unix socket számára mkdir -p ~/.gvx # 2. Indítsa el a docker:dind konténert egy gvx sandboxban ext4lite kötettel rungv run \ -p unix:~/.gvx/docker.sock:2375 \ -p 127.0.0.1:9000-9019:9000-9019 \ -v gvx-docker:/var/lib/docker \ -e DOCKER_TLS_CERTDIR= \ docker:dind --tls=false ``` Egy második terminálban irányítsa a host `docker` CLI-t a sandbox socketre: ```sh docker context create gvx --docker host=unix://$HOME/.gvx/docker.sock docker context use gvx docker info --format '{{.Driver}} {{.OperatingSystem}}' # Kimenet: overlayfs Alpine Linux ... (konténerizált) docker build -t myapp ./app docker compose up -d ``` ### 2. Kubernetes (`k3s` + `Calico`) futtatása jogosultság nélküli sandboxokban Mivel a `gvx` implementálja a `/dev/kmsg`, a `cgroup` v2 eszközt (`memory.max` OOM gyilkos és `cpu.max` sávszélesség-korlátozás), a `/proc/diskstats`, a `wireguard` és `vxlan` netlink eszközöket, az `ipset`-et és az `iptables-legacy`-t (`addrtype`, `conntrack`, `statistic`, `recent`), egy módosítatlan `rancher/k3s` image eléri a `Ready` állapotot egyetlen `rungv` folyamaton belül: ```sh mkdir -p ~/.gvx/k3s rungv run \ -e IPTABLES_MODE=legacy \ -p 127.0.0.1:6443:6443 \ -p 127.0.0.1:30000-30019:30000-30019 \ -v k3s:/var/lib/rancher \ --mount type=bind,src=$HOME/.gvx/k3s,dst=/output \ rancher/k3s:v1.31.4-k3s1 server \ --disable=traefik,servicelb \ --write-kubeconfig=/output/kubeconfig.yaml \ --write-kubeconfig-mode=644 ``` Több `gvx` csomópontot is csatlakoztathat WireGuard-on keresztül (`flannel-backend=wireguard-native` vagy `wg0` háló) beágyazott `etcd` magas rendelkezésre állással, vagy futtathatja a **Calico**-t (`calico-vxlan.yaml` a `FELIX_IPTABLESBACKEND=Legacy` beállítással), hogy a Kubernetes `NetworkPolicy` szabályokat teljes egészében felhasználói térben érvényesítse. ### 3. Linux konténerek beágyazása Go-ba a `z.gfire.dev/gvx/pkg/gvx` csomaggal Go alkalmazások külső konténerdémon nélkül, közvetlenül beágyazhatnak Linux konténereket: ```go package main import ( "context" "fmt" "os" "z.gfire.dev/gvx/pkg/gvx" ) func main() { ctx := context.Background() sb, err := gvx.New(ctx, gvx.Config{ Platform: gvx.PlatformAuto, NetworkMode: gvx.NetModeNAT, OCIImage: "alpine:3.20", WorkspacePath: "./repo", Argv: []string{"/usr/bin/git", "status"}, Stdout: os.Stdout, Stderr: os.Stderr, }) if err != nil { fmt.Fprintf(os.Stderr, "init sandbox: %v\n", err) os.Exit(1) } defer sb.Close() exitCode, err := sb.Run(ctx) if err != nil { fmt.Fprintf(os.Stderr, "run sandbox: %v\n", err) os.Exit(1) } os.Exit(exitCode) } ``` --- ## További olvasnivaló ebben a sorozatban 1. **[gvx: Linux konténerek, Docker és Kubernetes futtatása egyetlen jogosultság nélküli folyamatban](/blog/posts/gvx-cross-platform-linux-containers-z48916d01)** (ez a bejegyzés) 2. **[Docker, docker build és docker compose futtatása root vagy felhasználói névterek nélkül](/blog/posts/run-docker-without-root-or-userns-gvx-z48916d02)**: Hogyan indítsuk el a `docker:dind` környezetet olyan lezárt sandboxokban, ahol a `sudo`, `unshare(CLONE_NEWUSER)`, `mount(2)` és `/dev/fuse` le van tiltva. 3. **[Docker-in-Docker futtatása gVisoron belül és beágyazott sandboxokban a gvx segítségével](/blog/posts/docker-in-docker-inside-gvisor-with-gvx-z48916d03)**: Miért hibásodik meg az `apt-get install docker.io` és a beágyazott `runsc` a `gVisor` belsejében öt kernelkorláton át, és hogyan futtatja a `gvx` a beágyazott `docker:dind` környezetet megosztott memóriás futex ciklussal. 4. **[Gyors, izolált Docker környezetek AI-ügynökök RL futtatásaihoz a gvx segítségével](/blog/posts/fast-docker-environments-for-agent-rl-rollouts-z48916d04)**: `SWE-bench` és ügynök-megerősítéses tanulási futtatások skálázása több száz párhuzamos, jogosultság nélküli `docker:dind` példánnyal és 100 milliszekundumos copy-on-write `.ext4` kötetvisszaállításokkal.