Özel Docker Registry ve Container İmaj Güvenliği

Özel Docker Registry ve Container İmaj Güvenliği Neden Bu Kadar Kritik?

SaaS ve kurumsal uygulamalarınızı container tabanlı bir mimariye taşıdığınız anda, üretim ortamınızın kalbi aslında artık container imajları olur. Uygulama kodunuz, framework’ler, kütüphaneler, hatta zaman zaman yanlışlıkla içine gömülen gizli anahtarlar… Hepsi registry’de tuttuğunuz imajların içinde. Dolayısıyla özel Docker registry yapınızın güvenliği, doğrudan işinizin sürekliliği ve veri güvenliğinizle bağlantılıdır.

DCHost tarafında SaaS müşterileriyle yaptığımız mimari tasarım ve güvenlik denetimi çalışmalarında, çoğu zaman herkes uygulama güvenliği, WAF, SSL gibi başlıklara odaklanırken, registry tarafı sonradan hatırlanıyor. Oysa tedarik zinciri (supply chain) saldırıları, son yıllarda en çok container imajları üzerinden yayılıyor. Zararlı bir base imaj, imza doğrulaması yapılmadan çekilen bir image, CI/CD hattında taranmayan bir bağımlılık, tek bir sunucuyu değil tüm altyapıyı etkileyebiliyor.

Bu yazıda, özel Docker registry kurarken ve işletirken dikkat etmeniz gereken güvenlik adımlarını; SaaS ve kurumsal senaryolar üzerinden, pratik ve uygulanabilir şekilde ele alacağız. DCHost altyapısında registry’nizi VPS, dedicated sunucu veya colocation üzerinde nasıl konumlandırabileceğinizi, imaj güvenliğini nasıl otomatik hale getirebileceğinizi ve KVKK/GDPR gibi regülasyonlarla uyumu nasıl sağlayabileceğinizi adım adım inceleyeceğiz.

Özel Docker Registry Nedir, Ne Zaman Gerekir?

Basitçe söylemek gerekirse özel Docker registry, container imajlarınızı yalnızca sizin kontrol ettiğiniz, erişimi sınırlandırılmış bir depoda saklamanızdır. Herkesin erişebildiği genel (public) registry’ler yerine; kendi alan adınızla, TLS sertifikanızla ve kendi erişim politikanızla çalışan bir imaj deposu kurarsınız.

Özel registry özellikle şu durumlarda neredeyse zorunlu hale gelir:

• SaaS ürünleri: Müşteriye özel feature flag’ler, custom build’ler, white-label arayüzler; hepsi registry’den çekilir. Erişim ve versiyon yönetimi kritikleşir.
• Kurumsal uygulamalar: İntranet uygulamaları, kritik iş süreçleri, KVKK/GDPR kapsamındaki veriyi işleyen servisler; imajların şirket dışına çıkmaması istenir.
• Regülasyon ve denetim: PCI-DSS, KVKK, ISO 27001 gibi standartlar; yazılım tedarik zincirinizin izlenebilir olmasını bekler.
• Performans ve ağ maliyeti: Sık güncellenen çok sayıda servis için, imajların yerel ağda veya aynı veri merkezinde bulunması çekme sürelerini ve bant maliyetini azaltır.

Container dünyasına yeni geçiyorsanız ve önce temel mimariyi oturtmak istiyorsanız, Docker ile VPS’te izole uygulama barındırma rehberimiz başlangıç için iyi bir tamamlayıcı olabilir. Özel registry, bu mimarinin bir sonraki adımıdır.

SaaS ve Kurumsal Uygulamalarda Container Tehdit Modeli

Registry ve imaj güvenliğini ciddiye almak için önce tehdit modelini netleştirmek gerekir. Container tabanlı bir SaaS veya kurumsal platformda tipik riskler şunlardır:

• Zararlı veya ele geçirilmiş base imajlar: İnternetten rastgele çekilen bir base imajın içine gizlenmiş backdoor, tüm servislerinize yayılabilir.
• İmaj içerisine gömülü gizli bilgiler: API anahtarları, veritabanı parolaları, access token’lar; image layer’lara bir kez yazıldı mı, pratikte geri alınamaz.
• Güncellenmeyen bağımlılıklar: Yıllarca aynı image tag’inin kullanılması, bilinen güvenlik açıklarına (CVE) davetiye çıkarır.
• İmajın transit sırasında değiştirilmesi: TLS olmayan veya zayıf yapılandırılmış registry bağlantıları, araya girme (MITM) saldırılarına açık hale gelir.
• Yetkisiz imaj çekme ve sızma: Registry’niz internete açık ve zayıf kimlik doğrulama ile korunuyorsa, saldırgan imajları indirip içindeki kodu ve yapılandırmayı analiz edebilir.
• CI/CD tedarik zinciri saldırıları: Build pipeline’ına sızan saldırgan, registry’ye zararlı ama “resmi” görünen yeni imajlar itebilir.

Tehdit modelini doğru kurduğunuzda, özel Docker registry’yi yalnızca bir depolama sistemi olarak değil; tıpkı veritabanı veya kimlik yönetim sistemi gibi, kritik altyapı bileşeni olarak görmeye başlarsınız.

Özel Docker Registry Mimarisi: Temel Bileşenler

Güvenli ve sürdürülebilir bir özel registry kurmak için mimariyi parçalara ayırmak faydalı olur:

• Registry sunucusu: Docker Registry, Harbor, Git tabanlı çözümler veya benzeri bir yazılım.
• Depolama katmanı: İmaj layer’larının tutulduğu block storage (NVMe), network file system veya S3 uyumlu object storage.
• Kimlik doğrulama ve yetkilendirme: Kullanıcı hesapları, servis hesapları, token tabanlı erişim, RBAC (role-based access control).
• Şifreleme ve ağ katmanı: TLS ile şifrelenmiş bağlantılar, mümkünse private network veya VPN üzerinden erişim.
• İzleme, loglama ve denetim: Kim hangi imajı ne zaman push/pull etti, kim hangi label’ı değiştirdi gibi olayların kaydı.

Registry’yi Nerede Çalıştırmalı? Tek VPS, Ayrı Sunucu, Küme…

DCHost müşterilerinde en sık gördüğümüz üç yaklaşım şöyle:

• Tek VPS üzerinde registry + CI/CD + uygulama: Küçük ekipler için hızlı başlangıç. Ancak güvenlik ve kaynak izolasyonu açısından orta vadede sınırlı.
• Ayrı bir registry VPS’i veya dedicated sunucu: Uygulama sunucularından ayrılmış, yalnızca imaj depolama ve dağıtımına odaklanan bir makine. Erişim politikalarını, yedeklemeyi ve izlemeyi sadeleştirir.
• Küme (Kubernetes, k3s vb.) içerisinde registry: Çok sayıda servis ve ekibin olduğu yapılarda, registry de küme içinde, internal network’te konumlandırılır.

Büyüyen projelerde doğru mimariyi seçmek için, Kubernetes vs Docker Compose vs Tek VPS karşılaştırma rehberimizi registry kararınızla birlikte değerlendirmenizi öneririz.

Container İmaj Güvenliği İçin En İyi Uygulamalar

Özel Docker registry sadece kapının kilidi; asıl önemli olan, içeri koyduğunuz imajların kalitesi ve güvenliği. Aşağıdaki pratikler, SaaS ve kurumsal ortamlarda büyük fark yaratır.

1. Güvenilir ve Minimal Base İmajlar Kullanın

Rastgele Dockerfile örneklerini kopyalamak yerine:

• Resmi veya güvendiğiniz kaynaklardan base imaj seçin.
• Alpine, distroless gibi minimal imajlar kullanarak saldırı yüzeyini küçültün.
• Multi-stage build ile build-time bağımlılıkları final imajdan çıkarın.

Bu sayede hem imaj boyutu küçülür hem de içeri girebilecek gereksiz paket sayısı azalır.

2. İmaj Tarama (Image Scanning) ve SBOM Üretimi

Her imaj push’unu otomatik olarak zafiyet taramasından geçirmek günümüzde neredeyse standart hale geldi. CI/CD pipeline’ınıza entegre edeceğiniz tarayıcılar ile:

• Base imaj ve bağımlılık paketlerindeki bilinen CVE’leri yakalarsınız.
• Her build’te bir SBOM (Software Bill of Materials) üreterek; hangi versiyonun içinde hangi kütüphanenin olduğunu kayıt altına alırsınız.
• Yeni bir kritik zafiyet çıktığında, hangi imajların etkilendiğini hızlıca tespit edebilirsiniz.

Güvenlik ekibiyle uyumlu çalışmak için SBOM ve tarama raporlarının saklanacağı merkezi bir log ve raporlama altyapısı kurmak iyi bir pratiktir. DCHost üzerinde Loki + Promtail ile merkezi loglama anlatımımız, bu işin altyapı tarafını tasarlarken işinize yarayabilir.

3. Container’lara Secret Gömme Hatasından Kaçının

Belki de en yaygın ve en tehlikeli hata, veritabanı parolasını, üçüncü parti API anahtarını veya JWT imzalama secret’ını doğrudan Dockerfile içine yazmak. Bu bilgiler build sırasında imaj layer’larına girer ve pratikte silinemez. İmajı kim indirirse, bu bilgilere erişebilir.

Doğru yaklaşım:

• Secret’ları hiçbir zaman imaja veya repoya gömmemek.
• Ortam değişkeni, secret store veya orchestration katmanı üzerinden runtime’da enjekte etmek.
• Secret rotasyonunu (anahtar değiştirme) düzenli ve otomatik hale getirmek.

Bu konuyu derinlemesine ele aldığımız VPS üzerinde gizli bilgi yönetimi rehberimizi mutlaka okumanızı öneririm. Daha ileri seviye için de, VPS’te secrets yönetimi ve rotasyon stratejilerini anlattığımız yazı işinize yarayacaktır.

4. Tag Stratejisi: latest Her Zaman Kötü Fikirdir

İmaj tag’lerini rastgele kullanmak, üretim ortamında öngörülemez davranışlara yol açar. Öneriler:

• Üretimde asla sadece latest kullanmayın.
• Semantik versiyonlama (1.4.2 gibi) ve build numaralarını bir arada kullanın.
• Immutable tag yaklaşımı kullanın; bir tag tekrar push edildiğinde farklı imaj üretmesin.
• Tag’leri branch/ortam bazlı (prod, staging, canary) anlamlı biçimde tasarlayın.

5. İmaj İmzalama ve Politikalar

İmaj imzalama, registry’ye push edilen bir imajın gerçekten sizin CI/CD hattınızdan çıktığını kriptografik olarak kanıtlamanızı sağlar. Bu sayede:

• Kubernetes admission controller veya benzeri mekanizmalarla, sadece imzalı imajların çalışmasına izin verebilirsiniz.
• Registry’niz ele geçirilse bile, imzalanmamış sahte imajlar production’a çıkamaz.

İmza doğrulamasını devreye almak, teoride karmaşık görünse de; küçük SaaS projelerinde bile kademeli bir şekilde uygulanabilir. Örneğin önce yalnızca kritik servisler için zorunlu kılar, sonra kapsamı genişletirsiniz.

6. Network, TLS ve Erişim Kontrolü

Registry’nin dış dünyaya nasıl açıldığını da titizlikle tasarlamak gerekir:

• Mutlaka TLS (HTTPS) kullanın; geçerli bir sertifika ile.
• Mümkünse registry’yi tamamen public internete açmayın, yalnızca VPN veya özel ağ (private network) üzerinden erişim verin.
• IP tabanlı kısıtlamalar ve rate limiting ile brute-force denemelerini zorlaştırın.
• Erişim loglarını merkezi olarak toplayın; olağan dışı ip/pattern’leri tespit edin.

Genel erişim mimarisini tasarlarken, Zero Trust ile sunucu erişimini güvenceye alma rehberimiz registry dahil tüm yönetim panelleri için iyi bir çerçeve sunuyor.

Özel Docker Registry’yi Güvenli Şekilde Yayına Alma: Adım Adım

Teoriyi pratik hale getirmek için, DCHost üzerinde çalışan tipik bir senaryoyu adım adım düşünelim. Varsayalım ki SaaS uygulamanız için bir registry kurmak istiyorsunuz ve bunu ayrı bir VPS üzerinde çalıştıracaksınız.

1. Altyapıyı ve Kaynakları Planlayın

• Günlük/aylık push-pull sayınızı ve ortalama imaj boyutlarını tahmin edin.
• I/O performansı için NVMe diskli bir VPS veya dedicated sunucu tercih edin.
• Uzun vadeli saklama için harici object storage ya da snapshot tabanlı yedek stratejisi tasarlayın.

DCHost tarafında, registry trafiğinin yoğun olduğu müşterilerde genellikle uygulama sunucularından ayrı bir storage odaklı VPS veya dedicated sunucu kullanıyor, yedekleri ise farklı depolama katmanlarına dağıtıyoruz. Bu stratejiyi sıcak, soğuk ve arşiv depolama stratejisi yazımızda detaylı anlattık.

2. DNS ve TLS Sertifikasını Kurun

• registry.example.com gibi anlamlı bir subdomain belirleyin.
• Bu alan adını registry VPS’inizin IP’sine yönlendirin.
• Let’s Encrypt veya kurumsal bir CA’den TLS sertifikası alın.
• Sertifika yenilemesini otomatikleştirin; süresi dolmuş sertifika yüzünden CI/CD’nin durması oldukça yaygın bir hata.

Birden fazla alan adında otomatik SSL yönetiyorsanız, Let’s Encrypt wildcard SSL otomasyonu rehberimiz registry için de uyarlanabilir.

3. Kimlik Doğrulama, RBAC ve Projeler

Registry’yi anonymous erişime açmak yerine:

• Takım üyeleri için bireysel kullanıcı hesapları oluşturun.
• CI/CD için ayrı servis hesapları ve dar yetkili token’lar tanımlayın.
• Projeleri (örneğin frontend, backend, worker, raporlama) ve ortamları (dev, staging, prod) ayrı namespace’ler altında düzenleyin.
• Pull-only, push-pull gibi rollerle yetkilendirmeyi ince ayar yapın.

Yetki mimarisini genel Linux kullanıcı/grup yönetimi ile uyumlu düşünmek isterseniz, Linux VPS’te kullanıcı, grup ve sudo mimarisi yazımızdan esinlenebilirsiniz.

4. Ağ Güvenliği: Güvenlik Duvarı ve Erişim Katmanı

Registry sunucusunun ağ yüzeyini minimumda tutmak için:

• Yalnızca 80/443 (ve yönetim için gerekiyorsa SSH) portlarını açık bırakın.
• SSH erişimini IP kısıtlaması, anahtar tabanlı giriş ve fail2ban benzeri araçlarla koruyun.
• Registry’yi yalnızca belirli uygulama ve CI/CD sunucularının erişebildiği private bir VLAN içine almak mümkünse en sağlıklısı budur.

Ağ ve sunucu güvenliğini adım adım sertleştirmek için, VPS güvenlik sertleştirme kontrol listemiz registry sunucusu için de birebir uygulanabilir.

5. Yedekleme ve Felaket Kurtarma

Container imajları teorik olarak tekrar build edilebilir olsa da, pratikte registry’niz tek gerçek kaynak (source of truth) haline gelir. Özellikle eski ama hala çalışan sürümlere hızlıca dönebilmek için registry verisinin yedeği hayati önem taşır.

• Registry’nin depolama backend’ini düzenli snapshot veya object storage replikasyonu ile koruyun.
• 3-2-1 kuralına (3 kopya, 2 farklı ortam, 1 offsite) uygun yedek tasarlayın.
• Yalnızca yedek almakla kalmayın, geri yükleme tatbikatı yapın.

Felaket senaryolarına hazır olmak için, felaket kurtarma provası rehberimizde anlattığımız test yaklaşımını registry için de uygulayabilirsiniz.

6. İzleme, Alarm ve Kapasite Yönetimi

Registry’ye gelen istek sayısı, yanıt süreleri, disk doluluk oranı, hata kodları (5xx), push/pull oranları gibi metrikleri izlemeden, sistemin sağlığını anlamak zordur. Öneriler:

• Prometheus + Grafana veya benzeri bir izleme yığınıyla temel metrikleri toplayın.
• Disk doluluğu ve HTTP hata oranları için alarm eşikleri belirleyin.
• Beklenmedik push/pull artışlarını tespit edip olası bir sızıntıyı hızlıca fark edin.

Bunu daha geniş VPS izleme yapınızın bir parçası yapmak için, VPS izleme ve alarm kurulumu rehberimiz işe yarayacaktır.

SaaS ve Kurumsal Senaryolar: Örnek Mimariler

Senaryo 1: Küçük SaaS Ürünü, Tek Bölge, Tek Registry

3–4 geliştiricili bir ekibiniz var, tek bir ülkede hizmet veriyorsunuz ve Docker Compose ile production ortamı yönetiyorsunuz. Bu durumda:

• DCHost üzerinde bir registry VPS’i, bir de uygulama VPS’i kullanmak çoğu zaman yeterli olur.
• CI/CD pipeline’ınız (örneğin Git tabanlı) her deploy’da imajı build edip registry’ye push eder, uygulama VPS’i de oradan çekerek deploy eder.
• Registry’ye yalnızca ilgili VPS IP’lerinden erişim vererek saldırı yüzeyini ciddi oranda küçültürsünüz.

Bu yapıya geçerken, küçük SaaS uygulamaları için Docker Compose production mimarisi rehberimiz size somut bir yol haritası sağlayacaktır.

Senaryo 2: Orta Ölçekli Kurumsal Uygulama, Çoklu Ortamlar

Kurumsal tarafta daha sık gördüğümüz modelde; dev, test, staging ve prod ortamları ayrıdır. İmaj güvenliği açısından iyi bir yaklaşım:

• Tek bir merkezi registry kullanmak, ancak projeleri ve ortamları namespaces ile ayırmak.
• Geliştirme ekiplerine dev/test namespace’lerinde daha geniş yetkiler, prod tarafında ise yalnızca CI/CD servis account’larına push yetkisi vermek.
• İmaj tarama ve imza zorunluluğunu önce prod için devreye almak, sonra kademeli olarak diğer ortamlara yaymak.

Böyle bir yapıda registry’nizin bulunduğu veri merkezinin konumu da önem kazanır. Özellikle kişisel veri işliyorsanız, veri yerelleştirme ve KVKK/GDPR uyumlu hosting rehberimiz ile registry’yi hangi ülke/bölgede konumlandıracağınızı birlikte düşünmek gerekir.

Senaryo 3: Multi-Tenant SaaS, Müşteri Bazlı Özelleştirmeler

Multi-tenant bir SaaS ürününde bazı müşteriler için özel branch’ler, feature flag kombinasyonları veya ek modüller olabilir. Registry tarafında sık kullanılan yaklaşım:

• Temel ürün için ortak bir imaj seti ve tag stratejisi tasarlamak.
• Büyük veya regüle müşteriler için müşteri ID’sine özel imaj tag’leri üretmek (örneğin app:1.5.0-client123).
• Müşteri alan adları ve SSL yönetimini, registry’den çekilen versiyon bilgisiyle uyumlu tasarlamak.

Bu noktada, multi-tenant SaaS uygulamalarında müşteri alan adı yönetimi yazımızı registry stratejinizle birlikte okumanızı öneririz; çünkü müşteri bazlı routing ve versiyonlama çoğu zaman aynı mimarinin parçası haline geliyor.

DCHost Olarak Özel Docker Registry Altyapılarını Nasıl Tasarlıyoruz?

DCHost tarafında container tabanlı projelerle çalışırken registry’yi, diğer tüm bileşenler kadar ciddiye alıyoruz. Tipik yaklaşımımız şu adımları içeriyor:

• Altyapı ayrıştırması: Registry için ayrı VPS veya dedicated sunucu, mümkünse ayrı depolama katmanı.
• Yüksek performanslı depolama: Sık kullanılan imajlar için NVMe tabanlı depolama, uzun vadeli saklama için daha ekonomik katmanlar.
• Çok katmanlı güvenlik: Güvenlik duvarı, Zero Trust erişim modeli, TLS 1.2/1.3 zorlaması, kayıtlı IP aralıkları.
• Merkezi loglama ve izleme: Registry erişim loglarının ve metriklerinin diğer uygulama log’larıyla birlikte toplanması.
• Yedekleme ve DR: Registry verilerinin ayrı bir bölge veya platforma periyodik olarak kopyalanması, geri yükleme senaryolarının önceden test edilmesi.

Ekibinizle birlikte mimari tasarım yaparken, yalnızca bugün kaç imajınız olduğuna değil; iki yıl sonraki ölçek, regülasyon gereklilikleri ve ekip sayısındaki artışa da bakıyoruz. Böylece bugün kurduğunuz özel Docker registry, yarın mimariyi değiştirmek zorunda kalacağınız bir geçici çözüm olmaktan çıkıp, uzun vadeli bir yatırım haline geliyor.

Sonuç: Özel Docker Registry, Sadece Bir Depo Değil, Güvenlik Katmanıdır

Container dünyasına adım attığınız anda, uygulamanızın “binary” karşılığı artık container imajlarıdır. Bu imajları nasıl ürettiğiniz, nerede sakladığınız, kimlerin erişebildiği ve ne kadar hızlı güncel tuttuğunuz; hem güvenlik hem de operasyonel verimlilik açısından kritik rol oynar. Özel Docker registry, doğru tasarlandığında sadece imaj depolayan bir servis değil; tedarik zinciri güvenliğinizin ve denetlenebilirliğinizin merkezidir.

Bu yazıda; tehdit modelinden mimariye, image scanning ve imzalamadan ağ güvenliğine kadar pek çok başlığa değindik. Şimdi kendi yapınızı değerlendirip şu soruları sormanın tam zamanı: Registry’m şu anda nerede çalışıyor? Erişimler nasıl denetleniyor? İmajlarım taranıyor ve imzalanıyor mu? Yarın bir zafiyet çıktığında hangi sürümlerin etkilendiğini kaç dakikada bulabilirim?

Eğer bu soruların cevabı net değilse, DCHost ekibi olarak registry mimarinizi gözden geçirmenize ve gerekirse yeni bir özel Docker registry altyapısı kurmanıza yardımcı olabiliriz. Container mimarisi, CI/CD, yedekleme ve güvenlik adımlarını birlikte tasarlayarak; SaaS veya kurumsal uygulamalarınızı daha öngörülebilir, denetlenebilir ve güvenli bir zemine taşıyabiliriz. Bir sonraki adım için, ekibinizle birlikte küçük bir kapasite ve güvenlik analizi toplantısı planlamanız yeterli.