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

> Runner'ı kaydol-çalış-yok ol modeline geçirip job'ları unprivileged çalıştırın; Docker soketini vermeyin ve fork PR'larını bu runner'da hiç koşturmayın.

- Soruldu: 2026-06-12
- Yanıtlandı: 2026-06-12
- Soran: Cüneyt
- Etiketler: ci-cd, guvenlik, docker
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/self-hosted-ci-cd-runner-izolasyonu-ve-ephemeral-ortam/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Kaynak kod güvenliği politikamız nedeniyle bulut runner'larını (GitHub Hosted) kullanamıyoruz; kendi VPS'lerimizde Self-Hosted Runner koşturuyoruz. Ama bir test kodu ya da hatalı script sunucunun kök dizinine zarar verebiliyor (`rm -rf /`) veya Docker soketini (`/var/run/docker.sock`) manipüle edip sunucuyu ele geçirebiliyor.

Self-hosted runner'da tam izolasyon ve her pipeline sonrası temizlenen (ephemeral) ortam mimarisini 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.

## İlgili Yazılar

- [Docker sanallaştırma: kurulum ve temel kullanım](/blog/docker-sanallastirma-teknolojisi-kurulum-kullanim/) — Blog
- [Container'ı non-root çalıştırınca mount edilen storage dizinine yazamıyorum, izinleri nasıl çözerim?](https://www.muhammetsafak.com.tr/sor-bakalim/containeri-non-root-calistirinca-mount-edilen-storage-dizinine-yazamiyorum-izinleri-nasil/) — Sor Bakalım
- [CI/CD'de OIDC ve IAM Role ile şifresiz (secretless) AWS erişimini nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/ci-cd-de-secret-yonetimi-ve-oidc-ile-sifresiz-erisim/) — Sor Bakalım
- [Docker imaj boyutunu multi-stage build ve distroless ile nasıl küçültürüm?](https://www.muhammetsafak.com.tr/sor-bakalim/docker-imaj-boyutunu-multi-stage-ve-distroless-ile-kucultmek/) — Sor Bakalım