Geliştirici, kötü niyetli PR olayının ardından CI işlerini Firecracker microVM'lerde izole etti

Kodu değil, runner'ı hedefleyen bir pull request

dev.to'da yazan bir geliştirici, açık kaynak projelerinden birine gelen sıradan bir bağımlılık güncellemesi pull request'iyle başlayan bir güvenlik olayını anlatıyor. Diff'in büyük kısmı rutin görünüyordu; ancak bir hunk, CI yapılandırmasını sessizce değiştirerek her build'e tek bir ekstra adım ekliyordu. Yazar Dhruv Malaviya, değişikliği düzgünce okumadan neredeyse merge edeceklerini yazıyor.

Risk projenin kaynak kodunda değil, onu derleyen makinedeydi. Proje, self-hosted bir CI runner üzerinde çalışıyordu — CI dakikalarından tasarruf etmek için kurulmuş ucuz bir VPS — ki bu runner, repository fork'larından gelen işleri kabul ediyor ve kullanım kolaylığı için oraya bırakılmış bir config dosyasında bulut kimlik bilgilerini saklıyordu. Yazara göre kötü niyetli bir pull request'in herhangi bir sandbox kaçışına ihtiyacı olmayacaktı: runner'ın ortam değişkenlerini bir pastebin'e postalaması yeterliydi ve runner buna boyun eğecekti.

Yazarın dile getirdiği daha geniş ders şu: self-hosted bir runner, yabancıların kodunu çalıştıran ve ardından yaşamaya devam eden bir makinedir. En ucuz makinesi, en tehlikeli makinesi haline gelmişti.

Container'lar neden çözüm değildi

Runner'ı container içinde çalıştırmak bilinen tepkidir ve yazar bunu reddetmiyor; ancak bir CI sunucusunda yetersiz kaldığı birkaç nedeni sıralıyor:

• Container, host makineyle aynı kernel'ı paylaşır.
• Mount edilen cache'ler işten sonra da yaşar; bu yüzden zehirlenmiş bir cache bir sonraki build'e devredilir.
• Runner'lar çoğu zaman Docker socket'ini açığa çıkarır.
• Dosya sistemi build'ler arasında kalıcıdır.

Yazarın özeti şu: bir runner üzerindeki container'lar bir sınırdan çok nezaketten ibarettir.

İş başına tek kullanımlık microVM

Yazıda anlatılan çözüm, her CI işine, iş bittiğinde yok edilen kendi Firecracker microVM'ini vermektir. Kurulum Krova Cloud üzerinde çalışıyor; microVM'leri Cube adıyla pazarlanıyor. Yazar, taze bir 2 vCPU, 4 GB RAM, 40 GB diskli Ubuntu 24.04 makinenin bir saniyenin altında boot ettiğini bildiriyor.

Yaşam döngüsü bilinçli olarak basit: pipeline, build'in adını taşıyan bir Cube oluşturur, secret'ları runtime'da — deploy token'ı SSH üzerinden build script'ine ileterek — enjekte eder ve makineyi ardından siler. Yazar, teardown'ı 'güvenlik özelliği' olarak nitelendiriyor; çünkü sonrasında hiçbir şey kalıcı değildir: zehirlenmiş cache yok, artakalan cron job yok, bir sonraki build için diskte kimlik bilgisi yok. Sağlayıcının API'sini doğrudan çağıran orchestrator'lar için yazıda, retry edilen bir pipeline'ın iki kez makine açmasını önleyen, create isteğine eklenmiş bir idempotency key gösteriliyor.

Yazının belirttiği gibi Firecracker, AWS Lambda'nın arkasındaki aynı sanallaştırma teknolojisi; dolayısıyla bir build içinde tetiklenen bir kernel exploit'i, silinmeye saniyeler kalmış bir makineye düşer.

Saldırılacak adres yok

İş makinelerinin ayrıca genel bir IP adresi yok. Bunlar, gelen trafiğin varsayılan olarak reddedildiği özel, NAT'lı bir ağda duruyor; yazar, işin başlatmadığı hiçbir şeyin çalışmadığı temiz bir listening-socket listesi gösteriyor. Gelen port açmayan bir CI makinesi, SSH'u internete açık, taranabilir bir VPS değildir.

Yazara göre maliyet dakikalık faturalandırma: 2 vCPU, 4 GB'lık bir makinede 12 dakikalık bir iş birkaç sent tutuyor ve her şeyin ephemeral olduğu yaklaşımı ekonomik olarak mümkün kılan da bu.

İzolasyon güvenlik demek değildir

Yazı, yaklaşımın sınırları konusunda alışılmadık derecede açık sözlü. Taze bir VM, ele geçirilmiş bir build'in etki alanını daraltır; kimlik bilgisi hijyenine hiçbir katkısı yoktur. Bir işe uzun ömürlü bir production token'ı verildiyse, yazarın yazdığı gibi token yepyeni bir makineden çalınır. MicroVM izolasyonunun üzerine yine de iş başına kısa ömürlü, kapsamlı token'lar, işler arasında paylaşılan volume'ların olmaması ve gerektiği yerde kısıtlı egress öneriyorlar. Yazı, 'güvenli CI'yı bir onay kutusu olarak satan herkes bir şey satıyor diye bitiriyor.

Neden önemli

Yabancılardan gelen pull request'ler, bir CI sisteminin kabul etmek üzere tasarlandığı standart girdidir; bu da pipeline'ın kendisini bir supply-chain saldırı yüzeyi haline getirir: build'inizde çalışan kod, sizin yazmadığınız koddur. Bu anlatı — tek bir sağlayıcıya odaklanan, birinci ağızdan tek bir rapor olup bağımsız olarak doğrulanmamıştır — aynı zamanda her platforma aktarılabilir pratik bir kontrol listesi işlevi görüyor: runner'ları kullanımlık olarak ele alın, her işi kernel'de değil hypervisor düzeyinde izole edin, build makinelerini genel internetten uzak tutun ve uzun ömürlü bir secret'ın güvenilmeyen kod çalıştıran bir makineye asla dokunmasına izin vermeyin. Buradaki olay, bir diff'in dikkatli okunmasıyla yakalandı. Anlatılan mimari altında, bir dahaki sefere bunun gerekmesi gerekmeyecekti.