Kubernetes’te agent’ları OpenShell ile istek düzeyinde sınırlamak

NVIDIA’nın başlattığı CNCF Sandbox projesi OpenShell, Kubernetes’te her yapay zekâ agent’ını kendi OpenShell sandbox’ında, SIG Apps’in Agent Sandbox kaynağı üzerinden çalıştırıyor. Yeni rehber, akışı Kubernetes 1.35, Cilium 1.20, Agent Sandbox v1.0.5, OpenShell 0.1.3 ve Kyverno 1.18.2 ile iki node’lu bir kind cluster’ında adım adım gösteriyor. Rehber, projeyi Google kökenli Agent Substrate ile de karşılaştırıyor.

OpenShell nedir ve nerede kullanılır?

OpenShell, yapay zekâ agent’larını sandbox içinde çalıştıran açık kaynak bir runtime’dır. Sandbox dışındaki bir supervisor, agent’ın hangi dosyalara, ağ hedeflerine ve API anahtarlarına erişeceğine karar verir. Kubernetes backend’i SIG Apps’in Agent Sandbox kaynağını kullanır. Benzer alanda çalışan bir diğer CNCF projesi Agent Substrate’tir.

Agent’larınız gerçek API anahtarıyla production sistemlerine bağlanıyorsa NetworkPolicy’ye ek bir katman gerekir. NetworkPolicy “bu Pod api.github.com’a 443’ten gidebilir” der, “curl issue okuyabilir ama açamaz” diyemez. OpenShell bu ayrımı supervisor üzerinde binary, host, port ve HTTP method düzeyinde yapıyor ve kuralı çalışan sandbox’ta restart olmadan değiştiriyor.

Yeni bir scheduler kurmanız gerekmiyor. Agent’lar Pod, Service, PVC, Secret ve NetworkPolicy olarak görünüyor. RBAC, Kyverno, audit log ve kubectl bildiğiniz gibi çalışıyor.

Bir OpenShell sandbox’ının yaşam döngüsü

• Client isteği mTLS ile gateway’e gönderiyor, Kubernetes API ile hiç konuşmuyor.
• Gateway kaydı Provisioning aşamasında saklıyor. Doğruluk kaynağı Pod değil, bu kayıt.
• Driver önce iki NetworkPolicy kuruyor: workload Pod’larına hiç egress yok, ingress yalnızca supervisor’dan TCP 5500 üzerinden.
• Agent Sandbox workload Pod’unu ve /sandbox PVC’sini oluşturuyor, scheduling gate Pod’u bekletiyor.
• Supervisor Pod kalkıyor, policy’yi alıyor. Agent’ın komutu, filesystem ve process kontrolleri doğrulanmadan başlamıyor.

Kubectl ile Pod’a elle müdahale etmek yerine her işlemi openshell CLI üzerinden yapın; sandbox’ın durumu gateway kaydında tutuluyor.

Kurulumdan önce iki kontrol

İlki CNI. Demo, egress NetworkPolicy uygulayabilmek için kindnet yerine Cilium kuruyor. CNI’niz egress kuralını uygulamıyorsa workload Pod’u için yazılan “hiç egress yok” kuralı kâğıt üzerinde kalır. O durumda ağ izolasyonu yalnızca container içindeki socket ve DNS kontrollerine yaslanır.

İkincisi mutating webhook’lar. Driver, admission sonrası Pod’u geri okuyor ve non-root UID ile GID, eklenmiş capability olmaması, RuntimeDefault seccomp, host namespace ve ServiceAccount token olmaması, beklenen label ve volume’ları kontrol ediyor. Bir webhook bunlardan birini değiştirirse creation düşüyor. Volume veya label ekleyen bir sidecar (yardımcı container) injector’ı ya da Kyverno mutate kuralı bu sınıfa giriyor. Sandbox namespace’ini bu webhook’lardan hariç tutun.

kubectl get mutatingwebhookconfigurations
kubectl get networkpolicy -n <namespace>

Ölçek ve GitOps tarafındaki boşluklar

Proje v0.1.x aşamasında ve birkaç eksiği açıkça yazılı:

• Sandbox’lar yalnızca gateway API ile oluşuyor. CRD ve operator için openshell/#1719 açık. GitOps aracınızla sandbox’ları deklaratif yönetemezsiniz.
• Her agent için bir workload Pod ve bir supervisor Pod çalışıyor. Bin agent için iki bin Pod çalışır. Rehber bunun büyük ortamlarda iyi ölçeklenmeyebileceğini kabul ediyor ve RFC 0018’e yönlendiriyor.
• Sandbox kaynağında /scale subresource yok. HPA, KEDA ve VPA bir sandbox’ı hedefleyemiyor. Boyutu creation anında veriyorsunuz; demo bunu Kyverno ile default ve üst sınır koyarak yapıyor.
• Gateway’i birden fazla replica ile çalıştırmak harici PostgreSQL istiyor. HA planınıza bunu baştan ekleyin.
• Delete işlemi iki namespace NetworkPolicy’sini yerinde bırakıyor. Namespace temizliğini kendi script’inize koyun.

Hangi image’ın çalışacağı, sandbox’ın ne kadar büyüyeceği, hangi credential’ı alacağı ve OpenShell RBAC’ini kimin değiştireceği size bırakılmış. Bu dört noktayı admission policy olarak yazmadan pilot açmayın.

Agent Substrate ile seçim

Karar iş yükünüze bağlı. Kullanıcı başına bir asistan gibi çoğu zaman boşta duran binlerce agent’ınız varsa ve agent başı maliyet öndeyse Substrate’e bakın. Agent’larınız gerçek credential taşıyıp production’a ulaşıyorsa ve istek başına kontrol gerekiyorsa OpenShell daha uygun.

Görünürlük farkı da önemli. Substrate, actor ve egress policy’lerini PostgreSQL destekli kendi API’sinde tutuyor; admission control yalnızca worker pool’ları görüyor, agent’ları görmüyor. Substrate her actor için gVisor veya Cloud Hypervisor istiyor. OpenShell standart container üzerinde Landlock ve seccomp kullanıyor; güvenilmeyen agent’lar için daha sıkı bir RuntimeClass zorunlu tutabilirsiniz.

İki projenin birleşmesi henüz plan aşamasında. RFC 0012 isolation katmanını takılabilir backend’e çevirdi, Substrate backend önerisi (NVIDIA/OpenShell#3362) ise 11 Ekim itibarıyla açık ve maintainer yanıtı yok. Mimarinizi bu birleşime göre kurmayın.

Denemeye nirmata/demo-openshell repo’su ile kind üzerinde başlayın. Policy güncellemesinden sonra izin verilen ve reddedilen her isteği şu komutla görürsünüz:

openshell logs policy-demo --source sandbox