1. Container Güvenliğinin Temelleri
Container güvenliği, “tek ayar” değildir; üç katmanın birlikte doğru çalışmasıdır:
- Host güvenliği: container’ların çalıştığı altyapı güvenli mi?
- Image güvenliği: çalıştırdığınız paketler ve bağımlılıklar güvenilir mi?
- Runtime güvenliği: container çalışırken neye erişebilir, ne kadar kaynak tüketebilir?
Bu yaklaşım, “saldırı yüzeyi azaltma” hedefini gerçekçi hale getirir. Ayrıca sheet’teki veri noktasıyla uyumlu olarak; container güvenliği doğru kurgulanan yapılarda host’a sıçrayan saldırı ve stabilite sorunlarının belirgin biçimde azaldığı sık raporlanır.
Container ve Docker güvenliği nasıl sağlanır?
Container güvenliği; host’u harden etmek, güvenilir/taranmış image’ler kullanmak ve runtime’da least-privilege + resource/network limitleri tanımlamakla sağlanır. Secret’ların image içine gömülmemesi, düzenli tarama ve policy’lerin CI/CD’ye bağlanması da kritik parçadır.
Container güvenliğini “stabilite” ile birlikte düşünmek
Container güvenliği sadece saldırı değil; kaynak tüketimi ve izolasyon hatalarıyla da ilgilidir. Limitsiz çalışan bir container, CPU/memory tüketip sistemi düşürebilir; bu da DDoS etkisine benzer kesintiler üretir. Bu nedenle “security + reliability” birlikte ele alınmalıdır.
☑ Mini Check: 10 dakikalık container sağlık kontrolü
- •Host OS güncel ve harden edilmiş mi?
- •Container’lar root olarak mı çalışıyor (rootless hedef)?
- •Base image’ler resmî/minimal mi?
- •Image vulnerability scan düzenli çalışıyor mu?
- •Secrets image içinde mi, yoksa runtime’da mı?
- •CPU/memory limit ve network policy var mı?
Ne yapmalıyım?
- • Host→image→runtime sırası ile ilerle; tek alana takılı kalma.
- • Rootless/least-privilege’i standart yap.
- • Scan + policy kontrollerini CI/CD’ye bağla.
- • Logging/izlenebilirliği raporlama altyapısına entegre et (Internal link: /tr/veri-analiz-ve-raporlama).
2. Host Güvenliği ve İzolasyon
Host, container’ların “zemini”dir; zemini sağlam olmayan yapıda image taramak tek başına yeterli olmaz. Host güvenliği; OS hardening, Docker daemon ayarları, kernel/namespace izolasyonu ve erişim yönetimini kapsar.
Docker host OS hardening (prensip yaklaşım)
- •OS patch yönetimi ve minimum paket yaklaşımı
- •Gereksiz servislerin kapatılması
- •Yönetim erişiminin sınırlandırılması (IAM/VPN/bastion modeli)
- •Loglama/izleme ajanlarının standardize edilmesi
Rootless container ve least-privilege
Rootless yaklaşım; container’ların host üzerinde ayrıcalık kazanma riskini azaltır. En az yetki prensibi; yalnız gerekli capability’leri kullanmak, gereksiz mount/privileged moddan kaçınmak ve dosya izinlerini doğru kurmaktır.
İzolasyon hedefleri
- •Network izolasyonu: her servis her şeye erişmesin
- •Dosya izolasyonu: host dosya sistemine gereksiz mount yok
- •Yetki izolasyonu: kullanıcı/rol bazlı operasyon
☑ Mini Check: Host hardening kontrol listesi
- •Host OS patch rutini var mı?
- •Docker daemon erişimi kısıtlı mı?
- •Privileged container kullanımına izin politikası var mı?
- •Rootless veya non-root standart mı?
- •Host logları ve audit izleri tutuluyor mu?
Ne yapmalıyım?
- • Host’u “prod standardı”na harden et; drift’i azalt.
- • Rootless/non-root default yap; exception’ları gerekçeli yönet.
- • Privileged ve host mount’ları için approval süreci koy.
- • Host loglarını SIEM/loglama stratejisiyle bağla (Internal link: /tr/veri-analiz-ve-raporlama).
3. Image Güvenliği (Base Image, Vulnerability Scan)
Image güvenliği, çalıştırdığınız kodun ve bağımlılıkların güvenliği demektir. Güvenlik açığının önemli kısmı “uygulama kodu” değil, image içindeki paketlerden gelir. Bu nedenle base image seçimi ve tarama rutini çok kritiktir.
Resmî ve az katmanlı base image’ler
- •Resmî/kurumsal onaylı image tercih et
- •Minimal base (az paket) saldırı yüzeyini azaltır
- •Sürüm pinleme ve güncelleme politikası olmalı
Image vulnerability scanning (süreç olarak)
Tarama; tek sefer değil, rutin olmalıdır:
- •CI pipeline’da build sonrası tarama
- •Registry’de periyodik tarama
- •Kritik CVE’lerde otomatik uyarı ve rebuild
Secrets’leri image içine gömmemek
En sık ölümcül hata: API key, DB şifresi, token gibi secret’ların image katmanına yazılmasıdır. Çünkü image paylaşılır, cache’lenir, loglanır. Secret’lar runtime’da, secret store/manager üzerinden verilmelidir.
Fark yaratan mini bölüm (Competitor Gap): “Image tarandı ama prod’da eski”
Birçok ekip taramayı “build anı”nda yapar ama prod’da çalışan image aylarca güncellenmez. Bu yüzden tarama sonucu rebuild + rollout döngüsüne bağlanmalıdır: tarama → risk değerlendirme → patch → redeploy.
☑ Mini Check: Image güvenliği kontrol listesi
- •Base image resmî/minimal mi?
- •Sürüm pinleme ve güncelleme döngüsü var mı?
- •CI’da image scan zorunlu mu?
- •Secret’lar image içinde değil mi?
- •Scan sonucu rebuild+rollout sürecine bağlı mı?
Ne yapmalıyım?
- • Base image standardı belirle (approved list).
- • Scan’i CI gate yap; kritik CVE’de release blokla.
- • Secret’ları runtime secret manager’a taşı.
- • Rebuild/rollout takvimi oluştur (bakım-destek ile entegre) (Internal link: /tr/yazilim/bakim-ve-destek).
4. Runtime Güvenliği (Resource Limit, Network Policy)
Runtime güvenliği, container çalışırken “ne kadar kaynak tüketebilir ve neye erişebilir?” sorusunun cevabıdır. Otel ve B2B sistemlerinde stabilite; güvenliğin ayrılmaz parçasıdır. Resource limit yoksa bir worker tüm CPU’yu tüketebilir; network policy yoksa bir servis beklenmeyen yerlere bağlanabilir.
Runtime güvenliğinde resource ve network limitleri neden önemli?
Resource limitler CPU/memory tüketimini sınırlar ve OOM/CPU spike kaynaklı kesintileri azaltır. Network policy ise servislerin sadece gerekli hedeflere erişmesini sağlayarak lateral movement ve veri sızıntısı riskini düşürür. Bu iki kontrol birlikte, hem güvenliği hem stabiliteyi güçlendirir.
Resource limit (CPU/memory) ve stabilite
- •CPU limit ve request yaklaşımı (kapasite planı)
- •Memory limit ve OOM davranışı
- •Worker/batch işler için ayrı profil
Network policy ve servis izolasyonu
- •API gateway sadece backend’e, backend sadece DB’ye
- •Default-deny yaklaşımıyla başla, ihtiyaç kadar aç
- •Otel için rezervasyon servisi, ödeme ve PMS entegrasyonlarına sınırlı erişim
Observability: log/metric/trace olmadan runtime kördür
Runtime güvenliği için “kural” yetmez; görünürlük de gerekir. Rate limit tetiklenmeleri, OOM olayları, beklenmeyen outbound bağlantılar gibi sinyaller izlenebilir olmalı. (Internal link hedefi: /tr/veri-analiz-ve-raporlama)
☑ Mini Check: Runtime kontrol listesi
- •CPU/memory limit tanımlı mı?
- •OOM ve restart davranışı izleniyor mu?
- •Network policy default-deny var mı?
- •Secrets runtime’da veriliyor mu?
- •Log/metric ile anomali görünür mü?
Ne yapmalıyım?
- • Her servis için resource profil çıkar ve limitleri tanımla.
- • Default-deny network policy ile başla; gerekene izin ver.
- • Secrets runtime’da; loglarda masking.
- • Olay sinyallerini dashboard’a bağla (CPU spike, OOM, 429, outbound anomali).
5. Otel ve B2B İçin Container Senaryoları
Bu bölüm, güvenliği “iş akışı” ile bağlar: hangi servisler kritik, nerede limit/policy şart?
Otel — rezervasyon/back-office microservice’leri
- •Rezervasyon servisi: yüksek trafik, sıkı resource limit
- •Ödeme/checkout: en sıkı network policy + secret yönetimi
- •Back-office: role bazlı erişim, daha düşük dış dünya erişimi
B2B — API gateway ve worker container’ları
- •API gateway: rate limit/WAF entegrasyonları, kısa süreli loglar + audit
- •Worker: kaynak sınırı, queue tüketim kontrolü, outbound kısıtlar
- •Staging/prod: policy farkları kodla yönetilir (IaC ile uyum)
Otel ve B2B projelerinde container güvenliği için örnek adımlar neler?
Önce host’u harden edip yönetim erişimini sınırla; sonra minimal ve taranmış base image kullanıp secret’ları image’dan çıkar; son olarak runtime’da CPU/memory limit ve network policy uygula. Kritik servisler (rezervasyon, gateway, ödeme) için daha sıkı profil ve sürekli izleme/dashboards kur.
☑ Mini Check: Senaryo bazlı güvenlik doğrulaması
- •Kritik servisler için “sıkı profil” var mı?
- •Ödeme/rezervasyon servisinde outbound erişim minimal mi?
- •Worker’larda CPU/memory limit ve queue kontrolü var mı?
- •Image tarama sonucu redeploy ediliyor mu?
- •İzlenebilirlik raporlamaya bağlı mı?
Ne yapmalıyım?
- • Kritik servisleri etiketle (Tier-1) ve sıkı policy uygula.
- • Image scan + redeploy rutini kur.
- • Runtime limitleri standartlaştır; exception’ları kayıt altına al.
- • Sunucu güvenliği ve bakım-destek süreçleriyle entegre et (Internal link: /tr/yazilim/sunucu-guvenlik, /tr/yazilim/bakim-ve-destek).
6. İçerik İçi Tablo: Image Security ve Runtime Limit Örnekleri
| Katman | Kontrol | Amaç | Kanıt/Çıktı |
|---|---|---|---|
| Host | OS hardening + daemon kısıtı | Zemini sağlamlaştır | Host baseline raporu |
| Image | Minimal base + scan | CVE riskini azalt | Scan raporu + onaylı image listesi |
| Secrets | Secret manager | Sızıntıyı önle | Repo/image’da secret yok |
| Runtime | CPU/memory limit | Kesinti riskini azalt | OOM/CPU spike dashboard |
| Network | Network policy | Lateral movement azalt | Default-deny + izin listesi |
| Observability | Log/metric/alert | Erken uyarı | Dashboard + alert kuralları |
7. Container Host/Image/Runtime Güvenlik Checklist Şablonunu İndir
Checklist + Sprint Plan İçeriği
Container Host/Image/Runtime Güvenlik Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset, container güvenliğini host→image→runtime katmanlarında standartlaştırmak için hazırlanmıştır. Base image seçimi, vulnerability scanning, secret yönetimi ve runtime limit/policy kontrollerini tek listede toplar. Amaç; hem güvenlik olaylarını hem de stabilite sorunlarını erken yakalayan sürdürülebilir bir kontrol sistemi kurmaktır.
Kim Kullanır?
DevOps/SRE, platform mühendisliği, ajans teknik ekipleri (otel/B2B).
Nasıl Kullanılır?
- Host, image ve runtime için mevcut durumu işaretle.
- Kırmızı (kritik) maddeleri 14 günlük sprint planına aktar.
- KPI paneliyle tarama kapsaması ve OOM/CPU spike trendini takip et.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Host OS hardening ve patch rutini var
- ▢ ✅ Docker daemon erişimi kısıtlı
- ▢ ✅ Rootless/non-root default, privileged exception’lar kayıtlı
- ▢ ✅ Approved base image listesi var (resmî/minimal)
- ▢ ✅ CI’da image vulnerability scan zorunlu
- ▢ ✅ Registry’de periyodik tarama var
- ▢ ✅ Secrets image içine gömülmüyor (runtime secret store)
- ▢ ✅ CPU/memory limit tanımlı
- ▢ ✅ Network policy default-deny + izin listesi var
- ▢ ✅ OOM/CPU spike/WAF-like anomali dashboard ve alert var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Host hardening baseline
- •Approved base image listesi
- •CI scan gate + redeploy süreci
- •Network policy seti
- •KPI dashboard + alert runbook
Bir Sonraki Adım
Host, image ve runtime katmanlarında güvenlik/stabilite açıklarını tespit edip standardize etmek isteyen otel ve B2B DevOps/SRE ekipleri için.
Sık Sorulan Sorular
Container ve Docker güvenliği nasıl sağlanır?▾
Host ve image güvenliği için hangi adımları atmalıyım?▾
Runtime güvenliğinde resource ve network limitleri neden önemli?▾
Docker kullanıyoruz ama güvenliği tam bilmiyoruz, nereden başlamalıyız?▾
Secret’ları image içine koymak neden riskli?▾
Otel ve B2B projelerinde container güvenliği için örnek adımlar neler?▾
İlgili İçerikler