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 kurun: ephemerality ve izolasyon.

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

1. Ephemerality: her job taze, atılır bir ortamda çalışsın. Runner’ı “kaydol → tek job çalıştır → kaydı sil” modeline geçirin; 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 vermeyin. Job’ları unprivileged container’larda (ya da rootless Docker / job başına VM) çalıştırın; capability’leri düşürün, --privileged kullanmayın, hassas hiçbir şeyi mount etmeyin. /var/run/docker.sock’ı vermek, root vermekle eşdeğerdir.
3. Güvenilmeyen fork PR’larını self-hosted runner’da hiç çalıştırmayın. Bir fork’tan gelen PR sizin altyapınızda keyfi kod demektir; bunları onay (required approval) arkasına alın. En sık gözden kaçan ve en tehlikeli vektör budur.
4. Runner’ları prod’dan ağ olarak ayırın (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.