88 lines
2.8 KiB
Markdown
88 lines
2.8 KiB
Markdown
# gVisor
|
|
|
|
#kubernetes #security #sandbox #słownik
|
|
|
|
## Co to jest?
|
|
|
|
**gVisor** to projekt open-source od Google implementujący **user-space kernel** - warstwę pośrednią między kontenerem a kernelem hosta. Zamiast pozwalać kontenerowi na bezpośrednie wywołania systemowe (syscalls) do kernela hosta, gVisor przechwytuje je i obsługuje we własnym user-space kernelu o nazwie **Sentry**.
|
|
|
|
## Jak działa?
|
|
|
|
```
|
|
Bez gVisor:
|
|
Container → syscall → Host Kernel (współdzielony!)
|
|
|
|
Z gVisor:
|
|
Container → syscall → Sentry (user-space kernel) → ograniczone syscalls → Host Kernel
|
|
```
|
|
|
|
**Sentry** reimplementuje dużą część interfejsu Linux kernel (ponad 200 syscalls) w Go. Tylko niewielka liczba prawdziwych syscalls jest przekazywana do hosta.
|
|
|
|
## Kluczowe komponenty
|
|
|
|
| Komponent | Rola |
|
|
|-----------|------|
|
|
| **Sentry** | User-space kernel - obsługuje syscalls kontenera |
|
|
| **Gofer** | File server - pośredniczy w dostępie do systemu plików |
|
|
| **runsc** | OCI runtime - integruje się z containerd/runc |
|
|
|
|
## Dlaczego to ważne?
|
|
|
|
### Problem z tradycyjnymi kontenerami
|
|
Kontenery współdzielą kernel hosta. Exploit w kernelu (np. CVE w obsłudze syscalls) = ucieczka z kontenera = dostęp do hosta i wszystkich innych kontenerów.
|
|
|
|
### Rozwiązanie gVisor
|
|
- Kontener rozmawia z **Sentry**, nie z prawdziwym kernelem
|
|
- Nawet jeśli Sentry zostanie skompromitowany, ma ograniczony dostęp do hosta
|
|
- Powierzchnia ataku kernela zredukowana z ~400 syscalls do ~50
|
|
|
|
## Porównanie z alternatywami
|
|
|
|
| Technologia | Izolacja | Overhead | Kompatybilność |
|
|
|-------------|----------|----------|-----------------|
|
|
| Kontenery (runc) | Namespace + cgroups | ~0% | 100% |
|
|
| **gVisor** | User-space kernel | **5-10%** | ~95% (nie wszystkie syscalls) |
|
|
| [[Kata Containers]] | Lightweight VM | ~15-20% | ~99% |
|
|
| Pełna VM (KVM) | Hypervisor | ~30%+ | 100% |
|
|
|
|
## Ograniczenia
|
|
|
|
- **Nie wszystkie syscalls** są implementowane (np. niektóre ioctl)
|
|
- **Overhead I/O** - Gofer dodaje pośrednika do operacji plikowych
|
|
- **Networking** - netstack (własny stack sieciowy) może mieć różnice w zachowaniu
|
|
- **GPU** - ograniczone wsparcie dla GPU passthrough
|
|
|
|
## Użycie w Kubernetes
|
|
|
|
gVisor integruje się z K8s przez [[RuntimeClass]]:
|
|
|
|
```yaml
|
|
apiVersion: node.k8s.io/v1
|
|
kind: RuntimeClass
|
|
metadata:
|
|
name: gvisor
|
|
handler: runsc
|
|
```
|
|
|
|
Pod używający gVisor:
|
|
```yaml
|
|
spec:
|
|
runtimeClassName: gvisor
|
|
```
|
|
|
|
## Użycie w Sympozium
|
|
|
|
W Sympozium gVisor jest opcjonalną warstwą izolacji dla agent podów. Konfiguracja w [[AgentRun]] lub [[SympoziumInstance]]:
|
|
|
|
```yaml
|
|
agentSandbox:
|
|
enabled: true
|
|
runtimeClass: gvisor
|
|
```
|
|
|
|
Integracja via [[Agent Sandbox - gVisor i Kata]] (kubernetes-sigs/agent-sandbox).
|
|
|
|
---
|
|
|
|
Powiązane: [[Kata Containers]] | [[Agent Sandbox - gVisor i Kata]] | [[RuntimeClass]] | [[SecurityContext]]
|