Google Cloud wprowadziło zarządzaną usługę GKE Agent Sandbox, podczas gdy projekt open-source kubernetes-sigs/agent-sandbox zapewnia tę samą funkcjonalność każdemu klastrowi Kubernetes. Oba rozwiązania oferują programistom jednorazowy kontener Linux dla agentów AI, pozostawiając resztę infrastruktury nienaruszoną.
Dlaczego kod generowany przez AI potrzebuje piaskownicy
Nowoczesne agenci AI nie tylko odpowiadają na pytania. Piszą skrypty, przeglądają sieć, wykonują polecenia powłoki, a nawet uruchamiają usługi internetowe. Ta moc tworzy lukę w bezpieczeństwie: generowany przez nich kod może być błędny, złośliwy lub zbyt agresywny. Agent, który uruchomi rm -rf / lub połączy się z wewnętrzną bazą danych bez uprawnień, może zagrozić całemu systemowi.
Sandbox izoluje każdego agenta w jego własnym kontenerze — małej, jednorazowej maszynie wirtualnej. Jeśli agent zacznie działać nieprawidłowo, szkody pozostaną wewnątrz tego kontenera; host i inne obciążenia pozostaną bezpieczne. Nowa oferta GKE oraz projekt prowadzony przez społeczność zmieniają ten pomysł w gotową do użycia usługę.
Dwa sposoby na uzyskanie sandboxa
- GKE Agent Sandbox – w pełni zarządzana usługa dla klientów Google Cloud.
kubernetes-sigs/agent-sandbox– projekt open-source dla dowolnego klastra Kubernetes.
Oba rozwiązania opierają się na tej samej architekturze rdzenia, zbudowanej na standardowych prymitywach Kubernetes.
Jak zbudowany jest ten system
| Komponent | Rola |
|---|---|
| Sandbox | Izolowany kontener uruchamiający kod agenta. Posiada stałą nazwę i opcjonalnie trwały magazyn danych (persistent storage). |
| SandboxTemplate | Schemat definiujący obraz kontenera i polityki bezpieczeństwa — „przepis” na nowe sandboxy. |
| SandboxClaim | Żądanie wysłane przez agenta (lub jego kontroler), aby uruchomić sandbox na podstawie konkretnego szablonu. |
| SandboxWarmPool | Pulę wcześniej utworzonych sandboxów, gotowych do natychmiastowego przydzielenia. Utrzymywanie „ciepłych” kontenerów pozwala uniknąć opóźnień związanych z pobieraniem obrazów i uruchamianiem nowego poda za każdym razem. |
Gdy agent potrzebuje środowiska, wysyła SandboxClaim. Kontroler sprawdza pulę ciepłych kontenerów (warm pool), wybiera wolny sandbox i przypisuje go do żądania. Jeśli pula jest pusta, tworzy nowy sandbox na podstawie szablonu; w przeciwnym razie przekazanie następuje w ciągu milisekund.
Parametry bezpieczeństwa, które możesz dostosować
- Domyślne blokowanie sieci (Default-deny networking) – Domyślnie sandbox nie ma dostępu do sieci wewnętrznej. Należy dodać jawne reguły, aby zezwolić na połączenia przychodzące lub wychodzące, co zapobiega przypadkowemu wystawieniu wewnętrznych usług na zewnątrz.
- Poziomy izolacji – Wybierz środowisko uruchomieniowe kontenerów (container runtime) odpowiadające Twojej tolerancji na ryzyko:
- Standardowe kontenery dla szybkości,
- gVisor dla dodatkowej warstwy izolacji w przestrzeni użytkownika (user-space), lub
- Kata Containers dla izolacji wspomaganej sprzętowo, która działa jak lekka maszyna wirtualna.
- SDK – Biblioteki klienta w językach Python i Go pozwalają programistom na programowe tworzenie, żądanie i niszczenie sandboxów, co pasuje do przepływu pracy w potokach (pipelines) sterowanych przez AI.
Kto odniesie korzyści, a kto może stawiać opór
Podsumowanie
Zapewnienie agentom AI własnego, jednorazowego środowiska Linux eliminuje największą niewiadomą w automatyzacji opartej na AI: ryzyko, że wygenerowany kod zniszczy hosta. Zarządzana usługa GKE Agent Sandbox od Google Cloud oraz projekt społecznościowy kubernetes-sigs/agent-sandbox sprawiają, że taka izolacja jest praktyczna zarówno w środowiskach cloud-native, jak i on-premise. Organizacje, które muszą balansować między zwinnością a bezpieczeństwem, mają teraz konkretne, natywne dla Kubernetes narzędzie, aby trzymać kod generowany przez AI w bezpiecznej „piaskownicy”.