Self-hosted CI/CD runner'larını nasıl izole eder, her çalışmadan sonra temizlenen (ephemeral) ortamı nasıl kurarım?

Kısa cevap: Root’a ve gerçek Docker soketine sahip, üstüne rastgele kod çalıştıran kalıcı bir self-hosted runner, sunucu ele geçirilmesini bekleyen bir açıktır. İki ilke üzerine kur: ephemerality ve izolasyon.

Riskin kökü: güvenmediğin kodu, tam yetkili ve kalıcı bir makinede çalıştırıyorsun.

1. Ephemerality: her job taze, atılır bir ortamda çalışsın. Runner’ı “kaydol → tek job çalıştır → kaydı sil” modeline geçir; her job tek kullanımlık bir VM ya da container’da koşsun ve bittiğinde yok edilsin. Böylece job’lar arası hiçbir şey kalıcı olmaz, zehirlenmiş bir workspace bir sonraki job’ı etkileyemez.
2. İzolasyon: runner host’una root ve gerçek Docker soketi verme. Job’ları unprivileged container’larda (ya da rootless Docker / job başına VM) çalıştır; capability’leri düşür, --privileged kullanma, hassas hiçbir şeyi mount etme. /var/run/docker.sock’ı vermek, root vermekle eşdeğerdir.
3. Güvenilmeyen fork PR’larını self-hosted runner’da hiç çalıştırma. Bir fork’tan gelen PR senin altyapında keyfi kod demektir; bunları onay (required approval) arkasına al. En sık gözden kaçan ve en tehlikeli vektör budur.
4. Runner’ları prod’dan ağ olarak ayır (segmentation). Bir job kaçsa bile prod kaynaklarına ulaşamasın. Tooling tarafında: Kubernetes’te Actions Runner Controller ile ephemeral runner’lar, ya da her job için yeniden yaratılan autoscaling VM’ler.

Sonuç: Ben olsam ephemeral tek-job runner’lar + unprivileged izolasyon + fork PR yasağı + ağ segmentasyonu kurardım; ve her job’ı düşman kabul ederdim. Self-hosted runner’ın gücü kontrolde ama bedeli sorumluluk — konteyner izolasyonunun nasıl çalıştığını ve soketi vermenin neden root vermek olduğunu hub’daki Docker yazısında temelden anlattım.