EC2 içindeki Firecracker VM ile tarayıcıyı 1 saniyenin altında başlatmak

• Browser Use Cloud, her tarayıcı oturumu için ayrı bir Firecracker VM kullanırken yeni oturum başlatma süresini 1 saniyenin altına indirdi ve maliyeti tarayıcı saat başına 0,06 dolardan 0,02 dolara düşürdü
• Önceki Unikraft mimarisi boşta kalma maliyeti açısından avantajlıydı, ancak trafik sıçramalarında kapasitenin insanlar tarafından ayarlanması gerektiği için bir yük testi sırasında prodüksiyon 45 dakika boyunca kesintiye uğradı
• Yeni mimaride kendi control plane sistemi, tarayıcı filosunu gerçek zamanlı izleyerek EC2 host yerleşimi, ölçeklendirme ve draining kararlarını CloudWatch'tan daha ayrıntılı biçimde veriyor
• Standart EC2 üzerinde Firecracker çalıştıran iç içe sanallaştırma tercih edildi; bunun karşılığında 2MB bellek sayfaları, userfaultfd, vCPU sabitleme, real-time priority ve headless Chromium yamalarıyla darboğazlar azaltıldı
• VM cold start süresi 400ms'nin altında; 10.000 oturumluk stres testinde herkese açık API ölçümüne göre tarayıcı oluşturma gecikmesi p50 825ms, p99 1,35 saniyeydi ve tüm tarayıcılar başarıyla başladı

---

Hızlı, izole ve ucuz bulut tarayıcı

• Browser Use Cloud'un hedefi, tarayıcıları hızlı başlatırken oturumlar arasındaki durumu izole etmek ve maliyeti düşürmek
• Bir oturum; Chromium, dosya sistemi, çerezler, önbellek, proxy ayarları, indirmeler ve bazen müşterinin giriş yapmış oturumu gibi unsurları içeriyor
• Bir tarayıcının başka bir tarayıcının durumunu okuyabilmesi güvenlik sorunu yaratacağı için her oturumun host'tan ve diğer oturumlardan ayrılması gerekiyor
• Yaygın çözüm, kendi CPU, bellek, disk ve ağ aygıtlarına sahip bir VM kullanmak; ancak sürekli oluşturulup oturum sonunda atılan bulut tarayıcı ortamları için bu yaklaşım fazla ağır ve pahalı
• Yeni mimari, tüm Browser Use Cloud oturumlarını tek tek küçük bir Firecracker VM içinde çalıştırıyor ve bu VM'leri Amazon EC2 üzerinde yürütüyor

Unikraft'tan neden vazgeçildi

• Önceki mimari, bulut tarayıcıları çalıştırmak için Unikraft kullanıyordu
• Unikraft, tam Linux'u başlatmak yerine amaca özel hazırlanmış küçük bir imaj olan unikernel yüklüyor
• unikernel hızlı başlıyor ve kullanıcı olmadığında kapatılabildiği için boşta kalma maliyeti düşük oluyor
• Darboğaz, trafik sıçramalarında tarayıcı kapasitesini hızlıca büyütmekti
  • Unikraft'ta güçlü bir yerleşik autoscaling yoktu
  • Mühendislerin değişkenleri değiştirip instance'ları elle eklemesi gerekiyordu
  • Bir yük testi prodüksiyonu 45 dakika boyunca durdurdu
• Yeniden kurulumdan sonra Firecracker kullanılmaya başlandı
  • Firecracker, VM oluşturma, izleme ve çalıştırma katmanını sağlıyor
  • Her VM'e CPU, bellek, disk ve ağ aygıtları veriyor ve bunları host'tan ve diğer VM'lerden izole ediyor

Kendi control plane sistemiyle tarayıcı ölçeklendirmesini otomatikleştirmek

• Firecracker her tarayıcıya bir VM verebiliyor, ancak VM sayısını, yerleşimini ve ne zaman ölçekleneceğini otomatik olarak belirlemiyor
• Browser Use, tarayıcı filosunu izleyen ve scale up/down kararları veren kendi control plane sistemini kurdu
• Kullanıcı tarayıcı istediğinde control plane uygun kapasitesi olan bir makine seçiyor
• Trafik arttığında daha fazla makine başlatılıyor; azaldığında ise kaldırılacak makinelere yeni tarayıcı gönderilmiyor
• control plane filoyu gerçek zamanlı olarak görüyor
  • AWS izleme servisi CloudWatch genelde 1 dakikalık pencerelerle tepki veriyor
  • control plane; hâlâ başlamakta olan tarayıcılar, kaldırılmak üzere olan makineler ve yeni oturum almaması gereken makineler gibi standart metriklerde olmayan bilgileri biliyor
• Kullanıcı istekleri stateless bir edge router üzerinden control plane'e gidiyor, control plane de kapasitesi olan EC2 host'unu seçiyor

Standart EC2 üzerinde Firecracker çalıştırmayı neden seçtiler

• AWS'te Firecracker çalıştırmanın yaygın yolu .metal instance'ları kullanmak
  • .metal, tüm fiziksel sunucunun kiralanıp Firecracker'ın doğrudan üzerinde çalıştığı yapı
• Browser Use ise standart EC2'yi seçti
  • Standart EC2 makineleri daha hızlı temin edilebiliyor
  • İşletme maliyeti daha düşük
  • Host'lar önceden hazırlanmış imajlardan boot ediyor ve başladıktan yaklaşık 30 saniye sonra tarayıcı sunabiliyor
• Host'ların daha hızlı eklenebilmesi, maliyet oluşturan boşta kapasiteyi ve bunun müşteriye yansımasını azaltıyor
• Bunun bedeli VM içinde VM yapısı
  • Standart EC2 zaten AWS'in kendi izolasyon katmanı içinde çalışıyor
  • Bunun içinde bir kez daha tarayıcı VM'leri çalışıyor
  • Tarayıcı VM host'tan yardım istediğinde iki VM katmanından geçmek zorunda olduğu için ek gecikme oluşuyor
• Browser Use, daha hızlı scale-up ve daha düşük maliyet için bu ödünleşimi seçti ve Firecracker yürütme yolunu hızlandırmaya odaklandı

İstekten kullanılabilir tarayıcıya akış

• Kullanıcı tarayıcı istediğinde control plane kapasitesi olan bir makine seçiyor
• İlgili makine, saklanmış tarayıcı VM'ini geri yüklüyor ve içinde Chromium'u başlatıyor
• Chromium kontrol edilebilir duruma geldiğinde bağlantı URL'si döndürülüyor
• Kullanıcının ajanı bu URL'ye bağlanıyor
• Browser Use, WebSocket üzerinden Chrome DevTools Protocol(CDP) ile Chromium'u kontrol ediyor
  • CDP; buton tıklama, metin girme, sayfa okuma ve ekran görüntüsü alma gibi Chrome uzaktan kontrol API'si
• Gecikmeye neden olan başlıca üç darboğaz vardı
  • VM belleğini geri yükleme
  • Chromium başlatma
  • anti-bot güvenliğine yakalanmadan stealth koruma

Birinci darboğaz: bellek geri yükleme

• Prodüksiyon tarayıcıları sıfırdan boot etmek yerine snapshot üzerinden devam ediyor
• snapshot, zaten boot edilmiş ve Chromium başlatılmadan hemen önce durdurulmuş kayıtlı bir VM
• VM'i sürdürmek yeni başlatmadan daha hızlı, ancak ilk cold start sırasında page fault tüm VM exit olaylarının %72'sini oluşturuyordu
• VM devam ettikten CDP-ready tarayıcıya kadar geçen süre başlangıçta 9,8 saniyeydi
• Yavaş olmasının nedeni, geri yüklenen VM belleğe ilk kez dokunduğunda host'un o belleği yeniden map etmesi gerekmesiydi
  • Bu olaya page fault deniyor
  • İç içe VM yapısında page fault iki VM katmanından geçebildiği için maliyetli oluyor
• Çözüm, belleği daha büyük birimlerle map etmek oldu
  • Önceden 4KB sayfalarla geri yükleniyordu
  • Şimdi 2MB sayfalar kullanılıyor
  • Her sayfa 512 kat daha fazla belleği kapsadığı için tarayıcı uyanırken page fault sayısı ciddi biçimde azalıyor
• Linux'un eksik bellek sayfalarını ele alma API'si olan userfaultfd için özel bir handler da eklendi
  • VM çalışmadan önce Chromium'un önce erişmesi muhtemel bellek yükleniyor
  • Chromium başlangıcında page fault fırtınası önleniyor
• Bu değişiklikle, VM devam ettikten komut alabilecek tarayıcıya kadar geçen süre 9,8 saniyeden 3,1 saniyeye düştü
• Eksik bellek işlemek için tarayıcı VM'in durup host'tan yardım istediği sayı, her resume başına yaklaşık 100.000'den yaklaşık 1.100'e indi; yani yaklaşık 91 kat azaldı
• Küçük optimizasyonlar da birikti
  • Var olmayan eski PS/2 klavyesini aramak için harcanan 500ms kontrol devre dışı bırakıldı
  • Hazır olma kontrolü HTTP polling yerine vsock log okumasına çevrildi
  • Tarayıcı sürücüsü log'a ready mesajı yazdığında host bunu vsock üzerinden okuyup ready mesajını 1ms'den kısa sürede doğruluyor

İkinci darboğaz: Chromium başlangıcı ve CPU yerleşimi

• Chromium başlatılırken renderer, compositor ve V8 isolate aynı anda oluşturulduğu için CPU kullanımı yüksek oluyor
• Başlangıçtan sonraki tarayıcı otomasyonu ise görece sakin
  • Ajan tıklar, bekler, okur ve tekrar tıklar
  • Tarayıcı çoğu zaman sayfayı, ağ yanıtlarını veya ajanın sonraki hamlesini bekler
• Bu özellik sayesinde tek bir host üzerine çok sayıda tarayıcı packing yapılabiliyor
• Başlangıç anındaki CPU burst iki aşamada ele alınıyor
  • Tarayıcı devam ettirilip Chromium başlatılırken vCPU'lar unpinned bırakılıyor
  • Böylece Linux, tarayıcı CPU işini sabit çekirdeklere bağlamadan host geneline dağıtabiliyor
  • Tarayıcı ready durumunu bildirdiğinde vCPU'lar kararlı çekirdeklere pinning ile sabitleniyor
• Başlangıçtan itibaren pinning yapılırsa birden fazla tarayıcı aynı anda başlarken aynı hot core üzerine yığılıyor ve bazı launch'lar başarısız oluyor
• hyperthread yönetimi de ayarlandı
  • Tek bir fiziksel CPU çekirdeği çoğu zaman sibling thread denilen iki mantıksal CPU olarak görünüyor
  • İki tarayıcı VM'i bu sibling'lerden birer tane alırsa aynı fiziksel çekirdek için yarışıyor
  • İç içe ortamda bu yarış launch başarısızlığı olarak ortaya çıkıyor
  • Artık her tarayıcı, kullandığı fiziksel çekirdeğin her iki sibling thread'ini de alıyor
• Sabitlenmiş her vCPU thread'ine real-time priority verildi
  • Böylece Linux, daha az önemli işler yüzünden VM'i bekletmek yerine hemen çalıştırıyor
  • Değişiklikten önce 1.000 tarayıcılık testte oturumların %17'si oluşturulduktan hemen sonra kayboluyordu
  • Değişiklikten sonra aynı testte kayıp oranı 0 oldu

Ekransız stealth tarayıcı

• headless tarayıcı görünür pencere olmadan çalışır; headful tarayıcı ise dizüstü bilgisayardaki tarayıcı gibi pencere, grafik ve render frame'leriyle çalışır
• Düz headless Chromium, anti-bot önlemleri kullanan sitelerde kolayca tespit edilebiliyor
• Browser Use'un stealth benchmark verisine göre düz headless Chromium'un engellemeyi aşma oranı %2 idi
• Aynı Chromium görünür pencereyle çalışan headful durumda yalnızca rendering sayesinde %50 engel aşma oranına ulaşıyor
• Birçok sağlayıcının headful tarayıcı çalıştırmasının nedeni bu; ekrana bakan biri olmasa bile display server, GPU ve compositor maliyeti ödeniyor
• Browser Use, tam headless çalışmayı korumak için tarayıcının kendisini değiştirdi
• İlk bileşen bir Chromium fork
  • Birçok stealth aracı, otomasyonu gizlemek için tarayıcı başladıktan sonra tüm sayfalara JavaScript enjekte ediyor
  • Örneğin web sitelerinin true yerine false görmesi için navigator.webdriver değerini ezebiliyor
  • Web siteleri bu tür ezmelerin yapıldığını tespit edebiliyor
  • Browser Use ise Chromium'un daha alt seviyelerini yamalayarak bu değerlerin en baştan görünmemesini sağlıyor
• İkinci bileşen fingerprinting
  • Tarayıcı fingerprint'i, web sitelerinin okuduğu tarayıcı ve makine bilgilerinin birleşimi
  • İşletim sistemi, ekran boyutu, font'lar, grafik çıktısı, ses, zaman dilimi, dil ve yüzlerce başka ayrıntı buna dahil
  • Browser Use; macOS, Windows ve Linux genelinden on binlerce gerçek fingerprint kullanıyor
• Bu tarayıcılar stealth benchmark'ta %81, Halluminate BrowserBench'te ise %84,8 engel aşma oranına ulaştı
• Ekran olmadığı için tarayıcı çalıştırma maliyeti daha düşük ve ölçeklendirme daha kolay

Doğru tarayıcıya bağlanmak

• Tarayıcı hazır olduğunda kullanıcı CDP ile bağlanıyor
• Herkese açık URL bir WebSocket URL
• Tarayıcı filosunun önünde basit edge router'lar bulunuyor
• router, WebSocket bağlantısını alıp control plane'e ilgili tarayıcının yerini soruyor, ardından ham CDP baytlarını doğru VM'e iletiyor
• router tarayıcının nerede çalışacağına karar vermiyor
• Bir router ölse bile başka bir router yeni bağlantıyı üstlenebiliyor
• Yerleşim control plane tarafından yapılıyor, router ise yalnızca bayt iletimini gerçekleştiriyor

Sonuçlar ve sonraki adım

• Şu anda her tarayıcı oturumu, standart EC2 içinde çalışan küçük bir VM snapshot'ından devam ediyor ve bunun içinde headless Chromium çalışıyor
• VM cold start süresi 400ms'nin altında
• Herkese açık API ölçümüne göre tarayıcı oluşturma gecikmesi p50 825ms, p99 1,35 saniye
• Bu değerler, tüm tarayıcıların başarıyla başladığı 10.000 oturumluk stres testinde ölçüldü
• BrowserArena bağımsız leaderboard'u, Browser Use'u saatte 0,02 dolar ve %100 reliability ile 1. sıraya yerleştirdi
• Bu altyapıda geriye kalan en büyük maliyet kalemi hâlâ Chromium'un kendisi
  • resume sonrasında Chromium başlangıcı p50 ölçümünde hâlâ yaklaşık 545ms sürüyor
• Mevcut snapshot, Chromium başlatılmadan hemen önceki noktada alınıyor
  • Tüm tarayıcılar aynı ve temiz bir noktadan uyanıyor, ardından kendi Chromium süreçlerini başlatıyor
• Sonraki adım, snapshot'ı Chromium zaten çalışıyorken almak
  • Böylece yeni oturum, tarayıcıyı başlatmak yerine zaten yaşayan bir tarayıcıyla birlikte uyanabilir
• Bu iş karmaşık
  • Çalışan tarayıcıda açık aygıtlar, zamanlayıcılar, grafik durumu, ağ durumu ve fingerprint durumu bulunuyor
  • freeze öncesinde bu durumların güvenli hale getirilmesi gerekiyor
  • restore sonrasında her tarayıcının önceki tarayıcının kopyası değil, kendine ait bir tarayıcı gibi görünmesi gerekiyor
• Browser Use Cloud şu anda cloud.browser-use.com adresinde kullanılabiliyor

[GN⁺]

Hacker News görüşleri

• Anti-bot aşmayı bir benchmark olarak öne çıkarmak epey etik dışı görünüyor. Anti-bot sistemlerinin amacı istenmeyen botları engellemektir; bu tür bir hizmet de sonuçta web’i insanlar için daha kullanışsız ve daha pahalı hale getiriyor
  Siteler otomasyona dayalı erişimi engellemeye devam edecek ve içerik erişimindeki bariyerler daha da artacak. Web’de kimlik doğrulama taleplerinin artmasının nedeni de yalnızca yaş sınırı ya da “çocukları koruma” değil, bot savunması ve reklam gelirini koruma gibi daha üst düzey etkiler gibi görünüyor

  • Bu tür araçları web sitesi değişikliklerini tespit etmek için kullanıyorum. Takip ettiğim bazı yazarların RSS’i yok ve beyaz eşya gibi pahalı ürünlerde fiyat değişimlerini görmek için sürekli fiyat izleme kuruyorum
    API’si olmayan sitelerde scraper da kullanıyorum ve tüm satın alma geçmişimi analiz edebilmek için veritabanında indeksli tutuyorum. Aptal bot tespitlerini aşmak için daha fazla zaman harcamak istemem; başka türlü erişilemeyen veriyse bunun için para ödemeye de razıyım. Sonuçta kaynaklar, scraper’ların eninde sonunda kazanacağı bir kedi-fare oyununa harcanmış oluyor
  • Açık web sitelerinin scraping ile taranmasının etik dışı olup olmadığı tartışmaya açık. Bazı durumlarda, site teknik engeller koysa ya da ihtarname gönderse bile mahkemeler bunun yasal olduğuna hükmetti
    Ancak konut tipi proxy sunmak büyük ihtimalle etik dışı. Bu tür proxy’lerde konut hattını sağlayan kişiler çoğu zaman böyle bir hizmetin parçası olduklarını bilmiyor
  • Birinin istemediği bir şeyi yapmak, tek başına onu etik dışı yapmaz. Gerekçe ve niyet önemlidir
    Diyelim ki bir konser bileti almak için 24 saat bilgisayar başında bekleyemiyorsunuz; sevdiğiniz grubun biletini almak için kişisel bir bot kullanmayı etik dışı görmek zor. Buna karşılık amaç karaborsacılıksa etik dışı olduğuna katılırım. Anti-bot’a karşı anti-bot, başkalarının otomatikleştirilmemesi gerektiğini düşündüğü şeyleri mümkün kılmayı amaçlıyor ve Hacker News okurlarının epey çoğu muhtemelen bunu en az bir kez yapmıştır. Sırf kâr amacıyla yapılıyorsa pek hoş değil ama karaborsacılara karşı bir şans elde etmek içinse makul görünüyor
  • Yalnızca web üzerinden erişilebilen, API desteği zayıf ya da hiç olmayan yazılımları otomatikleştiren şirketler biliyorum. Genelde bunlar ciddi para ödenen yazılımlar ve giriş koruması için yerleşik CAPTCHA içeriyorlar
    Birden çok SaaS tenant’ından yalnızca biri olduğunuz için CAPTCHA’nın kaldırılmasını isteyecek kadar büyük müşteri de değilsiniz; dolayısıyla bu kısıtı sadece aşıyorsunuz
  • Bunu, kendi headless browser’larının engellenmemesini isteyen insanlar kullanıyor

• Burada eksik kalan nokta, sıradan EC2 instance’larında nested virtualization özelliğinin bu yılın şubat ayından beri mümkün olması. Öncesinde Firecracker VM çalıştırmak için metal EC2 instance kullanmanız gerekiyordu

  1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
  • Oldukça yeni bir özellik ve resmî olarak henüz önerilmiyor ama şimdiye kadar gayet iyi çalıştı. Sonunda bare metal çalıştırmak zorunda değiliz
  • metal instance’lar başlatma ve durdurmada aşırı yavaş

• Bunca şeyi yapıp hâlâ Chromium’da kalmaları biraz şaşırtıcı
  Bizim web-access MCP sunucumuz[0], çok daha basit bir kurulumla tarayıcı instance’larını alt süreç olarak başlatıyor; kararlılık, CPU ve bellek kullanımındaki en büyük iyileşme Chrome’dan Lightpanda[1]’ya geçtiğimizde oldu. Yazının sonundaki gibi, daha hızlı açılan tarayıcı aslında baştan daha az bellek ayıran tarayıcı olabilir
  [0]: https://github.com/EratoLab/web-access-mcp
  [1]: https://lightpanda.io

  • Stealth amacıyla Chromium motorunu korumaya karar verdik
    LightPanda gibi tarayıcılarda stealth hiç yok ve tespit edilmeleri çok kolay. Gereksiz şeyleri çıkarırsanız Chromium’u da daha hızlı hale getirmenin yolları var. Baştan tüm motoru yeniden yazmadan da, bizim birinci önceliğimiz olan stealth’i kaybetmeden Chromium’un o performansa ulaşabileceğini düşünüyorum. Sorun dil değil; C++ da Zig kadar performanslı olabilir ama Chromium’un hantallığının büyük olduğuna katılıyorum

• ApiFlash adlı bir ekran görüntüsü API işletiyorum; EC2’de Firecracker yerine AWS Lambda container image içine Chromium paketliyoruz
  AWS Lambda, izolasyon ve otomatik ölçeklendirmeyi ücretsiz verdiği için ekran görüntüsü gibi yükü sıçrayan stateless işler için ideal. browser-use çözümünün neredeyse aynı avantajlarını alırken mimarinin çok daha basit olduğunu düşünüyorum. Buradaki trade-off, AWS Lambda cold start süresi ama pratikte art arda gelen çağrılarda sıcak fonksiyonlar yeniden kullanılıyor. Yeterince çağrı hacmi varsa zirveler yumuşuyor ve cold start da o kadar sık yaşanmıyor

  • Bizim geliştirdiğimiz özelliğe her kullanım senaryosunda ihtiyaç yok
    Lambda’da yaşadığımız sorunlar, 15 dakikalık çalışma süresi sınırı, maliyet, snapshot mekanizmasının olmaması ve çalıştığı host üzerinde düşük seviyede kontrol eksikliğiydi. Biz en fazla 4 saati destekliyoruz ve gerekirse daha da uzun çalıştırabiliyoruz. Yine de çoğu genel web otomasyonu kullanım senaryosu için Lambda fazlasıyla yeterli
  • O çözüm epey pahalı görünüyor

• “Sıradaki: Chromium başlatmayı atlamak” denmiş ama zaten çalışan tarayıcı gruplarını bir warm pool olarak tutup gelen isteklere atamak mümkün değil mi diye düşünüyorum
  Kullanıcı açısından gecikme neredeyse sıfıra yakın olurdu. Trafik desenine göre warm pool’u büyütüp küçültecek tahmin mantığı gerekir ama en kolay çözüm gibi görünüyor

  • Warm pool işe yarıyor ama amaç zaten onun yerini almak
    Warm pool iyi ama sonuçta kaynak tüketiyor ve havuzu sürekli sıcak tutup dengelemek için tarayıcıları durmadan başlatmanız gerekiyor. Gelecek değişikliklerle Chromium başlangıcını korurken VM’in 50 ms içinde hazır olmasını sağlayıp warm pool’u tamamen geride bırakmayı planlıyoruz. Bazı müşteriler özel parametreler ve özellikler istiyor; bu da warm pool karmaşıklığını artırıyor. Genel yol hızlı olabilir ama istisna yollar çok yavaşlayabilir; talep edilen tarayıcıda hangi özellikler gerekirse gereksin, hızın hep yüksek kalmasını istiyoruz

• Firecracker harika bir teknoloji. Kodlama mülakatları ve kişisel çalışma alanları için izole runtime’lar çalıştıran bir mülakat girişiminde kullanıyoruz; çok kararlı ve şaşırtıcı derecede hafif
  Go SDK ile entegre etmek de çok kolaydı

• userfaultfd’nin daha fazla kullanıldığını görmek güzel. Sayfa hatası oluştuğunda belleğin nasıl ve nereden getirileceğini tamamen kontrol edebildiğiniz için gerçekten çok güçlü bir API

• Sıradan EC2’nin de zaten bir VM olduğu doğru ama bildiğim kadarıyla hypervisor erişimi sağlayan, dolayısıyla Firecracker’ı da mümkün kılan belirli EC2 türleri var. Yanlışsam düzeltin

  • Doğru. Yalnızca c8i, m8i, r8i instance türleri destekleniyor ve buna nested virtualization deniyor[1]
    [1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
  • Oldukça büyük makineler, yani AWS metal instance’ları gerektiğinde, metal ile aynı boyuttaki VM arasında CPU ağırlıklı işlerde performans farkı yaklaşık %10–20 oluyordu

• Firecracker’a neden ihtiyaç duyulduğunu merak ediyorum. Neden doğrudan bir container içinde çalıştırmıyorsunuz? İzolasyon kaygısını anlıyorum ama tarayıcı + container escape birleşimi milyar dolarlık bir CVE olmaz mı?

  • Olgun ya da güvenlik konusunda bilinçli çoğu sağlayıcı, container’ları güvenli bir izolasyon sınırı olarak görmüyor. Microsoft istisna gibi duruyor ama bunun iç politika başarısızlığı mı yoksa politikayı uygulama kapasitesinin eksikliği mi olduğu belirsiz
    Container’lar VM’lere kıyasla çok daha geniş bir saldırı yüzeyi sunuyor ve sektör standardında güvenli kabul edilmedikleri için container escape CVE’lerini yönetmeye ayrılan kaynaklar da muhtemelen VM escape’lere göre daha az
  • Kernel mailing list’e bakarsanız container escape exploit’leri bugünlerde neredeyse her hafta çıkıyor
  • MikroVM’lerde snapshot alıp rollback yapabilirsiniz. Container’larda bunun böyle yapıldığını hiç duymadım

• Bunu .metal olmayan instance’larda yapmak için kernel patch gerekmiyor mu? PVM patch gerekiyor gibi görünüyor