- Terrarium, Pyodide tabanlı ve Cloud Run üzerinde dağıtılabilen, güvenilmeyen kodları düşük maliyetle ve kabul edilebilir gecikmeyle çalıştırmak için tasarlanmış bir Python sanal ortamıdır.
- Bu ortam, çağrı tabanlı bölümlendirme, birden fazla bilimsel kütüphaneyi destekleme ve sanal dosya sistemi aracılığıyla giriş ve çıkış dosyalarının işlenmesini sağlar.
- Mimari yapısı, kodu izole etmek için WebAssembly, Node.js, Docker ve Cloud Run'ı bir araya getiriyor, ancak istikrar ve hizmet sağlığı yönetimi sorunları tespit edildi.
- Kritik güvenlik açığı CVE-2026-5752, root ayrıcalıklarıyla kod yürütülmesine olanak tanıyor ve henüz bir yama planlanmadığı için, risk azaltma önlemlerinin ve alternatiflerin değerlendirilmesi önerilir.
Güvenilmeyen veya yapay zeka tarafından üretilen Python kodunu çalıştırmaktan bahsettiğimizde , en büyük zorluklardan biri bunu güvenli , hızlı ve altyapı maliyetlerini çok yüksek tutmadan nasıl yapacağımızdır. İşte bu bağlamda, Cohere AI tarafından geliştirilen ve özellikle Google Cloud Run üzerinde bulutta dağıtılan konteynerler içinde bu tür kodları barındırmak ve çalıştırmak için bir sanal alan olarak tasarlanmış bir çözüm olan Terrarium ortaya çıktı.
Bu yaklaşım, geliştiricilerin ve şirketlerin Terrarium'u kullanıcı kodunu veya LLM modellerini makul bir maliyetle ve oldukça iyi bir performansla dağıtmak için izole bir ortam olarak kullanmalarına olanak sağladı . Bununla birlikte, zamanla, sanal ortamın güvenliğindeki kritik kusurları ortaya çıkaran ve Terrarium'u gündeme getiren bir CVE tanımlayıcısına sahip olanlar da dahil olmak üzere çok ciddi güvenlik açıkları da gün yüzüne çıktı.
Teraryum nedir ve ne amaçla tasarlanmıştır?
Terrarium, özünde Python için izole edilmiş bir çalışma ortamıdır ve örneğin Google Cloud Run üzerinde dağıtılabilir bir Docker konteyneri olarak işlev görecek şekilde tasarlanmıştır . Ana amacı, potansiyel olarak tehlikeli veya bilinmeyen kodların (kullanıcı tarafından gönderilen komut dosyaları veya dil tarafından oluşturulan kod parçacıkları gibi) ana altyapıyı doğrudan riske atmadan dağıtılabileceği bir sanal alan sağlamaktır.
Projenin ardındaki felsefe, mevcut iş akışlarına kolayca entegre edilebilen, uygun fiyatlı ve düşük gecikmeli bir hizmet sunmaktır . Terrarium, HTTP istekleri aracılığıyla çağrılmak üzere tasarlanmıştır; yürütülecek Python kodunu (ve isteğe bağlı olarak girdi dosyalarını) gönderir ve oluşturulan dosyalarla birlikte yürütme sonuçlarını geri alır.
Pratikte bu, harici bir sistemin, bir API'nin veya hatta dahili bir aracın Python kodunun yürütülmesini Terrarium'a devredebileceği ve bu kodun kaynaklar, yürütme süresi ve izin verilen yetenekler konusunda net kurallarla nispeten sınırlı bir ortamda kalabileceği anlamına gelir.
Terrarium'un temel tasarım özelliklerinden biri, Node.js işlemi içinde yürütülen bir CPython'dan WebAssembly'ye dönüştürücü olan Pyodide'a dayanmasıdır . Bu yaklaşım, Python kodunun ana sistemde yerel olarak çalışmadığı, bunun yerine kapsüllenmiş bir yorumlayıcı içinde çalıştığı anlamına gelir ve teorik olarak izolasyonunu güçlendirir.
Sanal ortamın performansı, maliyetleri ve temel özellikleri
Terrarium'un en güçlü satış noktalarından biri , düşük işletme maliyetleri ve kabul edilebilir performansın birleşimiydi . Google Cloud Run'da gerçek dünya dağıtımlarında, tipik bir 2 GB bellek, 1 vCPU ve isteğe bağlı otomatik ölçeklendirme özelliğine sahip en az bir sürekli açık örnek içeren bir yapılandırmada, dahili açıklama aşamalarında bildirilen aylık maliyet yaklaşık 30 dolardı.
Hız açısından, açıklanan testler, Terrarium'un örneğin basit bir matplotlib grafiğinin 200 dpi çözünürlüğünde bir PNG görüntüsünü yaklaşık 900 ms çalışma süresinde veya bir SVG sürümünü yaklaşık 500 ms'de oluşturabildiğini göstermektedir. Bu süreler, hizmetin tipik çağrı döngüsü de dahil olmak üzere Cloud Run üzerinde barındırılan kod için geçerlidir.
Terrarium, performansın yanı sıra, çağrılar arasında tam bir bölümlendirme sunuyordu . Her çağrıdan sonra, sanal ortam tamamen yeniden oluşturuluyordu: Pyodide'nin sanal dosya sistemi, genel değişkenler, yüklenen kütüphaneler ve herhangi bir iç durum atılıyordu. Amaç, herhangi bir çağrının önceki bir yürütmeden veri veya bağlam devralmasını önlemek ve böylece bilgi sızıntısı riskini azaltmaktı.
Bir diğer önemli nokta ise, sağlam bir izolasyon hedeflenmiş olsa da, Cohere'ın sanal ortamın bütünlüğü konusunda mutlak garantiler sunmadığını açıkça belirtmesidir . Bu durum, koruma katmanlarına rağmen, özellikle WebAssembly ve Node.js ile entegrasyonu gibi karmaşık bir ortamda, zayıf noktaların keşfedilebileceği olasılığının bulunduğunu zaten ima ediyordu.
Terrarium, diğer servislerden kolayca kullanılabilmesi için tasarlandı: Cloud Run'da dağıtılan uç noktaya, yürütülecek kod ve (yapılandırma gerektiriyorsa) bir yetkilendirme belirteciyle birlikte bir HTTP isteği göndermeniz yeterli. Karşılığında, sonuçları ve varsa oluşturulan dosyaları base64 ile kodlanmış olarak içeren bir JSON dosyası alırsınız.
Pyodide'de dosya yürütme ve kütüphane desteği
Terrarium'un çekici özelliklerinden biri , giriş ve çıkış dosyalarıyla yerel olarak çalışabilme yeteneğiydi . API, istekteki Python koduyla birlikte herhangi bir türden birden fazla dosyanın eklenmesine izin veriyordu; bunlar, Pyodide'nin Python yorumlayıcısına sunduğu sanal dosya sistemine yerleştiriliyordu.
Çalıştırma sırasında, Python kodu bu dosyaları sanal ortam içinde yerel dosyalarmış gibi okuyabilir ve işleyebilir . Çalıştırma tamamlandıktan sonra, Terrarium oluşturulan veya değiştirilen tüm dosyaları toplar ve genellikle HTTP üzerinden sorunsuz aktarım için kodlanmış olarak istemciye yanıt olarak gönderir.
Kütüphane ekosistemi açısından, Pyodide tabanlı olan Terrarium, oldukça kapsamlı bir bilimsel ve veri analizi paketleri kümesini miras aldı . Doğrudan desteklenen paketler şunlardır: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy ve sqlite3 (sonuncusu varsayılan olarak etkinleştirilmemiştir, ancak gerekirse yükleme seçeneği mevcuttur).
Matplotlib özelinde bazı sınırlamalar vardı: plt.show() bu ortamda desteklenmiyordu , ancak aşırı yüksek çözünürlükler gibi kaynak kullanımını artıracak aşırı parametreler zorlanmadığı sürece, plt.savefig() ile görüntü oluşturma işlemi doğru çalışıyordu.
Bu kütüphane seti, Terrarium'u özellikle veri analizi, görselleştirme, makine öğrenimi modellerinin prototiplenmesi ve yapılandırılmış bilgilerin manipülasyonu gibi görevler için kullanışlı hale getirdi; tüm bunlar teorik olarak kontrol edilen bir sanal ortamda gerçekleştirildi.
İç mimari: izolasyon ve dağıtım katmanları
Terrarium'un mimarisi, saldırı yüzeyini azaltmak ve güvenilmeyen kodu olabildiğince izole etmek için tasarlanmış birkaç katmandan oluşmaktadır . İlk katman, sunucu görevi gören ve Pyodide'ı (yani WebAssembly'e derlenmiş CPython'u) yükleyen Node.js işlemidir.
Kullanıcı tarafından gönderilen Python kodu, ana sistemde doğrudan değil, WebAssembly ortamında ayrıştırılır, derlenir ve yürütülür . Bu yaklaşım, Pyodide'ın bellekte sanal bir dosya sistemi kullanması, ana diske doğrudan erişiminin olmaması ve geleneksel arka plan işleme yeteneklerine sahip olmaması nedeniyle kodun yapabileceklerini doğal olarak sınırlandırır.
En önemli kısıtlamalar arasında şunlar yer almaktadır: gerçek dosya sistemine erişim yok (sadece Pyodide'ın dahili sanal dosya sistemi), çoklu işlem ve iş parçacığı desteğinin tamamen yokluğu, alt işlem başlatma yeteneğinin olmaması, Node.js çalıştıran ana bilgisayarın belleğine erişim olmaması, çağrılar arasında durum paylaşımının olmaması (çünkü tüm ortam yeniden başlatılıyor) ve tasarım gereği ağa veya internete erişim olmaması . Bu son sınırlama, gelecekte gözden geçirilebilecek bir tasarım kararı olarak düşünülmüştü, ancak başlangıçta başka bir tartışma katmanı ekledi.
İzolasyonun ikinci katmanı, bulut dağıtımının kendisidir: Node.js işlemi , Google Cloud Run'da dağıtılan bir Docker kapsayıcısı içinde çalışır. Bu, yalnızca çalışma süresini ve kullanılabilir kaynakları sınırlamakla kalmaz, aynı zamanda varsayımsal bir sanal alan ihlali durumunda kodu çalıştıran kapsayıcıyı kuruluşun altyapısının diğer herhangi bir bölümünden ayırır.
Özetle, Terrarium'un orijinal tasarımı, Python yürütmesi için nispeten güvenli bir ortam oluşturmak amacıyla WebAssembly, Docker ve Cloud Run'ın bir kombinasyonuna dayanır ve bu ortamdan ana sisteme ve iç ağa kaçışı zorlaştıran ardışık engeller bulunur.
Yerel dağıtım, Docker dağıtımı ve Google Cloud Run dağıtımı
Terrarium'u geliştirme ortamında kullanmak için makinede Node.js'nin kurulu olması gerekiyordu . Bu gereksinim karşılandıktan sonra, olağan prosedür, proje bağımlılıklarını kurmak ve kod yürütme isteklerini işleyen fonksiyonla birlikte yerel sunucuyu çalıştırmaktan oluşuyordu.
Sunucu çalışır durumdayken, geliştiricilerin üretim ortamlarına dağıtım yapmadan önce sanal ortamın davranışını doğrulamalarına olanak tanıyan test dosyaları ve Python komut dosyaları göndermek için yerel uç noktaya istekler yapılabilirdi . Test dizinindeki tüm .py dosyaları üzerinde bir dizi test çalıştırmak için komut dosyaları mevcuttu, bu da ortam doğrulamasını basitleştiriyordu.
Konteynerleştirilmiş ortamlarda, Terrarium bir Docker imajı olarak oluşturulabilir ve bağımsız bir konteyner olarak çalıştırılabilir . Tipik talimatlar, oluşturma, çalıştırma ve durdurma adımlarının yanı sıra çalışan konteynerin tanımlayıcısını bulmak ve gerekirse manuel olarak yönetmek için komutları içeriyordu.
Terrarium, Google Cloud Run'a taşındığında, yapılandırılabilir kaynak ve eşzamanlılık parametrelerine sahip otomatik ölçeklendirmeli bir HTTP hizmeti olarak dağıtıldı. Performans, maliyet ve güvenlik arasında denge kurmak için bu değerlerin ayarlanması tavsiye edildi . Örneğin, yoğun iş yükleri için daha fazla CPU ve bellek tahsis edilebilir ve engellemeyi önlemek için örnek başına eşzamanlılık sınırlandırılabilir.
Terrarium için yapılandırıldığında Pyodide'ın ana Node.js işleminde çalıştığını belirtmek önemlidir . Bu, Python kodunuz özellikle kaynak yoğun hale gelirse veya karmaşık döngülere girerse, Node.js'nin diğer isteklere yanıt verme yeteneğini engelleyebileceği anlamına gelir. Pyodide, yürütmeleri kesintiye uğratmanın veya daha da izole etmenin gerekli olduğu senaryolar için Workers kullanımını önerir, ancak bu yaklaşım entegrasyonu karmaşıklaştırır ve bazı durumlarda matplotlib gibi kütüphaneler için desteği sınırlar.
Sağlık hizmeti yönetimi ve istikrar sorunları
Google Cloud Run'da yapılan dağıtımlarda karşılaşılan pratik zorluklardan biri, hizmet sağlığını izlemek ve çökmelerden kurtarma işlemlerini gerçekleştirmekti . Cloud Run, varsayılan olarak, Dockerfile'larda HEALTHCHECK kullanılarak tanımlanan sağlık kontrollerini doğrudan desteklemediğinden, küçük bir ek ayarlama yapılması gerekiyordu.
Olağan prosedür, Cloud Run hizmetini gcloud ile tanımlamayı ve yapılandırmayı service.yaml dosyasına aktarmayı içeriyordu. Bu YAML dosyası içinde, Cloud Run'ın hizmetin doğru şekilde yanıt vermeyi bıraktığı zamanı algılayabilmesi için kapsayıcı görüntüsüyle ilişkilendirilmiş bir livenessProbe yapılandırması ekleniyordu.
Yapılandırma değiştirildikten sonra, mevcut servis uygun gcloud komutuyla değiştirildi; böylece Cloud Run, konteynerin durumunu aktif olarak izleyecek ve canlı kontrol başarısız olursa yeniden başlatacaktı. Bu işlem, yeni bir servisin bu özel imajla ilk kez dağıtılması durumunda gerekliydi.
Saf Docker düzeyinde ek bir sınırlama daha vardır: Docker motorunun kendisi yalnızca HEALTHCHECK'e dayalı otomatik yeniden başlatmalar sunmaz . Ayrıca, konteyner içindeki PID 1'e sahip işlem özellikle korunmaktadır ve içeriden sonlandırılması o kadar kolay değildir. Bu nedenle, bazı ortamlarda, konteynerin sağlığını izleyen ve sorunlar tespit edildiğinde yeniden başlatmayı zorlayan docker-autoheal gibi üçüncü taraf araçların kullanımı düşünülmektedir.
Yürütme kararlılığıyla ilgili olarak, ekip özellikle ağır iş yüklerini işlerken Pyodide'da "RangeError: Maximum call stack size exceeded" gibi hataların sıklıkla ortaya çıktığını gözlemledi . Bu durum, matplotlib ile PNG oluşturmada çok yüksek dpi değerleri kullanıldığında veya özellikle karmaşık pandas işlemleri yürütülürken daha yaygındı ve WebAssembly ortamındaki yığın yönetiminde içsel sınırlamalara işaret ediyordu.
Terrarium'da kritik güvenlik açığı CVE-2026-5752.
Zamanla, Terrarium'da CVE-2026-5752 olarak tanımlanan ve CVSS ölçeğinde 9,3 olarak derecelendirilen kritik bir güvenlik açığı keşfedildi . Bu ciddiyet seviyesi, bu sanal ortamı kullanan sistemlerin güvenliği üzerinde potansiyel olarak çok yüksek etkiye sahip bir kusuru göstermektedir.
Bu güvenlik açığı, saldırganın ana işlemde root ayrıcalıklarıyla rastgele kod yürütmesi yapmasına olanak tanır . Saldırı vektörü, Pyodide WebAssembly ortamında kötü amaçlı prototip zinciri geçişine dayanır ve bu sayede sanal alan kısıtlamalarını etkili bir şekilde atlar.
En endişe verici nokta, bu güvenlik açığından yararlanmak için özel ayrıcalıklara veya ek kullanıcı etkileşimine gerek olmamasıdır . Sanal ortama kod enjekte edebilen bir saldırgan (örneğin, Terrarium kullanan bir araçtaki kod yürütme işlevini kullanarak), bu kusurdan yararlanarak kontrollü ortamdan kaçabilir.
Bu güvenlik açığı istismar edildiğinde, /etc/passwd veya diğer dahili konteyner kaynakları gibi hassas sistem dosyalarına yetkisiz erişime izin verebilir ve genel güvenlik yapılandırmasına bağlı olarak, aynı altyapıyı paylaşan ana bilgisayara veya diğer hizmetlere yetki yükseltmesine bile olanak sağlayabilir.
Bu durum, Terrarium'u kullanıcı kodu veya yapay zeka modeli yürütme ortamı olarak kullanan tüm kuruluşlar için önemli bir risk oluşturmaktadır . Bu sadece teorik bir güvenlik açığı değil, bir sanal ortam ihlalinin veri ifşasına, iç hizmetlerin tehlikeye atılmasına ve ağ içinde yatay harekete yol açabileceği bir senaryodur.
İşletmeler, geliştiriciler ve son kullanıcılar üzerindeki etkisi
Bu güvenlik açığının keşfi, güvenilmeyen Python kodunu çalıştırmak için Terrarium'u altyapılarına entegre eden tüm şirketleri ve geliştiricileri doğrudan etkiliyor . İş birliğine dayalı geliştirme araçları, öğrenme platformları, isteğe bağlı analiz hizmetleri veya yapay zeka tabanlı kod destek ürünleri, Terrarium'u çalışma zamanı katmanı olarak kullanıyorlarsa risk altında olabilirler.
Son kullanıcının bakış açısından risk, yalnızca hizmet sağlayıcının altyapısının tehlikeye girmesi değil, aynı zamanda bir saldırganın güvenlik açığından yararlanmayı başarması durumunda bu platformlarda saklanan kişisel veya profesyonel bilgilerin önceden haber verilmeksizin sızdırılması veya manipüle edilmesi olasılığıdır.
Durum , Terrarium'un artık aktif olarak desteklenmemesi gerçeğiyle daha da karmaşıklaşıyor . Bu, sorunu düzeltecek resmi bir yama beklenmediği anlamına geliyor ve bu çözüme güvenmeye devam eden kuruluşlar, bilinen bir güvenlik açığı ve destek eksikliğiyle karşı karşıya kalıyor.
Bu bağlamda, ek önlemler alınmadan Terrarium'un kullanılmaya devam edilmesi önemli bir güvenlik riski oluşturmaktadır . Saldırı yönteminin farkında olan saldırganlar, sistemin genel güvenliğindeki zayıflıkları arayarak, bu teknolojiyi kullanmaya devam eden hizmetleri özellikle hedefleyebilirler.
Dahası, birden fazla hizmetin aynı dahili ağı veya hatta aynı konteyner kümesini paylaştığı ortamlarda, Terrarium'dan kaynaklanan bir sızıntı, görünüşte izole edilmiş diğer sistemlere yatay hareketin önünü açabilir ve başarılı bir saldırının potansiyel etkisini artırabilir.
Risk azaltma stratejileri ve dikkate alınması gereken alternatifler
Bu büyüklükteki bir güvenlik açığı ve aktif bakım eksikliği göz önüne alındığında, kuruluşlar için ilk öneri, Terrarium'un mevcut kullanımını acilen değerlendirmeleridir . Eğer üçüncü taraf kod veya yapay zeka modelleri tarafından üretilen kod çalıştırmak için kullanılıyorsa, risk daha büyüktür ve acil önlem gerektirir.
Kısa vadeli önlemler arasında, daha güvenli bir alternatif değerlendirilirken üretim ortamında rastgele kod yürütülmesine izin veren özelliklerin geçici olarak devre dışı bırakılması yer almaktadır . Diğer seçenekler arasında ağ politikalarının güçlendirilmesi, Terrarium kullanan hizmetlerin daha da bölümlere ayrılması ve konteynere diğer sistemlerden erişimin kısıtlanması yer almaktadır.
Orta vadede, aktif bakım desteği olan ve güvenlik açıklarını gidermek için bir topluluğa veya sağlayıcıya sahip diğer sanal alan veya izole yürütme çözümlerine geçmek daha mantıklı olabilir . Bu, yönetilen hizmetleri, daha güçlü kısıtlamalara sahip sunucusuz yürütme ortamlarını veya varsayılan olarak güvenlik düşünülerek özel olarak tasarlanmış mikro hizmet mimarilerini içerebilir.
Her durumda, bu olay, iyi güvenlik uygulamalarının geliştirme yaşam döngüsüne entegre edilmesinin önemini vurgulamaktadır : düzenli bağımlılık denetimleri, mimaride kullanılan üçüncü taraf bileşenlerin incelenmesi, ilgili CVE'lerin izlenmesi ve kritik bir hata tespit edildiğinde hızlı müdahale planları.
Son kullanıcıların kod çalıştırmasına veya üretmesine olanak tanıyan yapay zeka tabanlı araçlar geliştiren şirketler, sanal ortamlarının tasarımını dikkatlice analiz etmeli , izolasyon süreçlerinin güncel tutulmasını sağlamalı ve güvenilmeyen kod çalıştırma gibi hassas işlevler için terk edilmiş projelere güvenmekten kaçınmalıdır.
Terrarium'la ilgili her şey, kullanıcı kodunu ve LLM modellerini çalıştırmanın ne kadar aşırı bir güvenlik yaklaşımı gerektirdiğini yansıtıyor . Yüksek performanslı, düşük maliyetli bir sanal ortam çok cazip görünebilir, ancak görünürde bir yama olmadan kritik bir güvenlik açığı ortaya çıkarsa, denge bozulur ve risk birçok ciddi kullanım durumu için kabul edilemez hale gelir.
