Konteyner Güvenliği: Spring Uygulamalarını Üretime Taşımak

Java/Spring uygulamaları için konteyner güvenliği: root olmayan kullanıcı, minimal taban imajlar, imaj tarama, sır yönetimi, salt okunur dosya sistemi ve dağıtım disiplini.

Güvenli çok aşamalı Java imajını gösteren Dockerfile editör penceresi

Konteyner güvenliği nerede başlar?

Konteyner güvenliği Kubernetes'te değil, Dockerfile'ın ilk satırında başlar: taban imaj seçimi, çalıştırma kullanıcısı ve imaja giren her katman, üretimdeki saldırı yüzeyinizi belirler. Java/Spring uygulamaları için iyi haber şu: güvenli konteyner pratikleri az sayıda, net ve otomatikleştirilebilir kuraldan oluşur. Bu yazı o kuralları derler.

Taban imaj: küçük yüzey, az zafiyet

Tam işletim sistemi içeren geniş imajlar, uygulamanızın hiç kullanmadığı yüzlerce paketi — ve onların zafiyetlerini — taşır. Java için doğru yön minimal taban imajlardır: yalnızca JRE içeren resmi imajlar veya distroless yaklaşımı. İkinci kural sürüm disiplinidir: taban imajı latest ile değil, sürüm + digest sabitleyerek referanslayın — böylece derlemeler tekrarlanabilir olur ve imaj güncellemesi bilinçli bir karar haline gelir. Çok aşamalı (multi-stage) derleme, JDK ve derleme araçlarının üretim imajına sızmasını engeller.

Root olmayan kullanıcı: tek satırlık büyük fark

Konteyner içinde uygulamanın root olarak çalışması, konteyner kaçışı senaryolarında ve dosya sistemi manipülasyonlarında saldırganın işini kolaylaştırır. Dockerfile'da adanmış bir kullanıcı oluşturup USER ile geçmek çoğu uygulama için maliyetsizdir. Tamamlayıcıları: kök dosya sisteminin salt okunur bağlanması (yazma ihtiyacı olan dizinler için ayrı geçici birimler) ve ayrıcalık yükseltmenin kapatılması. Spring uygulamaları bu kısıtlarla sorunsuz çalışır; geçici dosya dizini gibi ihtiyaçlar bilinçli olarak tanımlanır.

Sırlar: imaja değil, çalışma zamanına

İmaj katmanlarına giren her şey kalıcıdır: Dockerfile'da ENV ile verilen parola, kopyalanan yapılandırma dosyasındaki API anahtarı, imajı çeken herkes tarafından okunabilir. Kural nettir: sır imaja girmez. Sırlar çalışma zamanında sağlanır — orkestratörün sır mekanizması, harici kasa (vault) çözümleri veya bulut sağlayıcının sır servisleri. Aynı disiplinin parçası: derleme argümanlarıyla (build arg) sır geçirmemek, çünkü bunlar da imaj geçmişinde iz bırakabilir.

İmaj tarama: CI'ın kapanış adımı

Uygulama bağımlılıklarını taramak yetmez; taban imajın işletim sistemi paketleri de zafiyet taşır. Trivy veya Grype gibi araçlarla imaj taraması CI hattının zorunlu adımı olmalı, kritik bulguda dağıtım durmalıdır. Tamamlayıcısı imaj imzalamadır: yalnızca CI'ın ürettiği ve imzaladığı imajların üretim ortamına kabul edilmesi, tedarik zinciri savunmasının konteyner ayağıdır.

JVM ve kaynak sınırları: konteynerle barışık Java

Modern JVM'ler konteyner kaynak sınırlarını tanır ve bellek ayarlarını buna göre yapar; yine de bellek limiti ile JVM yığın yapılandırmasının birlikte planlanması gerekir — limitin üstüne çıkan konteyner, orkestratör tarafından sonlandırılır ve bu, güvenlik olayı olmasa da erişilebilirlik olayıdır. Kaynak limitleri aynı zamanda güvenlik kontrolüdür: sınırsız konteyner, ele geçirildiğinde komşularını da boğar.

Ağ ve gözlemlenebilirlik: son katman

Konteynerler arası trafik varsayılan olarak serbest bırakılmamalı; ağ politikalarıyla yalnızca gerekli servisler arası iletişim tanımlanmalıdır. Loglar merkezî toplanmalı, konteyner içinde tutulmamalıdır. Sağlık uçları (health/readiness) dışarıya değil, yalnızca orkestratöre açık olmalıdır — Spring Actuator kuralları konteyner dünyasında da aynen geçerlidir.

İş etkisi: dağıtım disiplini güven üretir

Kurumsal müşterilerin bulut güvenlik değerlendirmeleri artık imaj kaynağını, tarama sürecini ve sır yönetimini soruyor; regülasyona tabi sektörlerde bunlar sözleşme eki haline geliyor. İmzalı imaj, tarama raporu ve sır politikasını belgeleyebilen tedarikçi, üretim erişimi tartışmalarını kısaltır. Konteyner disiplini, DevOps hızından vazgeçmeden denetlenebilirlik kazandırır — hız ve güvenin aynı anda satıldığı yer burasıdır.

Sık sorulan sorular

Alpine tabanlı imaj kullanmalı mıyım?

Küçüklük avantajı gerçektir; ancak farklı C kütüphanesi (musl) bazı Java iş yüklerinde sürpriz üretebilir. Minimal JRE imajları veya distroless, Java için çoğu zaman daha öngörülebilir dengedir.

İmajı ne sıklıkla yeniden derlemeliyim?

Taban imaj güncellemelerini düzenli (ör. haftalık) almak ve kritik zafiyet duyurularında plansız yeniden derleme yapmak sağlıklı ritimdir; digest sabitleme bunu bilinçli bir süreç haline getirir.

Sırları ortam değişkeniyle vermek güvenli mi?

Dosya tabanlı sır bağlama veya kasa entegrasyonu, ortam değişkenlerine göre daha az sızıntı yüzeyi taşır (env çıktıları, hata raporları). Ortam değişkeni kullanılacaksa loglama ve hata raporlarında maskeleme zorunludur.

Konteyner içinde JDK mı JRE mi olmalı?

Üretimde yalnızca çalıştırma için gerekenler bulunmalı: JRE (veya jlink ile üretilmiş özel çalışma zamanı). JDK ve derleme araçları çok aşamalı derlemenin ilk aşamasında kalır.

Konteyner güvenlik kontrol listesi

  1. Minimal taban imaj; sürüm + digest sabitli

  2. Çok aşamalı derleme; üretim imajında yalnızca çalışma zamanı

  3. Root olmayan kullanıcı; salt okunur kök dosya sistemi

  4. Sırlar imaj dışında; çalışma zamanında sağlanıyor

  5. CI'da imaj taraması; kritik bulguda dağıtım duruyor

  6. İmaj imzalama ve üretimde doğrulama aktif

  7. Kaynak limitleri ve ağ politikaları tanımlı

SSH Yazılım, Java/Spring iş yükleri için güvenli konteynerleştirme, CI/CD sertleştirme ve dağıtım güvenliği danışmanlığı sunar. Dağıtım hattınızı birlikte gözden geçirelim.