Kurum İçi Docker Registry Kurulumu ve Yönetimi

Kurumların container tabanlı uygulamalara geçmesiyle birlikte image dosyalarının nerede saklandığı, kim tarafından güncellendiği ve hangi koşullarda production ortamına taşındığı ciddi bir operasyon konusu haline geldi. Kurum İçi Docker Registry Kurulumu ve Yönetimi yalnızca bir sunucuya registry container'ı kurup port açmaktan ibaret değildir. Gerçek bir production ortamında TLS, kullanıcı doğrulama, erişim kontrolü, image tarama, imzalama, yedekleme, kapasite yönetimi ve CI/CD entegrasyonu birlikte düşünülmelidir. Yıllar içinde karşılaştığım en yaygın sorunlardan biri, registry altyapısının başlangıçta küçük bir dosya deposu gibi kurulması ve ekip sayısı arttığında güvenlik ile operasyon ihtiyaçlarının sonradan eklenmeye çalışılmasıdır. Bu rehberde kurum içi Docker Registry nasıl kurulur, private Docker Registry kurulumu ve yönetimi nasıl yapılır ve şirket içi container registry image scanning backup ve storage yönetimi nasıl ele alınır sorularını production odaklı bir yaklaşımla ele alacağız.

Docker Registry Nedir?

Docker Registry, container image dosyalarının merkezi olarak saklandığı ve istemcilere dağıtıldığı bir servis katmanıdır. Bir geliştirici bilgisayarında oluşturulan image, registry'ye gönderildiğinde ekipteki diğer geliştiriciler, CI/CD sunucuları veya Kubernetes cluster'ları aynı image'ı kontrollü biçimde kullanabilir. Registry yaklaşımı sayesinde image dosyalarının geliştirici makineleri arasında manuel olarak taşınmasına gerek kalmaz. Ayrıca hangi uygulamanın hangi sürümünün nerede bulunduğu merkezi biçimde görülebilir. Production açısından asıl değer, image dağıtımının izlenebilir, yetkilendirilebilir ve otomasyona uygun hale gelmesidir.

Container Registry Nasıl Çalışır?

Container registry, istemciden gelen push ve pull isteklerini standart HTTP API üzerinden işler. Bir kullanıcı image gönderdiğinde registry önce manifest bilgisini ve ardından gerekli layer dosyalarını kabul eder. Aynı layer daha önce sisteme yüklenmişse tekrar kaydedilmesine gerek olmayabilir ve bu durum depolama alanından tasarruf sağlar. Pull işleminde istemci, ihtiyaç duyduğu manifest ve layer verilerini registry üzerinden alır. Kimlik doğrulama, TLS ve erişim kontrolü eklendiğinde bu işlem güvenli bir dağıtım zincirine dönüşür.

Docker Image Registry'de Nasıl Saklanır?

Docker image tek bir büyük dosya gibi saklanmaz. Image; manifest, layer, digest ve repository ilişkileriyle organize edilen içeriklerden oluşur. Registry'nin storage yapısı bu içerikleri birbirinden ayırarak tekrar kullanılabilir biçimde saklar. Böylece benzer image'ların ortak layer kullanması mümkün olur. Bu mimari özellikle yüzlerce build üreten ekiplerde storage kapasitesinin daha kontrollü kullanılmasını sağlar.

Repository

Repository, belirli bir uygulama veya image ailesini mantıksal olarak bir arada tutan alandır. Örneğin bir backend uygulamasının farklı sürümleri aynı repository altında tutulabilir. Repository isimleri ekip, uygulama veya proje yapısına göre standartlaştırılmalıdır. Dağınık isimlendirme zamanla erişim yönetimini ve retention politikalarını zorlaştırır. Bu nedenle repository yapısı registry kurulmadan önce belirlenmesi gereken temel tasarım kararlarından biridir.

Tag

Tag, bir image sürümünü insanlar açısından anlaşılır biçimde işaretlemek için kullanılır. Örneğin 1.4.2, staging veya build-148 gibi tag değerleri kullanılabilir. Tag değerleri değiştirilebilir olduğu için production ortamlarında yalnızca tag'e güvenmek risk oluşturabilir. Özellikle latest etiketi farklı zamanlarda farklı içerikleri gösterebilir. Bu yüzden deployment süreçlerinde digest tabanlı referans kullanılması daha güvenli bir yöntemdir.

Manifest

Manifest, image'ın hangi layer'lardan oluştuğunu ve ilgili metadata bilgilerini tanımlar. Registry istemcisi bir image çekmek istediğinde önce manifest bilgisini alır. Ardından manifest içinde belirtilen layer içeriklerine erişir. Multi-architecture image yapılarında manifest listeleri farklı işlemci mimarilerini tanımlamak için de kullanılabilir. Manifest bütünlüğü, image'ın doğru içerikle dağıtılabilmesi açısından kritik öneme sahiptir.

Layer

Layer, container image dosya sisteminin katmanlarından biridir. Dockerfile içindeki belirli adımlar yeni layer üretimine yol açabilir. Registry aynı layer'ı kullanan farklı image'larda veriyi tekrar saklamadan paylaşabilir. Bu durum depolama alanını ve transfer miktarını azaltabilir. Ancak gereksiz büyük layer üretimi hem build sürelerini hem de push ve pull performansını olumsuz etkiler.

Digest

Digest, image veya manifest içeriğini kriptografik olarak tanımlayan değişmez bir değerdir. SHA-256 tabanlı digest kullanımı, belirli bir image içeriğinin kesin olarak referans edilmesini sağlar. Bir tag daha sonra başka image'a taşınabilir ancak digest aynı içerik için değişmez. Bu özellik production deployment güvenliği açısından oldukça değerlidir. Kubernetes manifestlerinde digest kullanmak, beklenmeyen image değişikliklerinin önüne geçmeye yardımcı olur.

Docker Hub ile Private Registry Arasındaki Fark

Public registry hizmetleri genel image dağıtımı için kullanışlıdır ancak kurum içi sistemlerde kontrol gereksinimleri daha farklıdır. Private registry ile image dosyaları kurumun belirlediği ağ, storage ve güvenlik politikaları içinde tutulabilir. Kullanıcı yetkileri, erişim kayıtları ve retention süreçleri şirket politikalarına göre yönetilebilir. İnternet bağlantısının sınırlı olduğu ortamlarda kurum içi registry ayrıca operasyonel süreklilik sağlar. Bu nedenle hassas uygulamalar, düzenlemeye tabi ortamlar ve yoğun CI/CD kullanımı bulunan yapılarda private registry güçlü bir seçenek haline gelir.

Container Registry ile Artifact Repository Arasındaki Fark

Container registry temel olarak OCI ve container image formatlarına odaklanır. Artifact repository ise paket, binary, bağımlılık veya farklı yazılım çıktıları gibi daha geniş içerik türlerini saklayabilir. Bazı platformlar iki ihtiyacı aynı sistem içinde karşılayabilir ancak mimari karar verirken gerçek kullanım senaryosu dikkate alınmalıdır. Yalnızca container image yönetilecekse daha sade bir registry yapısı operasyonu kolaylaştırabilir. Çok sayıda artifact formatı kullanılacaksa merkezi artifact yönetimi farklı gereksinimler doğurabilir.

Docker Registry ve OCI Registry Arasındaki Fark

Docker Registry kavramı tarihsel olarak Docker image dağıtımıyla ilişkilidir. OCI standartları ise container image ve ilişkili artifact yapılarının daha geniş bir ekosistemde ortak biçimde çalışmasını amaçlar. Modern registry çözümleri çoğu zaman OCI uyumlu artifact depolama özellikleri sunar. Bu sayede yalnızca image değil, imza, SBOM veya başka ilişkili artifact türleri de registry içinde tutulabilir. Yeni kurulumlarda OCI uyumluluğu uzun vadeli entegrasyon açısından önemli bir seçim kriteridir.

Kurum İçi Docker Registry Nedir?

Kurum içi registry, container image depolama ve dağıtım altyapısının kurumun kontrol ettiği sunucu, veri merkezi veya private cloud ortamında çalıştırılmasıdır. Buradaki ana fikir, kritik image verisinin ve erişim politikalarının dış bir servise tamamen bağımlı olmamasıdır. Kurum kendi DNS, TLS, authentication, storage, backup ve monitoring yapısını belirler. Bu kontrol seviyesi güvenlik açısından avantaj sağlar ancak operasyon sorumluluğunu da beraberinde getirir. Kurum İçi Docker Registry Kurulumu ve Yönetimi planlanırken yalnızca kurulum kolaylığı değil, sistemin üç yıl sonra nasıl işletileceği de düşünülmelidir.

Self-Hosted Registry Ne Demektir?

Self-hosted registry, registry servisinin kurum tarafından yönetilen altyapıda çalıştırılması anlamına gelir. İşletim sistemi güncellemeleri, storage kapasitesi, sertifika yenileme ve backup süreçleri kurumun sorumluluğundadır. Bu model veri üzerinde yüksek kontrol sağlar. Buna karşılık monitoring, high availability ve disaster recovery gibi konuların ayrıca tasarlanması gerekir. Küçük bir ekipte tek sunucu yeterli olabilirken production ortamında yedeklilik ihtiyacı hızlı biçimde ortaya çıkar.

On-Premise Registry

On-premise registry doğrudan kurumun fiziksel veri merkezi içinde çalışır. Network erişimi çoğu zaman kurumun iç ağı veya VPN üzerinden sınırlandırılır. Bu yaklaşım düşük latency ve veri egemenliği açısından fayda sağlayabilir. Özellikle dış internet erişiminin sınırlı olduğu sistemlerde image dağıtımı daha öngörülebilir hale gelir. Buna karşılık donanım kapasitesi ve disaster recovery sorumluluğu tamamen kurum tarafından yönetilir.

Private Cloud Registry

Private cloud üzerinde çalışan registry, sanallaştırılmış veya kurum kontrolündeki cloud altyapısından yararlanır. Kaynakların artırılması fiziksel sunucuya göre daha kolay olabilir. Object storage, load balancer ve otomatik backup gibi altyapı servislerinden yararlanmak mümkündür. Ancak network tasarımı ve erişim sınırları doğru yapılmadığında beklenenden daha açık bir mimari oluşabilir. Bu nedenle private cloud kullanılması güvenlik kontrollerinin azaltılması anlamına gelmemelidir.

Air-Gapped Registry

Air-gapped registry, internet erişimi olmayan veya dış ağlarla çok sınırlı iletişim kuran ortamlar için tasarlanır. Image dosyaları kontrollü transfer süreçleriyle iç ortama alınır. Vulnerability database güncellemeleri de çevrimdışı paketler üzerinden gerçekleştirilebilir. İmza doğrulama ve artifact kaynağı kontrolü burada daha önemli hale gelir. Çünkü dış dünyadan alınan her dosya iç ortama girmeden önce doğrulanmalıdır.

Hibrit Registry

Hibrit modelde kurum içi registry ile dış kaynaklı registry sistemleri birlikte kullanılabilir. Örneğin public base image'lar proxy cache üzerinden kontrollü biçimde içeri alınabilir. Kurumun kendi uygulama image'ları ise tamamen private alanda tutulabilir. Bu yapı esneklik sağlar fakat hangi image'ın hangi kaynaktan alınabileceğine ilişkin net politikalar gerektirir. Aksi durumda ekipler güvenlik kontrollerini atlayarak doğrudan dış kaynaklardan image çekebilir.

Kurumlar Neden Kendi Docker Registry'sini Kurar?

Kurumların private registry tercih etmesinin tek nedeni gizlilik değildir. Performans, network bağımsızlığı, merkezi yetki, audit kayıtları ve güvenlik politikaları da önemli nedenlerdir. Özellikle çok sayıda build ve deployment yapan ekiplerde image trafiği ciddi seviyelere ulaşabilir. Registry'nin uygulama ekiplerine yakın konumlandırılması pull sürelerini düşürebilir. Ayrıca güvenlik ekibi hangi image'ın production ortamına girdiğini merkezi biçimde takip edebilir.

Kaynak Kod ve Image Gizliliği

Container image içinde uygulama binary'leri, yapılandırmalar ve bazı durumlarda hassas dosyalar bulunabilir. Bu nedenle image dosyalarının kimler tarafından erişilebilir olduğu ciddi bir güvenlik konusudur. Private registry, repository erişimini ekip ve proje bazında sınırlandırmayı mümkün kılar. Ayrıca yanlışlıkla public paylaşım riskini azaltır. Yine de secret bilgilerinin image içine eklenmemesi gerektiği unutulmamalıdır.

Veri Egemenliği

Bazı kurumlar belirli verilerin fiziksel veya hukuki olarak tanımlı bölgelerde kalmasını ister. Registry içinde tutulan image ve metadata bilgileri de bu kapsama girebilir. On-premise veya private cloud mimarisi veri konumunu daha doğrudan yönetmeye yardımcı olur. Backup kopyalarının nerede tutulduğu da aynı politikanın parçasıdır. Bu nedenle registry tasarımında primary storage kadar off-site backup konumu da değerlendirilmelidir.

Public Registry Bağımlılığını Azaltmak

CI/CD sürecinin her build sırasında internet üzerinden image çekmesi dış bağlantıya bağımlılık oluşturur. Bağlantı sorunu yaşandığında build ve deployment süreçleri durabilir. Proxy cache veya kurum içi mirror kullanımı bu bağımlılığı azaltır. Sık kullanılan base image'lar bir kez içeri alındığında sonraki kullanımlar lokal altyapıdan karşılanabilir. Bu yaklaşım aynı zamanda hangi public image sürümlerinin kurum içinde kullanıldığını daha görünür hale getirir.

Docker Hub Rate Limitlerini Azaltmak

Yoğun build ortamlarında public registry üzerinden yapılan pull işlemleri kota veya hız sınırlamalarına takılabilir. Proxy cache kullanımı aynı image layer'larının tekrar tekrar dışarıdan indirilmesini önleyebilir. Bu sayede build süreleri daha kararlı hale gelir. Network çıkış trafiği de azalabilir. Büyük CI/CD altyapılarında yalnızca bu fayda bile kurum içi cache kullanımını anlamlı hale getirebilir.

Düşük Network Latency

Registry'nin build sunucularına ve Kubernetes cluster'larına yakın olması image transfer süresini azaltabilir. Büyük image dosyalarında bu fark daha belirgin hale gelir. Özellikle çok sayıda node aynı image'ı eş zamanlı olarak çekiyorsa network kapasitesi önemli olur. Bölgesel registry veya replication modelleri coğrafi olarak dağıtık sistemlerde fayda sağlayabilir. Performans planlamasında yalnızca storage değil, network bandwidth de ölçülmelidir.

Merkezi Access Control

Merkezi access control, hangi kullanıcının hangi repository üzerinde push veya pull yapabileceğini belirlemeyi kolaylaştırır. Geliştirici, operasyon ekibi ve CI/CD servislerinin aynı yetkiye sahip olması doğru değildir. Production repository'lerinde push yetkisi daha dar tutulmalıdır. İnsan kullanıcıları ile robot account kimlikleri birbirinden ayrılmalıdır. Bu yaklaşım olası credential sızıntısının etkisini sınırlar.

Vulnerability Management

Registry ile vulnerability scanner entegrasyonu, image'ların merkezi biçimde analiz edilmesini sağlar. Scan on push özelliği sayesinde yeni image geldiği anda bilinen zafiyetler kontrol edilebilir. Ancak yalnızca severity skoruna bakmak yeterli değildir. Zafiyetin gerçekten çalıştırılan bileşende erişilebilir olup olmadığı ve güncel bir düzeltme bulunup bulunmadığı da değerlendirilmelidir. CI/CD güvenlik kontrolleri için https://www.diyarbakiryazilim.com.tr/posts/ci-cd-ortaminda-otomatik-guvenlik-taramalari-sast-dast adresindeki yaklaşım da güvenlik hattının diğer parçalarıyla birlikte değerlendirilebilir.

Compliance

Denetime tabi kurumlarda kimin hangi artifact üzerinde işlem yaptığı kayıt altına alınmalıdır. Registry audit logları login, push, delete ve policy değişikliklerini izlemek için kullanılabilir. Logların merkezi SIEM sistemine gönderilmesi olay incelemelerini kolaylaştırır. Ayrıca retention, signing ve vulnerability politikaları denetim kanıtı olarak kullanılabilir. Teknik kontrolün yanında yazılı governance politikalarının bulunması da önemlidir.

Air-Gapped Çalışma

İnternet bağlantısı bulunmayan ortamlarda kurum içi registry temel bir dağıtım bileşenine dönüşür. Gerekli base image ve uygulama artifact'ları kontrollü kanallar üzerinden taşınır. Her artifact için digest ve imza doğrulaması yapılması güvenliği artırır. Vulnerability database güncellemeleri çevrimdışı paketlerle yönetilebilir. Böyle bir ortamda dokümante edilmiş transfer prosedürü bulunması gerekir.

Private Registry Kullanmanın Dezavantajları

Private registry yüksek kontrol sağlar ancak bu kontrol ücretsiz bir operasyon avantajı değildir. Sistem güncellemeleri, backup, sertifika yönetimi, monitoring ve kapasite planlaması kurum tarafından yürütülmelidir. Küçük ekiplerde bu sorumluluk bazen gözden kaçabilir. Registry çalıştığı sürece sorun yokmuş gibi görünür ancak disk dolduğunda veya sertifika süresi dolduğunda CI/CD hattı tamamen durabilir. Bu nedenle yatırım kararı yalnızca lisans maliyetine bakılarak verilmemelidir.

Operasyon Maliyeti

Registry sunucusu sürekli bakım gerektiren bir production servisidir. İşletim sistemi yamaları, uygulama güncellemeleri ve güvenlik kontrolleri düzenli yapılmalıdır. Monitoring alarmları takip edilmeli ve olaylara müdahale edecek sorumlu ekip belirlenmelidir. Küçük bir sistem bile zaman içinde ciddi operasyon yükü oluşturabilir. Toplam maliyet değerlendirilirken mühendislik zamanı mutlaka hesaba katılmalıdır.

Storage Yönetimi

Image sayısı arttıkça depolama alanı hızlı biçimde büyüyebilir. Retention politikası olmayan registry'lerde yıllar önce oluşturulmuş build image'ları bile kalmaya devam eder. Layer deduplication alan tasarrufu sağlar ancak sınırsız büyümeyi engellemez. Kapasite alarmı ve büyüme trendi düzenli izlenmelidir. Storage dolmadan önce yeni alan ekleme veya retention çalıştırma planı bulunmalıdır.

Backup Sorumluluğu

Registry yedeği yalnızca blob dosyalarını kopyalamaktan ibaret değildir. Database, configuration, certificate ve kritik metadata bilgileri de yedek kapsamına girebilir. Backup sıklığı hedeflenen RPO değerine göre belirlenmelidir. Ayrıca backup'ın başka bir hata alanında saklanması gerekir. En önemli nokta ise restore işleminin gerçekten test edilmiş olmasıdır.

Güvenlik Güncellemeleri

Registry platformu, scanner, veritabanı ve reverse proxy gibi bileşenler düzenli güncelleme ister. Güncellemelerin gecikmesi bilinen güvenlik açıklarının sistemde kalmasına neden olabilir. Bununla birlikte production ortamına doğrudan güncelleme yapmak da risklidir. Önce staging ortamında uyumluluk testi yapılmalıdır. Upgrade öncesinde geri dönüş planı hazırlanması operasyon güvenliğini artırır.

High Availability

Tek sunucu üzerinde çalışan registry kolay kurulabilir ancak önemli bir tek hata noktası oluşturur. Sunucu veya disk kaybı olduğunda tüm deployment süreçleri etkilenebilir. Kritik sistemlerde uygulama replica'ları, dış veritabanı ve shared storage gibi HA bileşenleri kullanılabilir. Load balancer üzerinden trafik dağıtımı yapılabilir. Gerçek HA için yalnızca uygulama container sayısını artırmak yeterli değildir.

Monitoring

Registry izlenmeden sağlıklı işletilemez. Disk kullanımı, error rate, request latency, scan queue ve replication hataları düzenli takip edilmelidir. Yalnızca servis ayakta mı kontrolü yetersizdir. Push ve pull işlemlerinin başarı oranı da ölçülmelidir. Kapasite ve sertifika süresi gibi göstergeler için erken uyarı alarmı oluşturulmalıdır.

Disaster Recovery

Disaster recovery, registry servisinin büyük bir arıza sonrasında ne kadar sürede geri dönebileceğini belirler. RPO ve RTO hedefleri iş birimleriyle birlikte belirlenmelidir. İkinci lokasyonda storage kopyası veya replication modeli değerlendirilebilir. DNS failover planı dokümante edilmelidir. Kağıt üzerinde yazılmış ancak hiç test edilmemiş DR planı production güvenliği sağlamaz.

Certificate Yönetimi

TLS certificate süresinin dolması registry istemcilerinin bağlantısını tamamen kesebilir. Bu nedenle expiration monitoring yapılmalıdır. Otomatik yenileme kullanılıyorsa istemci trust store davranışı da test edilmelidir. Internal CA rotation sırasında eski ve yeni certificate chain geçişi planlanmalıdır. Sertifika olayları için önceden hazırlanmış runbook bulunması müdahale süresini azaltır.

Kurum İçi Registry İçin Hangi Yazılım Seçilmeli?

Registry yazılımı seçerken yalnızca kurulum kolaylığına bakmak uzun vadede sorun çıkarabilir. Küçük bir ekip için sade bir dağıtım servisi yeterli olabilirken, çok ekipli yapılarda RBAC, SSO, vulnerability scanning, replication ve audit gibi özelliklere ihtiyaç duyulur. Benim sık gördüğüm hata, başlangıçta yalnızca bugünkü ihtiyaçların değerlendirilmesidir. Oysa registry altyapısı ekip büyüdükçe merkezi bir güvenlik bileşenine dönüşür. Bu nedenle seçim kriterleri kullanıcı sayısı, image hacmi, veri merkezi sayısı, güvenlik politikaları ve operasyon ekibinin kapasitesi üzerinden belirlenmelidir.

CNCF Distribution

Dağıtım odaklı sade registry yapısı, temel push ve pull ihtiyacını düşük ek yükle karşılayabilir. Küçük ekiplerde veya özel bir uygulamanın arkasında registry servisi olarak kullanmak mantıklı olabilir. Ancak gelişmiş RBAC, kullanıcı portalı veya yerleşik governance özellikleri beklenmemelidir. Bu işlevler gerektiğinde ek servislerle tamamlanır. Dolayısıyla sade kurulum avantajı zaman içinde ek entegrasyon maliyetine dönüşebilir.

Harbor

Harbor, private container registry kullanımını kurumsal ihtiyaçlara yaklaştıran kapsamlı özellikler sunar. Project yapısı, robot account, vulnerability scanning, replication, retention ve kullanıcı yönetimi bu özellikler arasındadır. Özellikle birden fazla ekip aynı registry sistemini kullanacaksa merkezi yönetim kolaylığı sağlar. Trivy entegrasyonu image tarama süreçlerini daha görünür hale getirir. Production kullanımında yine de external database, storage, backup ve high availability tasarımının ayrıca yapılması gerekir.

Seçim Kriterleri

Seçim yaparken ilk soru kaç kullanıcının sisteme bağlanacağı olmalıdır. İkinci konu authentication ve yetkilendirme modelidir. Üçüncü olarak scanning, signing, replication ve proxy cache ihtiyaçları değerlendirilmelidir. Operasyon ekibinin çözümü güncelleme ve sorun giderme kapasitesi de karar üzerinde doğrudan etkilidir. Son olarak platformun OCI artifact desteği, uzun vadeli kullanım açısından göz önünde bulundurulmalıdır.

RBAC

RBAC, kullanıcıların görevleri kadar yetki almasını sağlayan temel güvenlik mekanizmasıdır. Production repository üzerinde herkesin push yetkisine sahip olması iyi bir uygulama değildir. Project admin, developer ve read-only gibi roller net biçimde ayrılmalıdır. CI/CD servis hesapları yalnızca ihtiyaç duydukları repository ile sınırlandırılmalıdır. Yetkiler düzenli aralıklarla gözden geçirilmelidir.

SSO

SSO, kullanıcı yaşam döngüsünü merkezi kimlik sistemiyle yönetmeyi kolaylaştırır. Yeni çalışanların sisteme eklenmesi ve ayrılan çalışanların erişiminin kaldırılması daha kontrollü hale gelir. MFA desteği varsa yönetici hesapları için özellikle kullanılmalıdır. Local admin hesapları yalnızca acil durum için sınırlandırılabilir. Kimlik sistemi arızasında kullanılacak break-glass hesabı ayrıca güvence altına alınmalıdır.

Vulnerability Scanning

Vulnerability scanning, registry'ye gelen image içindeki bilinen açıkları tespit etmeye yardımcı olur. Scan on push işlemi yeni image'ların hızlıca değerlendirilmesini sağlar. Zafiyet veritabanı sürekli değiştiği için scheduled re-scan de önemlidir. Geçen hafta temiz görünen image bugün yeni yayınlanan bir CVE nedeniyle riskli hale gelebilir. Bu nedenle scanning tek seferlik build adımı olarak görülmemelidir.

Image Signing

Image signing, bir artifact'ın güvenilir bir süreç tarafından üretildiğini doğrulamaya yardımcı olur. İmza kontrolü production deployment öncesinde policy olarak uygulanabilir. Signing key güvenliği ayrı bir sorumluluktur ve düzenli rotation planı gerekir. Keyless signing modelleri bazı ortamlarda operasyonu kolaylaştırabilir. Her durumda doğrulama mekanizması deployment katmanına kadar taşınmalıdır.

Replication

Replication, image içeriklerinin farklı registry noktaları arasında kopyalanmasını sağlar. Çoklu veri merkezinde latency azaltmak veya DR hazırlamak için kullanılabilir. Push-based ve pull-based yöntemler farklı ihtiyaçlara uygundur. Replication gecikmesi monitoring ile takip edilmelidir. Ağ kesintisi sonrasında senkronizasyon davranışı önceden test edilmelidir.

Proxy Cache

Proxy cache, public image'ların bir kez indirilip sonraki isteklerde kurum içinden sunulmasını sağlar. Bu yöntem network çıkışını ve tekrar eden transferleri azaltabilir. Aynı zamanda kullanılan dış image'ların merkezi noktadan kontrol edilmesini kolaylaştırır. Security scanning ile birlikte kullanıldığında dış artifact'lar iç politikaya göre değerlendirilebilir. CI/CD sistemlerinin doğrudan internete çıkması yerine kontrollü cache kullanması daha yönetilebilir bir modeldir.

HA

High availability ihtiyacı registry'nin iş açısından önemine göre belirlenmelidir. Deployment süreçleri registry olmadan çalışamıyorsa tek node mimarisi önemli risk oluşturur. Uygulama replica'ları, redundant load balancer ve dayanıklı storage birlikte tasarlanmalıdır. Veritabanı ve cache servisleri de HA mimarisine dahil edilmelidir. Yalnızca frontend replica sayısını artırmak gerçek HA sağlamaz.

OCI Artifact Desteği

OCI artifact desteği registry'nin yalnızca container image değil, ilgili metadata ve güvenlik artifact'larını da saklamasını mümkün kılar. SBOM, signature ve attestation gibi içerikler image ile ilişkilendirilebilir. Bu yapı software supply chain görünürlüğünü artırır. Gelecekte yeni artifact türleri eklendiğinde sistemin yeniden tasarlanma ihtiyacını azaltabilir. Bu nedenle yeni registry seçimlerinde OCI desteği güçlü bir kriterdir.

Operasyon Maliyeti

Kurulum ücretsiz olsa bile işletim maliyeti sıfır değildir. Monitoring, backup, upgrade ve güvenlik kontrolleri mühendislik zamanı gerektirir. Storage büyümesi ayrıca maliyet yaratır. Çok bileşenli platformlarda database ve cache katmanları da yönetilmelidir. Bu nedenle toplam sahip olma maliyeti yalnızca lisans veya sunucu ücretinden hesaplanmamalıdır.

Docker Registry mi Harbor mı?

Sade registry ile Harbor arasındaki seçim kullanım ölçeğine bağlıdır. Tek bir ekip, sınırlı sayıda image ve basit authentication ihtiyacı varsa temel registry yeterli olabilir. Ekip sayısı arttığında project isolation, RBAC, scanning, retention ve audit gibi özellikler önem kazanmaya başlar. Bu noktada Harbor operasyonel olarak daha düzenli bir yapı sunabilir. Karar verirken üç yıl sonraki kullanıcı sayısını ve güvenlik gereksinimlerini düşünmek daha sağlıklı sonuç verir.

Basit Docker Registry'nin Avantajları

Sade registry mimarisinin en önemli avantajı düşük bileşen sayısıdır. Kurulum, backup ve troubleshooting süreçleri daha anlaşılır olabilir. Küçük laboratuvar veya development ortamlarında hızlı sonuç verir. Kaynak tüketimi de daha düşüktür. Ancak kurumsal kimlik ve governance ihtiyacı arttığında ek entegrasyonlar gerekebilir.

Harbor'ın Kurumsal Özellikleri

Harbor, kullanıcıların project bazlı çalışmasını ve farklı rollerle yetkilendirilmesini destekler. Robot account ile CI/CD kimlikleri insan kullanıcılarından ayrılabilir. Scanner entegrasyonu sayesinde image güvenliği merkezi biçimde izlenebilir. Retention, replication ve audit özellikleri operasyon süreçlerini kolaylaştırır. Bu nedenle çok takımlı ortamlarda yönetim açısından önemli avantaj sağlayabilir.

Hangi Ölçekte Docker Registry Yeterlidir?

Az sayıda geliştirici, birkaç repository ve basit push/pull ihtiyacı bulunan yapılarda temel registry yeterli olabilir. Böyle bir ortamda external authentication veya gelişmiş portal gerekmeyebilir. Yine de TLS ve backup ihmal edilmemelidir. Production dışı laboratuvarlarda sade yapı operasyon maliyetini azaltabilir. Kullanım büyüdüğünde migration seçeneği önceden düşünülmelidir.

Hangi Ölçekte Harbor Tercih Edilmelidir?

Birden fazla ekip, farklı yetki seviyeleri ve ciddi güvenlik gereksinimleri varsa Harbor değerlendirilmelidir. Production ve development project'lerini ayırmak gerektiğinde project yapısı fayda sağlar. Vulnerability scanning ve robot account gibi özellikler CI/CD entegrasyonunu kolaylaştırır. Çoklu veri merkezinde replication ihtiyacı varsa avantajı daha belirgin hale gelir. Ayrıca audit ve retention süreçlerinin merkezi yönetilmesi operasyon ekibinin işini kolaylaştırır.

Docker Registry'den Harbor'a Geçiş

Geçişten önce mevcut repository, tag ve storage yapısı envanterlenmelidir. Image'ların yeni registry'ye kopyalanmasında digest bütünlüğü kontrol edilmelidir. Kullanıcı ve CI/CD credential yapısı yeniden tasarlanmalıdır. DNS geçişi sırasında istemcilerin yeni certificate chain'e güvenmesi sağlanmalıdır. Migration sonrası push, pull, scan ve deployment testleri tamamlanmadan eski sistem kapatılmamalıdır.

Kurum İçi Registry Referans Mimarisi

Production registry mimarisi birçok bileşenin birlikte çalışmasını gerektirir. DNS, load balancer, TLS termination, authentication, registry application, database ve storage katmanları birbirinden bağımsız düşünülmemelidir. Vulnerability scanner, monitoring ve backup servisleri de mimarinin doğal parçasıdır. Küçük sistemlerde bu bileşenlerin bazıları tek node üzerinde bulunabilir ancak kritik ortamlarda hata alanları ayrılmalıdır. Kurumsal private Docker Registry kurulum ve DevOps hizmeti planlanırken referans mimari doğrudan iş sürekliliği hedeflerine göre tasarlanmalıdır.

DNS

Registry için sabit ve anlamlı bir FQDN kullanılmalıdır. İstemcilerin IP adresi üzerinden registry kullanması uzun vadede yönetimi zorlaştırır. DNS kaydı load balancer veya reverse proxy katmanına yönlendirilmelidir. Disaster recovery senaryosunda DNS değişiminin nasıl yapılacağı önceden planlanmalıdır. TTL değeri failover beklentisine göre seçilmelidir.

Firewall

Registry yalnızca gerekli network segmentlerinden erişilebilir olmalıdır. Developer, CI/CD ve Kubernetes ağları için izinler açık biçimde tanımlanmalıdır. Yönetim arayüzü mümkünse ayrı management network üzerinden erişilebilir olmalıdır. Gereksiz internet erişimi kapatılmalıdır. Firewall logları olay analizi için merkezi sisteme aktarılabilir.

Load Balancer

HA registry yapısında load balancer trafiği birden fazla uygulama replica'sına dağıtır. Health check yalnızca TCP port kontrolüne indirgenmemelidir. Uygulamanın gerçekten istek yanıtlayabildiği endpoint tercih edilmelidir. TLS termination load balancer üzerinde yapılacaksa certificate lifecycle burada yönetilir. Uzun süren layer upload bağlantıları için timeout değerleri ayrıca ayarlanmalıdır.

Reverse Proxy

Reverse proxy, TLS termination ve HTTP header yönetimi açısından önemli rol oynar. Büyük image upload işlemlerinde body size limitleri doğru yapılandırılmalıdır. Default timeout değerleri büyük layer transferleri için kısa kalabilir. Forwarded header bilgileri uygulamanın doğru external URL üretmesi için gereklidir. Proxy logları 401, 413 ve timeout sorunlarını analiz ederken değerli bilgi sağlar.

Registry Application

Registry application image push ve pull işlemlerinin merkezidir. Uygulama stateless tasarlanabiliyorsa yatay ölçekleme daha kolay olur. Persistent verinin ayrı storage katmanında tutulması gerekir. Health check ve readiness kontrolleri production deployment için önemlidir. Upgrade sırasında rolling veya kontrollü downtime modeli kullanılabilir.

Authentication Service

Authentication servisi kullanıcı veya makine kimliklerini doğrular. Basic auth küçük sistemlerde yeterli olabilir ancak kurumsal ortamlarda OIDC veya LDAP entegrasyonu daha sürdürülebilirdir. CI/CD için robot account kullanılması önerilir. Token süresi ve credential rotation politikaları tanımlanmalıdır. Authentication olayları audit log içinde tutulmalıdır.

Database

Harbor gibi platformlarda database project, kullanıcı, policy ve metadata bilgilerini saklar. Production ortamında database backup ayrı planlanmalıdır. Connection pool değerleri yüksek yük altında performansı etkileyebilir. HA gereksinimi varsa dış database servisi veya cluster mimarisi değerlendirilebilir. Restore testinde blob storage ile metadata tutarlılığı kontrol edilmelidir.

Redis

Redis job ve cache işlemlerinde kullanılan önemli bir altyapı bileşeni olabilir. Tek Redis instance'ı kritik ortamlarda hata noktası oluşturabilir. External Redis kullanımı HA tasarımını kolaylaştırabilir. Memory kapasitesi ve eviction davranışı izlenmelidir. Redis arızasının hangi registry fonksiyonlarını etkilediği test edilmelidir.

Blob Storage

Blob storage image layer içeriklerinin ana depolama alanıdır. Storage seçimi performans ve dayanıklılık üzerinde doğrudan etkilidir. Local filesystem küçük sistemlerde kolaydır ancak HA için sınırlı olabilir. S3-compatible object storage daha esnek bir seçenek sunabilir. Storage lifecycle ve backup stratejisi birlikte planlanmalıdır.

Vulnerability Scanner

Vulnerability scanner image içindeki işletim sistemi paketlerini ve uygulama bağımlılıklarını analiz eder. Scan sonucu deployment kararına doğrudan bağlanabilir. Scanner database güncellemeleri düzenli yapılmalıdır. Scan queue yoğunluğu monitoring üzerinden takip edilmelidir. Air-gapped ortamda offline database güncelleme prosedürü hazırlanmalıdır.

Monitoring

Monitoring katmanı registry'nin hem teknik hem de operasyonel sağlığını ölçmelidir. Availability, push success rate, pull latency ve storage büyümesi önemli göstergelerdir. Kritik eşikler için alarm üretilmelidir. Alarm sayısının çok fazla olması ekibin gerçek sorunları fark etmesini zorlaştırabilir. Bu nedenle ölçümler SLI ve SLO hedeflerine bağlanmalıdır.

Backup

Backup, blob storage dışında database, configuration, certificates ve kritik secrets verilerini de kapsamalıdır. Backup verisinin aynı sunucuda saklanması gerçek koruma sağlamaz. Off-site veya ayrı hata alanında kopya tutulmalıdır. Restore prosedürü yazılı runbook halinde bulunmalıdır. Düzenli restore drill ile yedeklerin gerçekten kullanılabilir olduğu doğrulanmalıdır.

Registry İçin Domain ve DNS Tasarımı

Registry domain tasarımı genellikle küçük bir ayrıntı gibi görünür ancak sertifika, client configuration ve disaster recovery süreçlerini doğrudan etkiler. Başlangıçta kullanılan geçici hostname daha sonra yüzlerce istemcide sabit hale gelebilir. Bu nedenle registry için kalıcı bir FQDN belirlenmelidir. Development ve production sistemlerinin aynı hostname altında karıştırılması güvenlik açısından iyi değildir. DNS ve certificate tasarımı ilk kurulumdan önce netleştirilmelidir.

Registry FQDN Belirlemek

FQDN kısa, açık ve kurumsal naming standardına uygun olmalıdır. Uygulama ekipleri hostname'i Dockerfile veya CI/CD variable içinde kullanabilir. Bu nedenle ileride değiştirilmesi operasyon maliyeti doğurur. FQDN certificate SAN alanında bulunmalıdır. Aynı isim üzerinden load balancer veya DR hedefi değiştirilebilir.

Internal DNS Kullanımı

Registry yalnızca kurum içinden kullanılacaksa internal DNS mantıklı bir seçenektir. Böylece servis public DNS üzerinde yayınlanmadan erişilebilir. VPN kullanıcıları da internal DNS çözümlemesine dahil edilebilir. DNS zone yedekliliği önemlidir çünkü isim çözümlenemediğinde registry erişimi tamamen durur. Monitoring yalnızca registry servisini değil DNS çözümlemesini de kontrol etmelidir.

Split DNS

Split DNS aynı domain adının iç ve dış ağlarda farklı IP adreslerine çözülmesini sağlar. Bu yöntem hibrit erişim senaryolarında yararlı olabilir. Ancak yanlış yapılandırıldığında kullanıcıların beklenmeyen endpoint'e gitmesine neden olabilir. TLS certificate her iki senaryoda da aynı hostname ile uyumlu olmalıdır. Disaster recovery testlerinde hem internal hem external resolution doğrulanmalıdır.

Development ve Production Registry'lerini Ayırmak

Development ve production registry'lerinin ayrılması yetki ve risk yönetimini kolaylaştırır. Development ortamında daha sık push yapılırken production daha kontrollü bir promotion süreci kullanabilir. Ayrı FQDN veya project yapıları tercih edilebilir. Production push yetkisi yalnızca belirli CI/CD kimlikleriyle sınırlandırılmalıdır. Böylece geliştiricinin yanlışlıkla production artifact değiştirme riski azalır.

Certificate SAN Gereksinimleri

Certificate SAN alanında registry istemcilerinin kullandığı gerçek hostname bulunmalıdır. IP üzerinden erişim gerekiyorsa bu ayrıca certificate tasarımında düşünülmelidir. Wildcard certificate bazı yapılarda kolaylık sağlar ancak güvenlik politikasıyla uyumlu olmalıdır. Internal CA kullanılıyorsa client trust store dağıtımı otomatikleştirilmelidir. Certificate renewal sonrasında SAN değerleri tekrar kontrol edilmelidir.

Docker Registry Kurulumu İçin Ön Gereksinimler

Kuruluma başlamadan önce CPU, RAM, disk, DNS, TLS ve firewall gereksinimleri belirlenmelidir. Küçük bir test sistemi ile production sistemi aynı kaynak planına sahip olmamalıdır. Image build sayısı, ortalama image boyutu ve retention süresi kapasite hesaplamasında kullanılmalıdır. TLS certificate ve DNS kaydı sonradan düşünülmemelidir. Ön gereksinimler hazır olduğunda kurulum daha hızlı ve geri dönüşü daha kolay olur.

CPU ve RAM

CPU ve RAM ihtiyacı yalnızca kullanıcı sayısına bağlı değildir. Eş zamanlı push ve pull işlemleri, vulnerability scanning ve job servisleri kaynak tüketimini artırır. Scanner aynı node üzerinde çalışıyorsa ek RAM gerekebilir. Monitoring ile gerçek kullanım ölçülmeli ve kapasite buna göre güncellenmelidir. HA ortamında her replica'nın minimum yükü tek başına karşılayabilecek kapasitede olması tercih edilebilir.

Disk Kapasitesi

Disk kapasitesi günlük build sayısı ve retention politikasına göre hesaplanmalıdır. Ortalama image boyutunu doğrudan build sayısıyla çarpmak kaba bir tahmin sağlar ancak layer deduplication bu değeri düşürebilir. Backup alanı ayrıca hesaplanmalıdır. En az yüzde yirmi veya daha fazla headroom bırakmak büyüme için faydalıdır. Disk doluluk alarmı kritik seviyeye ulaşmadan önce uyarı üretmelidir.

Linux İşletim Sistemi

Production registry için güncel ve desteklenen bir Linux dağıtımı kullanılmalıdır. Güvenlik yamaları düzenli uygulanmalıdır. Gereksiz servisler kapatılarak saldırı yüzeyi azaltılabilir. Sistem logları merkezi log altyapısına gönderilebilir. Kernel ve filesystem seçimi storage performansını etkileyebileceği için yük testleriyle değerlendirilmelidir.

Docker Engine

Container tabanlı kurulum yapılacaksa desteklenen container runtime sürümü kullanılmalıdır. Eski runtime sürümleri TLS veya registry API uyumluluğu açısından sorun çıkarabilir. Daemon configuration dikkatli yönetilmelidir. Insecure registry ayarının production ortamında geçici çözüm olarak bile yaygınlaştırılmaması gerekir. Runtime upgrade işlemleri staging ortamında test edilmelidir.

Docker Compose

Tek node veya küçük deployment senaryolarında Compose kurulum kolaylığı sağlar. Servis bağımlılıklarını ve volume tanımlarını tek dosyada yönetmek pratiktir. Ancak production HA ihtiyacı arttığında orchestrator tabanlı mimari daha uygun olabilir. Compose dosyası source control altında tutulmalıdır. Secret değerleri doğrudan dosya içine yazılmamalıdır.

DNS

Registry hostname'i kurulumdan önce çözülür durumda olmalıdır. Client makineler ve Kubernetes node'ları aynı hostname'i doğru IP adresine çevirebilmelidir. Internal DNS kullanılıyorsa VPN kullanıcıları da test edilmelidir. DNS TTL değeri planlanan failover modeline uygun seçilmelidir. x509 hatalarının önemli bir bölümü yanlış hostname veya DNS tasarımından kaynaklanır.

TLS Certificate

Production registry için TLS temel gereksinimdir. Certificate chain eksiksiz olmalıdır. Internal CA kullanılıyorsa tüm Docker ve container runtime istemcilerine root certificate dağıtılmalıdır. Certificate expiration monitoring kurulmalıdır. Renewal işlemi otomatik olsa bile client trust davranışı düzenli test edilmelidir.

Firewall

Firewall yalnızca gerekli port ve kaynak network'lere izin vermelidir. Yönetim arayüzü ile registry data trafiği mümkünse farklı erişim politikalarına tabi tutulmalıdır. CI/CD runner'larının registry'ye erişimi açıkça tanımlanmalıdır. Public internet erişimi gerekmiyorsa kapatılmalıdır. Firewall değişiklikleri audit kayıtlarına dahil edilmelidir.

Docker Compose ile Private Registry Kurulumu

Docker Compose ile private registry kurulumu eğitim, test veya kontrollü tek node production senaryolarında hızlı bir başlangıç sağlar. Ancak kurulumun amacı yalnızca container'ı çalıştırmak olmamalıdır. Persistent volume, TLS, authentication ve health check ayarları en baştan eklenmelidir. Restart policy sayesinde host yeniden başladığında servis otomatik dönebilir. Gerçek kullanım öncesinde push, pull, restart ve disk doluluk senaryoları test edilmelidir.

Registry Container'ını Çalıştırmak

Registry container'ı resmi image üzerinden başlatılabilir ve gerekli configuration volume olarak bağlanabilir. Port doğrudan internete açılmamalıdır. Reverse proxy arkasında çalıştırmak TLS ve erişim yönetimini kolaylaştırabilir. Container resource limitleri yoğun ortamlarda dikkate alınmalıdır. Log çıktısı merkezi toplama sistemine yönlendirilebilir.

Persistent Volume Oluşturmak

Registry verisinin container filesystem içinde tutulması doğru değildir. Container yeniden oluşturulduğunda image verisi kaybolabilir. Bu nedenle persistent volume kullanılmalıdır. Production sistemlerinde volume backup politikası ayrıca tanımlanmalıdır. Local volume kullanılıyorsa host disk arızasının etkisi değerlendirilmelidir.

Registry Configuration Dosyası

Configuration dosyası storage, authentication, HTTP ve logging ayarlarını tanımlar. Bu dosyanın source control altında tutulması değişiklik takibini kolaylaştırır. Secret bilgiler ayrı yöntemlerle yönetilmelidir. Configuration değişiklikleri staging ortamında test edilmelidir. Upgrade sırasında deprecated ayarlar için release note kontrolü yapılmalıdır.

Restart Policy

Restart policy host veya container arızası sonrasında servisin otomatik başlamasını sağlar. Ancak sürekli crash olan container'ın tekrar tekrar başlatılması temel problemi çözmez. Monitoring bu durumu fark edip alarm üretmelidir. Startup dependency bulunan yapılarda servis sırası kontrol edilmelidir. Restart sonrasında health endpoint doğrulaması yapılması faydalıdır.

Health Check

Health check servis portunun açık olmasından daha fazlasını kontrol etmelidir. Registry API endpoint'ine başarılı yanıt alınması daha anlamlıdır. Authentication kullanılan sistemlerde uygun endpoint seçilmelidir. Load balancer aynı health check sonucunu kullanabilir. Yanlış health check tasarımı çalışan node'un trafik dışına çıkmasına veya arızalı node'un trafikte kalmasına neden olabilir.

İlk Registry Testi

İlk testte docker login, tag, push ve pull işlemleri yapılmalıdır. Farklı bir istemciden pull testi gerçekleştirerek local cache etkisi ortadan kaldırılmalıdır. TLS certificate chain doğrulanmalıdır. Registry restart sonrasında image'ın hala erişilebilir olduğu kontrol edilmelidir. Son olarak yanlış credential ile erişim denemesi yapılarak authorization davranışı test edilmelidir.

Persistent Storage Nasıl Tasarlanmalı?

Registry storage tasarımı yalnızca kapasite seçimi değildir. Latency, throughput, durability, backup ve HA birlikte değerlendirilmelidir. Küçük ortamlarda local filesystem yeterli olabilir ancak büyüyen sistemlerde object storage daha esnek hale gelebilir. Storage performansı özellikle eş zamanlı pull trafiğinde doğrudan kullanıcı deneyimini etkiler. Şirket içi container registry image scanning backup ve storage yönetimi planlanırken storage tek başına değil retention ve disaster recovery politikalarıyla birlikte ele alınmalıdır.

Local Filesystem

Local filesystem kolay kurulum ve düşük latency avantajı sağlar. Tek node sistemlerde operasyonu oldukça basittir. Ancak host kaybı storage erişimini tamamen durdurabilir. Backup başka bir sisteme alınmalıdır. HA ihtiyacı ortaya çıktığında local disk sınırlayıcı hale gelir.

Block Storage

Block storage yüksek IOPS ve tahmin edilebilir performans sağlayabilir. Sanallaştırılmış altyapılarda volume farklı host'a bağlanabilir. Ancak aynı volume'un eş zamanlı olarak birden fazla node tarafından kullanılması her storage çözümünde desteklenmez. Filesystem bütünlüğü önemli bir konudur. Backup snapshot yaklaşımı database tutarlılığıyla birlikte değerlendirilmelidir.

NFS

NFS merkezi filesystem sağlar ve birden fazla node için ortak storage olarak kullanılabilir. Kurulumu görece basit görünse de yüksek eş zamanlı yük altında performans sınırlamaları yaşanabilir. NFS sunucusu kendi başına hata noktası olmamalıdır. Network latency doğrudan registry performansına yansır. Production öncesinde gerçek image push ve pull yüküyle test yapılmalıdır.

S3-Compatible Object Storage

S3-compatible object storage büyük ölçekli registry kullanımı için güçlü bir seçenektir. Uygulama node'larından bağımsız çalışması HA tasarımını kolaylaştırabilir. Durability ve lifecycle seçenekleri storage operasyonunu destekler. Ancak object storage latency değerleri image pull performansını etkileyebilir. Bağlantı sayısı ve throughput testleri gerçek workload üzerinden yapılmalıdır.

Cloud Object Storage

Cloud tabanlı object storage yönetim yükünü azaltabilir ancak veri konumu ve maliyet politikaları değerlendirilmelidir. Egress maliyeti bazı mimarilerde önemli hale gelebilir. Registry uygulaması ile storage aynı network bölgesinde tutulduğunda latency azalabilir. Backup veya versioning özellikleri ek koruma sağlayabilir. Yine de yanlış silme senaryosu için immutable backup yaklaşımı ayrıca düşünülmelidir.

Production İçin Storage Seçim Kriterleri

Production storage seçiminde tek bir kriter yeterli değildir. Latency düşük olsa bile durability zayıfsa veri riski oluşur. Çok dayanıklı storage çözümü ise yetersiz throughput nedeniyle deployment sürelerini uzatabilir. Backup ve restore süreleri RPO ve RTO hedefleriyle uyumlu olmalıdır. Maliyet hesabında yalnızca kullanılan GB değil, request ve network maliyetleri de düşünülmelidir.

Latency

Registry pull işlemleri çok sayıda küçük ve büyük object isteği üretebilir. Storage latency yükseldiğinde image başlatma süreleri uzar. Kubernetes node scale-out sırasında bu etki daha görünür hale gelir. P95 latency metriği ortalama değerden daha anlamlı olabilir. Coğrafi replication bazı bölgelerde latency azaltmak için kullanılabilir.

Throughput

Throughput, eş zamanlı image transferleri için kritik bir metriktir. Tek bir büyük push hızlı olabilirken onlarca eş zamanlı pull sırasında darboğaz oluşabilir. Network ve storage throughput birlikte değerlendirilmelidir. Load test gerçek image boyutlarıyla yapılmalıdır. Monitoring zaman içinde değişen yoğunluğu gösterebilir.

Durability

Durability, storage içindeki blob verisinin uzun vadede korunma seviyesini ifade eder. Registry image'ları yeniden build edilebilir görünse bile production artifact'ların kaybı operasyon riski yaratır. Storage redundancy tek başına backup yerine geçmez. İnsan hatası veya kötü niyetli silme durumunda bağımsız kopya gerekir. Bu nedenle durability ve backup iki ayrı katman olarak düşünülmelidir.

Backup

Storage backup stratejisi retention ve disaster recovery hedefleriyle uyumlu olmalıdır. Incremental yaklaşım büyük veri hacimlerinde avantaj sağlayabilir. Backup kopyaları farklı hata alanında tutulmalıdır. Immutable backup ransomware veya yetkisiz silmeye karşı ek koruma sağlayabilir. Restore testinin belirli aralıklarla yapılması zorunlu bir operasyon pratiği olmalıdır.

HA

Storage HA olmadan registry uygulama replica'larının yüksek erişilebilir olması yeterli değildir. Shared storage tek noktadan arızaya açık olmamalıdır. Object storage veya clustered filesystem seçenekleri değerlendirilebilir. Failover sırasında veri tutarlılığı test edilmelidir. Storage servisinin SLO hedefi registry'nin genel SLO hedefiyle uyumlu olmalıdır.

Maliyet

Storage maliyeti yalnızca ham kapasite üzerinden hesaplanmamalıdır. Backup kopyaları, replication ve object request ücretleri toplam maliyeti artırabilir. Retention politikasının olmaması maliyeti her ay büyütür. Gereksiz development build'leri otomatik temizlenmelidir. Production artifact'lar ise daha uzun süre korunabilir.

Docker Registry TLS/HTTPS Yapılandırması

Docker Registry SSL authentication ve role based access control yapılandırması konuşulurken TLS ilk güvenlik katmanıdır. Registry credential ve image metadata bilgilerinin açık ağ üzerinden taşınması kabul edilmemelidir. TLS sayesinde istemci sunucunun kimliğini doğrular ve trafik şifrelenir. Internal CA kullanılması mümkündür ancak CA certificate bütün istemcilere doğru dağıtılmalıdır. Production sistemlerinde insecure registry ayarı kalıcı çözüm olarak kullanılmamalıdır.

Registry'de HTTPS Neden Zorunludur?

Registry login sırasında credential veya token bilgileri kullanılır. HTTP kullanıldığında bu trafik ağ üzerinde korunmasız hale gelebilir. Ayrıca image bütünlüğü ve endpoint kimliği konusunda güven kaybı oluşur. HTTPS, istemcinin doğru registry ile konuştuğunu doğrulamaya yardımcı olur. Bu nedenle production ortamlarında TLS temel güvenlik kontrolü olarak kabul edilmelidir.

Public CA Certificate

Public CA certificate istemciler tarafından doğal olarak güvenilir kabul edildiği için operasyonu kolaylaştırır. Ancak internal hostname veya özel network yapılarında kullanımı her zaman mümkün olmayabilir. Certificate renewal otomasyonu tercih edilmelidir. Private key erişimi sınırlandırılmalıdır. Renewal sonrası service reload işlemi otomatik olarak test edilmelidir.

Internal Corporate CA

Internal CA kurumun kendi certificate lifecycle politikasını uygulamasına imkan verir. Registry hostname'i için şirket içi certificate üretilebilir. Root ve intermediate CA certificate'ların Docker istemcilerine dağıtılması gerekir. Kubernetes node'ları ve CI/CD runner'ları bu trust chain'e dahil edilmelidir. CA rotation işlemi planlı biçimde yapılmalıdır.

Self-Signed Certificate

Self-signed certificate test ortamlarında kullanılabilir ancak production yönetimini zorlaştırır. Her istemcinin certificate'e ayrı olarak güvenmesi gerekir. Certificate yenilendiğinde tüm trust store'ların tekrar güncellenmesi gerekebilir. Bu nedenle kurumsal internal CA genellikle daha düzenli bir çözüm sunar. Insecure registry kullanmak yerine doğru trust chain oluşturulmalıdır.

Certificate Chain

Certificate chain eksik olduğunda istemci sunucu certificate'ini doğrulayamayabilir. Reverse proxy üzerinde server certificate ile intermediate certificate'lar doğru sırada sunulmalıdır. Browser üzerinde çalışan bağlantının başarılı olması Docker istemcisinin de mutlaka başarılı olacağı anlamına gelmez. CLI üzerinden TLS testi yapılmalıdır. Chain değişiklikleri rollout öncesinde staging ortamında doğrulanmalıdır.

Certificate Renewal

Certificate expiration production kesintilerinin önlenebilir nedenlerinden biridir. Expiration tarihi monitoring sistemine metric veya alarm olarak eklenmelidir. Otomatik renewal kullanılıyorsa renewal sonrası proxy reload işlemi kontrol edilmelidir. Internal CA certificate süresi de ayrıca takip edilmelidir. En az birkaç hafta önceden uyarı oluşturmak müdahale için zaman sağlar.

Docker Client'a CA Certificate Tanıtmak

Internal CA kullanan registry için istemci trust store doğru yapılandırılmalıdır. Docker daemon belirli registry hostname'i için CA certificate dosyasını bekleyebilir. Containerd kullanılan Kubernetes node'larında farklı trust configuration gerekebilir. Bu dağıtım configuration management sistemiyle otomatikleştirilebilir. CA rotation sırasında eski ve yeni CA'nın geçiş döneminde birlikte tanınması kesinti riskini azaltır.

Reverse Proxy ile Registry Yayınlamak

Reverse proxy registry trafiğini merkezi biçimde yönetmek için kullanışlıdır. TLS termination, access log ve request limitleri bu katmanda uygulanabilir. Ancak container image upload işlemleri klasik web isteklerinden daha uzun sürebilir. Varsayılan body size ve timeout değerleri büyük layer transferlerini engelleyebilir. Production öncesinde birkaç GB boyutunda gerçek upload testi yapmak faydalıdır.

NGINX

NGINX reverse proxy olarak TLS termination ve header yönetimi için kullanılabilir. Büyük upload işlemlerinde client body limitleri doğru ayarlanmalıdır. Proxy buffering davranışı registry workload'una göre değerlendirilmelidir. Timeout değerleri uzun push işlemlerini desteklemelidir. Access ve error logları troubleshooting sırasında önemli veri sağlar.

Traefik

Traefik dinamik container ortamlarında route ve TLS yönetimini kolaylaştırabilir. Otomatik certificate yönetimi bazı senaryolarda operasyon yükünü azaltır. Ancak registry için request timeout ve upload davranışı ayrıca kontrol edilmelidir. Production yapılandırması version control altında tutulmalıdır. Yönetim dashboard'u internet erişimine açılmamalıdır.

HAProxy

HAProxy yüksek bağlantı sayısı bulunan ortamlarda güçlü bir load balancing katmanı sunabilir. Health check ve backend dağıtımı ayrıntılı biçimde yapılandırılabilir. TLS termination veya passthrough modelleri değerlendirilebilir. Uzun süreli transferler için timeout değerleri ayrıca ayarlanmalıdır. HAProxy logları backend hata oranlarını analiz etmeyi kolaylaştırır.

TLS Termination

TLS termination reverse proxy üzerinde yapılırsa certificate yönetimi merkezi hale gelir. Backend trafiğinin de TLS ile şifrelenip şifrelenmeyeceği network güvenlik modeline göre belirlenmelidir. Zero Trust yaklaşımında iç network trafiği de güvenilir varsayılmamalıdır. Certificate private key yalnızca gerekli servis hesabı tarafından okunabilmelidir. Rotation prosedürü kesinti oluşturmadan test edilmelidir.

Forwarded Headers

Reverse proxy arkasındaki registry gerçek istemci ve protokol bilgisini forwarded header üzerinden alabilir. Yanlış header yapılandırması redirect veya authentication sorunlarına neden olabilir. Uygulamanın external URL ayarı proxy hostname'i ile eşleşmelidir. Güvenilmeyen istemcilerin forwarded header değerlerini manipüle etmesine izin verilmemelidir. Proxy yalnızca kendi oluşturduğu güvenilir header bilgilerini backend'e iletmelidir.

Large Image Layer Upload

Büyük layer upload işlemleri reverse proxy limitlerini hızlı biçimde ortaya çıkarır. Küçük test image'larıyla yapılan doğrulama production sorunlarını göstermeyebilir. Multi-GB image ile test yapılmalıdır. Upload sırasında network kesintisi senaryosu da değerlendirilmelidir. Mümkün olduğunda image boyutu Dockerfile optimizasyonuyla azaltılmalıdır.

client_max_body_size

Body size limiti büyük image layer'larının yüklenmesini engelleyebilir. Limit çok düşük olduğunda istemci 413 hatası alır. Registry için uygun veya sınırsız değer kullanılabilir. Ancak genel reverse proxy üzerindeki diğer uygulamalar için aynı ayarın uygulanması gerekmeyebilir. Registry route'una özel configuration tercih edilmelidir.

Proxy Timeout

Proxy timeout değerleri uzun süren layer transferleri için yeterli olmalıdır. Düşük bandwidth bağlantılarda upload süresi beklenenden fazla olabilir. Timeout artırmadan önce network performansı da kontrol edilmelidir. Sonsuz timeout kullanmak sorunları gizleyebilir. Ölçülen transfer sürelerine göre makul sınırlar belirlenmelidir.

Upload Timeout

Upload timeout özellikle büyük image ve uzak lokasyon senaryolarında önemlidir. Zayıf bağlantı nedeniyle upload yarıda kesilebilir. Retry davranışı CI/CD pipeline içinde kontrol edilmelidir. Network partition durumunda pipeline'ın belirsiz süreyle beklemesi engellenmelidir. Timeout değerleri operasyon ekibinin kabul ettiği deployment süresiyle uyumlu olmalıdır.

Docker Registry Authentication

Registry authentication kullanıcı veya servis kimliğinin doğrulanmasını sağlar. Anonymous erişim yalnızca gerçekten public olması gereken repository'ler için düşünülmelidir. Production ortamında push işlemi mutlaka kimlik doğrulamalı olmalıdır. İnsan kullanıcıları ve CI/CD kimlikleri farklı credential politikalarına tabi tutulmalıdır. Merkezi kimlik sistemiyle entegrasyon kullanıcı yaşam döngüsünü kolaylaştırır.

Anonymous Registry

Anonymous registry herkesin kimlik doğrulama olmadan belirli işlemleri yapmasına izin verebilir. Public pull ihtiyacı olan bazı ortamlarda kullanılabilir. Ancak anonymous push production sistemlerinde ciddi risk oluşturur. Public project açılması gerekiyorsa yalnızca read-only erişim tercih edilmelidir. Audit ihtiyacı varsa anonymous kullanım ayrıca değerlendirilmelidir.

Basic Auth

Basic auth küçük kurulumlarda basit bir authentication yöntemi sunar. TLS olmadan kullanılmamalıdır. Kullanıcı sayısı arttığında credential yaşam döngüsü zorlaşır. Password rotation ve kullanıcı silme işlemleri manuel yük oluşturabilir. Bu nedenle büyük yapılarda merkezi identity sistemi tercih edilir.

htpasswd

htpasswd dosyası basic auth için kullanıcı bilgilerini saklayabilir. Küçük ekiplerde hızlı kurulum avantajı sağlar. Dosya izinleri sınırlandırılmalıdır. Kullanıcı sayısı arttıkça merkezi yönetim zayıf kalır. Production büyüme planında daha gelişmiş authentication modeline geçiş düşünülmelidir.

Bearer Token Authentication

Bearer token modeli istemcinin kimlik doğrulama servisinden kısa ömürlü token almasını sağlar. Registry bu token içindeki scope bilgisini değerlendirerek erişim kararı verebilir. Bu yaklaşım merkezi authorization sistemleriyle entegrasyonu kolaylaştırır. Token süresi sınırlı tutulmalıdır. Token içeriği loglara yazılmamalıdır.

External Authentication

External authentication kurumsal identity sistemlerinin registry ile kullanılmasını sağlar. Kullanıcılar ayrı registry parolası tutmak zorunda kalmaz. Hesap kapatıldığında registry erişimi de merkezi olarak sona erdirilebilir. Grup bilgileri role mapping için kullanılabilir. Identity service kesintisi için break-glass erişim planı hazırlanmalıdır.

SSO Entegrasyonu

SSO kullanıcı deneyimini ve merkezi güvenlik yönetimini iyileştirir. MFA politikaları identity provider üzerinden uygulanabilir. Registry local kullanıcı sayısı azaltılabilir. Yönetici erişimleri ayrı grup veya role bağlanmalıdır. SSO yapılandırması düzenli olarak test edilmelidir.

mTLS ile Registry Güvenliği

mTLS, sunucunun istemciyi certificate üzerinden doğrulamasını sağlayarak network seviyesinde güçlü bir makine kimliği kontrolü oluşturur. Bu yöntem özellikle CI/CD runner, Kubernetes node veya yüksek güvenlikli segmentler arasında kullanılabilir. Kullanıcı authentication mekanizmasının yerine geçmek zorunda değildir. İki katman birlikte kullanıldığında hem cihaz hem kullanıcı kimliği doğrulanabilir. Certificate issuance ve revocation süreçleri otomatikleştirilmezse operasyon yükü artabilir.

Mutual TLS Nedir?

Standart TLS bağlantısında istemci sunucu certificate'ini doğrular. mTLS yapısında sunucu da istemciden certificate ister. Böylece yalnızca geçerli client certificate sahibi sistemler bağlantı kurabilir. Network erişimi ele geçirilse bile certificate olmadan registry'ye bağlanmak zorlaşır. Bu model machine identity güvenliğinde güçlü bir kontrol sunar.

Internal Certificate Authority

mTLS için internal CA çoğu kurumda merkezi certificate yönetimi sağlar. Client certificate'lar belirli servis veya cihaz kimliklerine verilebilir. Certificate policy içinde kullanım süresi sınırlandırılmalıdır. CA private key yüksek güvenlik altında tutulmalıdır. Revocation mekanizması olay müdahalesinin önemli parçasıdır.

Client Certificate

Client certificate her makine veya servis için ayrı üretilmelidir. Aynı certificate'ın onlarca sunucuda paylaşılması izlenebilirliği azaltır. Private key dosyası yalnızca ilgili servis tarafından okunabilmelidir. Expiration süresi monitoring ile takip edilmelidir. Credential rotation otomatik yapılabiliyorsa operasyon daha güvenli hale gelir.

Machine Identity

Machine identity CI/CD runner veya Kubernetes node gibi sistemlerin kimliğini kullanıcı hesabından bağımsız biçimde tanımlar. Bu model servislerin insan parolası kullanmasını önler. Certificate veya kısa ömürlü token kullanılabilir. Her servis yalnızca ihtiyacı olan scope'a erişmelidir. Audit loglarda makine kimliği açık biçimde görülebilmelidir.

Certificate Revocation

Bir client private key sızdığında ilgili certificate hızla geçersiz kılınmalıdır. Certificate revocation mekanizması önceden test edilmelidir. Sadece yeni certificate üretmek eski anahtarın riskini ortadan kaldırmaz. Registry veya proxy revocation bilgisini dikkate almalıdır. Olay sonrasında audit log kontrolü yapılmalıdır.

mTLS + User Authentication Birlikte Kullanımı

mTLS cihazın güvenilir olduğunu doğrularken kullanıcı authentication erişim yapan kişinin kimliğini belirler. İki mekanizmanın birlikte kullanılması yüksek güvenlikli ortamlarda güçlü bir katmanlı kontrol sağlar. Örneğin yalnızca kurumsal cihazdan gelen ve SSO ile giriş yapan kullanıcıların erişimine izin verilebilir. CI/CD servisleri ise machine certificate ve robot account kullanabilir. Bu tasarım biraz daha fazla operasyon gerektirir ancak saldırı yüzeyini azaltır.

Harbor Kurulumu

Harbor kurulumu production odaklı yapılacaksa installer çalıştırmadan önce domain, TLS, storage ve database mimarisi hazırlanmalıdır. Online veya offline installer seçimi network politikasına bağlıdır. harbor.yml dosyası external URL, storage ve authentication gibi kritik ayarları içerir. Trivy scanner etkinleştirilecekse CPU ve RAM kapasitesi ayrıca hesaplanmalıdır. İlk kurulumdan sonra default administrator parolası değiştirilmelidir.

Harbor Sistem Gereksinimleri

Sistem gereksinimleri kullanıcı ve image hacmine göre değişir. Scanner, job service ve registry aynı node üzerinde çalışıyorsa kaynak ihtiyacı artar. Disk kapasitesi retention süresiyle birlikte hesaplanmalıdır. Production ortamında minimum kaynak değerlerinin üzerinde headroom bırakılmalıdır. Monitoring sayesinde gerçek yük takip edilerek kapasite zaman içinde güncellenebilir.

Online Installer

Online installer gerekli container image'larını kurulum sırasında indirebilir. İnternet erişimi bulunan ortamlarda kurulum daha kolaydır. Ancak production network politikası dış erişimi sınırlandırıyorsa bu yöntem uygun olmayabilir. İndirilen bileşenlerin sürümleri kaydedilmelidir. Upgrade sırasında aynı süreç staging ortamında denenmelidir.

Offline Installer

Offline installer internet erişimi olmayan veya kontrollü ortamlar için uygundur. Gerekli container image'ları installer paketiyle birlikte taşınabilir. Artifact paketi iç ortama alınmadan önce checksum ve imza kontrolleri yapılmalıdır. Scanner database'i ayrıca güncellenmelidir. Air-gap süreçleri dokümante edilmelidir.

harbor.yml

harbor.yml temel platform configuration dosyasıdır. Hostname, certificate, storage ve database seçenekleri bu dosyada tanımlanabilir. Secret değerlerin erişimi sınırlandırılmalıdır. Dosya version control altında tutulabilir ancak hassas bilgiler repository'ye yazılmamalıdır. Upgrade öncesinde configuration backup alınmalıdır.

TLS Yapılandırması

Harbor TLS certificate ve key dosyaları güvenli dizinde saklanmalıdır. Hostname certificate SAN ile eşleşmelidir. Internal CA kullanılıyorsa tüm istemcilere trust dağıtılmalıdır. Reverse proxy kullanılıyorsa termination noktası açık biçimde belirlenmelidir. Certificate renewal süreci otomatik veya dokümante edilmiş şekilde yönetilmelidir.

Storage Yapılandırması

Storage backend deployment ölçeğine göre seçilmelidir. Local filesystem küçük ortamlar için yeterli olabilir. HA ortamında shared veya object storage daha uygun olabilir. Backup ve lifecycle politikaları baştan tanımlanmalıdır. Storage credential bilgileri secret yönetim sistemiyle korunmalıdır.

Trivy Scanner

Trivy image içindeki bilinen zafiyetleri taramak için kullanılabilir. Scan on push etkinleştirildiğinde yeni image'lar otomatik olarak analiz edilir. Scanner database güncellemeleri düzenli takip edilmelidir. Scan süresi büyük image'larda uzun olabilir. Queue yoğunluğu monitoring ile izlenmelidir.

Harbor Servislerini Başlatmak

Servisler başlatıldıktan sonra yalnızca web arayüzünün açılması yeterli doğrulama değildir. Registry endpoint, database bağlantısı ve scanner durumu kontrol edilmelidir. Loglarda tekrar eden hata bulunmamalıdır. İlk push ve pull testi farklı bir istemciden yapılmalıdır. Restart sonrasında tüm servislerin otomatik döndüğü doğrulanmalıdır.

İlk Login

İlk login sonrasında administrator parolası hemen değiştirilmelidir. Default credential production ortamında bırakılmamalıdır. SSO veya LDAP kullanılacaksa yapılandırma bu aşamada tamamlanabilir. Local admin yalnızca acil durum hesabı olarak tutulabilir. Audit logların login olaylarını kaydettiği doğrulanmalıdır.

Harbor Mimarisi Nasıl Çalışır?

Harbor tek bir registry container'ından daha geniş bir platform yapısına sahiptir. Portal, core servisleri, job service, database, Redis, scanner ve storage birlikte çalışır. Bu nedenle herhangi bir bileşenin arızası farklı fonksiyonları etkileyebilir. Production monitoring tüm bu servisleri kapsamalıdır. HA tasarımında stateful ve stateless bileşenler birbirinden ayrılarak değerlendirilmelidir.

Harbor Portal

Portal kullanıcıların project, repository ve security sonuçlarını görüntülediği web arayüzüdür. Portal erişimi yönetim network üzerinden sınırlandırılabilir. SSO entegrasyonu kullanıcı girişini kolaylaştırır. Portal kullanılamasa bile registry data path davranışı ayrıca değerlendirilmelidir. Health monitoring UI ile API durumunu ayrı ayrı takip edebilir.

Harbor Core

Core servis kullanıcı, project ve policy mantığının önemli bölümünü yönetir. Registry ve diğer bileşenler arasında koordinasyon sağlar. Çoklu replica kullanıldığında session ve shared state davranışı dikkate alınmalıdır. Logları authorization hatalarını analiz ederken yararlıdır. Core servisin yüksek erişilebilirliği portal ve API fonksiyonları için önemlidir.

Registry

Registry servisi image manifest ve blob transferinin merkezidir. Storage backend ile doğrudan çalışır. Yüksek pull trafiğinde bu katmanın performansı kritik hale gelir. Stateless çalışabildiği ölçüde yatay ölçekleme yapılabilir. Storage bağlantı hataları doğrudan push ve pull başarısını etkiler.

Registry Controller

Registry controller, registry ile Harbor yönetim özellikleri arasındaki bazı koordinasyon görevlerini yürütür. Configuration tutarlılığı önemlidir. Servis erişim izinleri sınırlandırılmalıdır. Loglar registry API ile Harbor core arasındaki problemleri analiz etmeye yardımcı olur. Upgrade sırasında controller uyumluluğu kontrol edilmelidir.

Job Service

Job service replication, scan ve benzeri arka plan görevlerini işleyebilir. Yoğun registry'lerde queue büyüklüğü önemli bir metriktir. Biriken işler operasyon gecikmesine neden olabilir. Multiple replica kullanımı throughput artırabilir. Ancak aynı işin tekrar çalıştırılması gibi idempotency davranışları test edilmelidir.

PostgreSQL

PostgreSQL platform metadata bilgilerinin önemli bölümünü saklar. Database backup registry DR planının temel parçalarından biridir. External HA database production sistemlerinde değerlendirilebilir. Connection limitleri ve performans metrikleri takip edilmelidir. Restore sırasında blob storage ile metadata uyumu kontrol edilmelidir.

Redis

Redis cache ve job koordinasyonu için kullanılabilir. External Redis yüksek erişilebilirlik planını güçlendirebilir. Memory ve bağlantı sayısı izlenmelidir. Redis kesintisinin hangi işlevleri durdurduğu test edilmelidir. Backup gereksinimi kullanılan veri tipine göre değerlendirilmelidir.

Trivy

Trivy image security scanning görevlerini yürütür. CVE database güncelliği scan sonuçlarının doğruluğu açısından önemlidir. Air-gapped ortamda database güncelleme paketleri kontrollü biçimde taşınmalıdır. Çok fazla eş zamanlı scan CPU tüketimini artırabilir. Queue ve completion time değerleri SLO olarak izlenebilir.

Storage

Harbor storage katmanı image blob verisinin kalıcı olarak saklandığı alandır. Object storage HA için güçlü bir seçenek olabilir. Disk kapasitesi retention ve growth rate ile birlikte takip edilmelidir. Backup kopyalarının application backup ile uyumlu olması gerekir. Storage permission değişiklikleri registry servisinin erişimini kesebilir.

Harbor Project Yapısı

Harbor project yapısı ekipleri, uygulamaları veya ortamları mantıksal olarak ayırmak için kullanılabilir. Her project farklı üyeler, quota ve retention politikalarına sahip olabilir. Kurumsal isimlendirme standardı baştan tanımlanmalıdır. Production ve development artifact'larını aynı alanda tutmak erişim kontrolünü zorlaştırabilir. Project tasarımı RBAC ve lifecycle politikalarının temelini oluşturur.

Public Project

Public project içindeki artifact'lar authentication olmadan çekilebilir. Bu özellik yalnızca gerçekten public olması gereken içerikler için kullanılmalıdır. Production uygulama image'larının public yapılması genellikle uygun değildir. Public project oluşturma yetkisi sınırlandırılmalıdır. Audit sürecinde public erişimli project'ler düzenli kontrol edilmelidir.

Private Project

Private project erişim için authentication gerektirir. Kullanıcı ve robot account izinleri project scope üzerinden yönetilebilir. Hassas application image'ları için varsayılan yaklaşım private project olmalıdır. Production push yetkisi daha dar tutulabilir. Pull erişimi ise deployment servisleriyle sınırlandırılabilir.

Project Naming Standard

İsimlendirme standardı ekiplerin repository yapısını tahmin edilebilir hale getirir. Departman, takım, uygulama ve environment bilgisi belirli kurala göre kullanılabilir. Çok uzun veya rastgele isimler automation script'lerini zorlaştırır. Naming policy dokümante edilmelidir. Yeni project oluşturma süreci bu standardı otomatik kontrol edebilir.

Project Quota

Quota belirli project'in sınırsız storage tüketmesini engeller. Development ekipleri için daha düşük limitler uygulanabilir. Production project'leri retention politikasına göre farklı quota alabilir. Quota dolmadan önce alarm gönderilmelidir. Limit yalnızca ceza mekanizması değil kapasite planlama aracı olarak görülmelidir.

Project Member

Project member kullanıcının ilgili project içinde hangi role sahip olduğunu belirler. İnsan kullanıcı ve servis account rolleri birbirinden ayrılmalıdır. Gereksiz geniş yetkiler düzenli olarak temizlenmelidir. Grup tabanlı membership yönetimi büyük ekiplerde daha kolaydır. İşten ayrılan kullanıcıların erişimi merkezi kimlik sistemi üzerinden sona erdirilmelidir.

Project Policy

Project policy retention, immutability ve vulnerability gibi kuralları kapsayabilir. Production project için daha sıkı kontroller uygulanabilir. Development ortamında hızlı iterasyon için daha esnek retention kullanılabilir. Policy değişiklikleri audit kaydına alınmalıdır. Kritik değişikliklerde approval süreci uygulanabilir.

Kurumsal Registry Namespace Stratejisi

Namespace yapısı doğru kurulmadığında repository sayısı arttıkça yönetim zorlaşır. Departman, takım, uygulama veya environment bazlı yaklaşımlar kullanılabilir. Tek bir model her kurum için doğru değildir. En önemli nokta namespace ile RBAC modelinin uyumlu olmasıdır. CI/CD pipeline ve Kubernetes manifest isimleri de bu standarda göre tasarlanmalıdır.

Departman Bazlı Namespace

Departman bazlı yapı büyük organizasyonlarda temel ayrım sağlayabilir. Her departmanın project admin sorumluları bulunabilir. Ancak ortak uygulamalar birden fazla departman tarafından kullanılıyorsa sahiplik karmaşası oluşabilir. Shared project yapısı ayrıca tanımlanmalıdır. Departman değişiklikleri namespace migration ihtiyacı doğurabilir.

Takım Bazlı Namespace

Takım bazlı namespace DevOps ownership modeliyle uyumlu olabilir. Takım kendi repository ve retention politikasını yönetebilir. Production push yetkisi yine merkezi politika ile sınırlandırılmalıdır. Takım isimleri değiştiğinde repository rename etkisi düşünülmelidir. Namespace yapısı organizasyon şemasına aşırı bağımlı olmamalıdır.

Uygulama Bazlı Namespace

Uygulama bazlı namespace artifact sahipliğini netleştirebilir. Backend, frontend ve worker image'ları aynı application project altında tutulabilir. Role ve quota uygulama seviyesinde yönetilebilir. Birden fazla takım aynı uygulamaya katkı sağlıyorsa erişim daha kolay planlanır. Production promotion aynı uygulama namespace içinde ayrı repository veya project ile yapılabilir.

Environment Bazlı Namespace

Environment bazlı yapı development, test, staging ve production artifact'larını ayırır. Bu yaklaşım promotion sürecini görünür hale getirir. Production push yalnızca CI/CD tarafından yapılabilir. Kullanıcıların yanlış environment'a image göndermesi authorization ile engellenebilir. Retention süreleri environment'a göre farklı uygulanabilir.

Development

Development ortamında build sayısı yüksek olduğu için kısa retention mantıklı olabilir. Geliştiricilere daha geniş push yetkisi verilebilir. Vulnerability scan yine aktif tutulmalıdır. latest tag kullanımı yalnızca geçici development senaryolarında kabul edilebilir. Production promotion sırasında immutable artifact yaklaşımına geçilmelidir.

Test

Test environment doğrulanacak image'ların belirli süre tutulduğu alandır. CI pipeline test sonrası image'ı buraya promote edebilir. QA ekibine pull erişimi verilebilir. Başarısız test image'ları kısa sürede temizlenebilir. Digest bilgisi test sonucu ile ilişkilendirilmelidir.

Staging

Staging production'a en yakın artifact ve configuration modelini kullanmalıdır. Buraya gelen image production'a rebuild edilmeden promote edilmelidir. Böylece test edilen artifact ile production artifact aynı digest değerini taşır. Security gate bu aşamada yeniden uygulanabilir. Approval mekanizması production geçişinden önce kullanılabilir.

Production

Production project en sıkı yetki ve immutability politikasına sahip olmalıdır. İnsan kullanıcıların doğrudan push yetkisi olmaması iyi bir yaklaşımdır. Image yalnızca onaylı CI/CD promotion süreciyle gelmelidir. Tag değiştirilemez hale getirilebilir. Deployment manifestlerinde digest kullanılması artifact bütünlüğünü güçlendirir.

Tenant Bazlı Namespace

Multi-tenant platformlarda her tenant için ayrı namespace kullanılabilir. Böylece quota ve erişim sınırları tenant seviyesinde uygulanabilir. Ortak base image'lar shared project içinde tutulabilir. Tenant silme süreci retention ve legal ihtiyaçlarla uyumlu olmalıdır. Cross-tenant erişim varsayılan olarak kapalı tutulmalıdır.

Registry RBAC Nasıl Tasarlanmalı?

RBAC tasarımı least privilege prensibi üzerinden yapılmalıdır. Administrator rolü günlük geliştirme işlerinde kullanılmamalıdır. Project admin yalnızca sorumlu olduğu project üzerinde yönetim yapmalıdır. Developer ve read-only roller kullanım amacına göre ayrılmalıdır. Production push yetkisinin yalnızca güvenilir otomasyon kimliklerine verilmesi güçlü bir güvenlik kontrolüdür.

Administrator

Administrator tüm registry üzerinde geniş yetkiye sahiptir. Bu nedenle hesap sayısı minimum tutulmalıdır. MFA zorunlu hale getirilmelidir. Günlük push veya pull işlemlerinde admin hesabı kullanılmamalıdır. Admin aktiviteleri ayrı audit alarmı ile izlenebilir.

Project Admin

Project admin yalnızca belirli project yönetiminden sorumlu olmalıdır. Kullanıcı ekleme, quota ve bazı policy değişiklikleri bu role verilebilir. Global platform ayarlarına erişmemelidir. Role atamaları merkezi süreçle onaylanabilir. Düzenli access review yapılmalıdır.

Developer

Developer development repository'lerinde push ve pull yetkisine sahip olabilir. Production project için yalnızca pull veya hiç erişim verilmeyebilir. Delete yetkisi ayrıca değerlendirilmelidir. Geliştirici hesabı CI/CD içinde kullanılmamalıdır. Kullanıcı ayrıldığında erişim merkezi identity sistemi üzerinden kaldırılmalıdır.

Maintainer

Maintainer repository yönetimi için developer'dan daha geniş yetki alabilir. Retention veya artifact delete gibi işlemler bu role bağlanabilir. Production ortamında maintainer sayısı sınırlı tutulmalıdır. Her işlem audit log içinde izlenmelidir. Role tanımı kurumun governance politikasında açıkça yazılmalıdır.

Guest / Read-Only

Read-only kullanıcı image çekebilir ancak değiştiremez. Güvenlik, denetim veya operasyon ekipleri için uygun olabilir. Gereksiz push yetkisi verilmemesi saldırı yüzeyini azaltır. Production deployment servisleri çoğu durumda yalnızca pull yetkisine ihtiyaç duyar. Robot account scope'u da aynı prensiple sınırlandırılabilir.

Least Privilege

Least privilege her kullanıcı veya servise yalnızca ihtiyacı olan minimum yetkinin verilmesini ifade eder. Admin credential'ın pipeline içinde kullanılması bu prensibe aykırıdır. Yetkiler repository veya project scope ile sınırlandırılmalıdır. Geçici işler için süreli erişim tercih edilebilir. Access review periyodik olarak yapılmalıdır.

Production Push Yetkisini Sınırlandırmak

Production push yetkisi doğrudan geliştirici hesaplarına verilmemelidir. Onaylı CI/CD pipeline artifact promotion işlemini yapmalıdır. Robot account yalnızca production repository push scope'una sahip olabilir. Credential rotation düzenli yapılmalıdır. Her production push olayı audit ve webhook üzerinden kayıt altına alınabilir.

LDAP ve Active Directory Entegrasyonu

Kurumsal directory entegrasyonu kullanıcı yaşam döngüsünü merkezi hale getirir. Kullanıcı işe başladığında grup üyeliği üzerinden registry erişimi alabilir. İşten ayrıldığında merkezi hesabın kapatılması registry erişimini de sona erdirir. Role mapping grup bazında yapıldığında manuel kullanıcı yönetimi azalır. Directory bağlantısı TLS üzerinden korunmalıdır.

LDAP Authentication

LDAP authentication registry'nin kullanıcı doğrulamasını merkezi dizine yönlendirmesini sağlar. Bind hesabı yalnızca gerekli okuma izinlerine sahip olmalıdır. LDAP trafiği TLS ile şifrelenmelidir. Base DN ve filter ayarları gereksiz kullanıcı kapsamını daraltabilir. Bağlantı kesintisi senaryosu önceden test edilmelidir.

Active Directory Groups

Directory grupları project role atamasını kolaylaştırır. Örneğin belirli uygulama ekibi için ayrı grup oluşturulabilir. Kullanıcı hareketleri merkezi grup yönetimi üzerinden yapılabilir. Grup isimleri registry naming standardıyla uyumlu olmalıdır. Nested group davranışı kullanılan platformda test edilmelidir.

Group-to-Role Mapping

Group-to-role mapping manuel kullanıcı yetkilendirmesini azaltır. Security ekibi grup üyeliğini merkezi olarak yönetebilir. Production admin grupları özel onay sürecine tabi tutulabilir. Yanlış grup eşlemesi geniş yetki vermemelidir. Mapping değişiklikleri audit kaydına alınmalıdır.

Centralized User Lifecycle

Merkezi kullanıcı yaşam döngüsü hesap açma ve kapatma işlemlerini düzenler. Registry için ayrı kullanıcı veritabanı tutulmasına gerek kalmaz. İşten ayrılma süreci daha hızlı uygulanır. Password policy ve MFA merkezi sistemden yönetilebilir. Access review raporları grup üyelikleri üzerinden üretilebilir.

İşten Ayrılan Kullanıcının Yetkisini Otomatik Kaldırmak

İşten ayrılan kullanıcının erişiminin açık kalması önemli bir güvenlik riskidir. Merkezi identity entegrasyonu bu riski azaltır. Kullanıcı hesabı devre dışı bırakıldığında registry login otomatik olarak başarısız olmalıdır. Mevcut token'ların süresi de kısa tutulmalıdır. Kritik ayrılıklarda aktif session ve token iptali ayrıca yapılabilir.

OIDC ve SSO

OIDC tabanlı SSO modern kimlik sistemleriyle registry entegrasyonunu kolaylaştırır. Kullanıcılar merkezi hesapla giriş yapabilir ve ayrı registry parolası tutmaz. MFA politikaları tek noktadan uygulanabilir. Group claim bilgileri RBAC ile eşleştirilebilir. Ancak identity provider kesintisinde admin erişimi için güvenli bir break-glass mekanizması gereklidir.

OIDC Nedir?

OIDC kimlik doğrulama için token tabanlı standart bir protokoldür. Registry kullanıcı kimliğini merkezi identity provider üzerinden doğrulayabilir. Access ve ID token süreleri kontrollü tutulmalıdır. Redirect URL doğru TLS hostname ile yapılandırılmalıdır. Token bilgileri application loglarına yazılmamalıdır.

Kurumsal Identity Provider

Kurumsal identity provider kullanıcı, grup ve MFA politikalarını merkezi biçimde yönetir. Registry bu yapıya bağlandığında ayrı kullanıcı yönetimi ihtiyacı azalır. Role mapping grup claim'leri üzerinden yapılabilir. Admin erişimleri farklı security group ile sınırlandırılabilir. Identity provider logları registry audit loglarıyla birlikte olay incelemesinde kullanılabilir.

SSO

SSO kullanıcıların tek kurumsal oturumla registry'ye erişmesini sağlar. Kullanıcı deneyimini iyileştirirken password sprawl riskini azaltır. Session timeout güvenlik politikasına göre belirlenmelidir. Shared cihazlarda otomatik login davranışı dikkatli yönetilmelidir. Logout işleminin merkezi oturumu nasıl etkilediği test edilmelidir.

MFA

MFA özellikle administrator ve project admin hesapları için güçlü bir güvenlik katmanıdır. Parola sızsa bile ikinci faktör olmadan login zorlaşır. CI/CD servis hesaplarında MFA yerine machine identity kullanılmalıdır. MFA bypass istisnaları minimum tutulmalıdır. Kritik hesaplarda phishing-resistant yöntemler tercih edilebilir.

Local Admin Hesabını Sınırlamak

Local admin hesabı günlük operasyon için kullanılmamalıdır. SSO arızası durumunda acil erişim için saklanabilir. Parolası güçlü ve ayrı bir secret vault içinde korunmalıdır. Her kullanım alarm üretmelidir. Düzenli olarak login testi yapılarak hesabın gerçekten çalıştığı doğrulanmalıdır.

Break-Glass Account

Break-glass account normal authentication sistemi kullanılamadığında acil yönetim erişimi sağlar. Credential yüksek güvenlikli bir secret yönetim alanında tutulmalıdır. Kullanımı iki kişilik onay gerektirebilir. Her kullanım sonrası parola değiştirilmelidir. Hesabın varlığı düzenli denetimlerde kontrol edilmelidir.

Robot Account ve Service Account Yönetimi

CI/CD sistemlerinin insan kullanıcı hesabıyla registry'ye bağlanması uzun vadede ciddi erişim sorunları doğurur. Çalışan ayrıldığında pipeline bozulabilir veya kişisel credential gereğinden fazla yetkiye sahip olabilir. Robot account belirli project ve işlem scope'uyla sınırlandırılabilir. Credential expiration ve rotation otomatikleştirilebilir. Bu yaklaşım audit loglarda otomasyon ile insan aktivitelerinin ayrılmasını da kolaylaştırır.

Robot Account Nedir?

Robot account insan kullanıcı yerine uygulama veya otomasyon tarafından kullanılan kimliktir. CI/CD pipeline, deployment sistemi veya replication görevi bu hesabı kullanabilir. Yetkisi belirli project veya repository ile sınırlandırılmalıdır. Login parolası secret manager içinde saklanmalıdır. Expiration süresi düzenli rotation için kullanılabilir.

CI/CD'de İnsan Kullanıcı Hesabı Neden Kullanılmamalı?

İnsan hesabı kişinin görev değişikliği veya işten ayrılmasıyla kapanabilir. Pipeline buna bağlıysa production süreci beklenmedik biçimde durur. Ayrıca insan hesabı çoğu zaman pipeline'ın ihtiyacından daha fazla yetkiye sahiptir. Audit loglarda kimin manuel, hangi işlemin otomatik olduğu karışabilir. Robot account bu sorunları önemli ölçüde azaltır.

Push-Only Account

Push-only account yalnızca belirli repository'ye image gönderme amacıyla kullanılabilir. CI build pipeline için uygun olabilir. Delete veya admin yetkisi verilmemelidir. Production push hesabı yalnızca promotion job tarafından kullanılabilir. Credential scope ne kadar dar olursa sızıntı etkisi o kadar sınırlı kalır.

Pull-Only Account

Pull-only account deployment sistemleri için ideal bir modeldir. Kubernetes node veya ServiceAccount yalnızca image çekme yetkisine ihtiyaç duyar. Push ve delete izinleri gereksizdir. Her cluster için ayrı credential kullanılması audit görünürlüğünü artırabilir. Credential sızarsa saldırganın registry içeriğini değiştirmesi engellenmiş olur.

Project Scope

Robot account mümkün olduğunca project kapsamıyla sınırlandırılmalıdır. Global robot account yalnızca gerçekten gerekli durumlarda kullanılmalıdır. Bir pipeline başka project'e erişmek zorunda değilse izin verilmemelidir. Scope düzenli olarak gözden geçirilmelidir. Yeni repository açıldığında otomatik olarak geniş yetki verilmesinden kaçınılmalıdır.

Credential Expiration

Credential expiration unutulmuş servis hesaplarının süresiz aktif kalmasını önler. Ancak süre dolmadan önce rotation otomasyonu çalışmalıdır. Expiration tarihi monitoring ile takip edilmelidir. Kritik pipeline credential'ı süresi dolduğu için deployment durmamalıdır. Rotation sonrası eski credential kısa sürede iptal edilmelidir.

Credential Rotation

Credential rotation belirli aralıklarla yeni secret üretip eski secret'ı devre dışı bırakma işlemidir. Otomatik yapılması insan hatasını azaltır. Pipeline secret store yeni değerle güncellenmelidir. Geçiş sırasında iki credential'ın kısa süre birlikte geçerli olması gerekebilir. Rotation işlemi audit kaydına alınmalıdır.

Docker Image İsimlendirme ve Tag Stratejisi

Image naming ve tag standardı görünüşte basit bir konu olsa da deployment güvenliğini doğrudan etkiler. Semantic version, Git commit SHA ve build number birlikte kullanılabilir. Environment tag tek başına artifact kimliği olarak görülmemelidir. latest etiketi özellikle production sistemlerinde belirsizlik oluşturur. Immutable tag politikası sürüm izlenebilirliğini önemli ölçüde artırır.

Semantic Version

Semantic version insanlar için anlaşılır release bilgisi sağlar. Major, minor ve patch yapısı değişiklik seviyesini gösterir. Ancak aynı semantic version tag'inin yeniden yazılmasına izin verilmemelidir. Build metadata gerekirse ek tag ile tutulabilir. Production deployment yine digest üzerinden yapılabilir.

Git Commit SHA

Git commit SHA image'ın hangi kaynak kod revizyonundan üretildiğini gösterir. CI pipeline her build'de commit SHA tag'i ekleyebilir. Bu yöntem olay incelemesinde ilgili source revision'a hızlı erişim sağlar. Rebuild yapıldığında aynı commit farklı bağımlılıklar nedeniyle farklı digest üretebilir. Bu nedenle commit SHA ve digest birlikte kaydedilmelidir.

Build Number

Build number CI sistemindeki belirli çalışmayı tanımlar. Hangi pipeline run'ın image ürettiğini görmek kolaylaşır. Build logları image metadata ile ilişkilendirilebilir. Tek başına build number farklı repository'lerde benzersiz olmayabilir. Project veya application ismiyle birlikte kullanılmalıdır.

Environment Tag

Environment tag bir image'ın hangi aşamada olduğunu göstermek için kullanılabilir. dev, test veya prod gibi tag'ler bu amaçla tercih edilebilir. Ancak tag değiştirilebilir olduğu için immutable artifact kimliği olarak kullanılmamalıdır. Promotion işlemi sırasında digest korunmalıdır. Environment bilgisi deployment metadata içinde ayrıca tutulabilir.

latest Tag Problemi

latest etiketi hangi image sürümünün çalıştığını anlamayı zorlaştırır. Tag yeni build tarafından üzerine yazılabilir. Kubernetes node cache davranışı da beklenmeyen sonuçlar üretebilir. Production rollback işlemi hangi previous image'ın kullanıldığını belirlemeyi zorlaştırabilir. Bu nedenle version veya digest kullanımı daha güvenlidir.

Immutable Tag

Immutable tag bir kez oluşturulduktan sonra başka image'a taşınamaz. Bu özellik release artifact'larının değişmesini engeller. Production repository'lerinde immutability policy güçlü bir güvenlik kontrolüdür. Yanlış image push edilirse yeni bir sürüm oluşturulmalıdır. Böylece audit geçmişi korunur.

Image Digest Nedir ve Neden Önemlidir?

Digest bir image içeriğinin değişmez kimliğini temsil eder. Tag kullanıcı dostudur ancak değiştirilebilir. Digest aynı image içeriğini kesin olarak seçmeye yardımcı olur. Production deployment sırasında digest kullanmak supply chain güvenliğini artırır. Özellikle Kubernetes manifest'lerinde digest referansı kullanıldığında yanlış tag yönlendirmesi riski azalır.

Tag ile Digest Arasındaki Fark

Tag mantıksal ve değiştirilebilir bir isimdir. Digest ise içeriğe bağlı kriptografik değerdir. Aynı tag zaman içinde farklı digest değerlerini gösterebilir. Bu nedenle audit sırasında yalnızca tag kaydı yeterli değildir. Deployment loglarında digest saklanmalıdır.

SHA-256 Digest

SHA-256 digest image manifest içeriğinden hesaplanan hash değeridir. İçerikte küçük bir değişiklik yapıldığında digest tamamen değişir. Bu özellik artifact bütünlüğünü doğrulamaya yardımcı olur. Registry pull sırasında digest doğrulaması yapabilir. Security tooling de digest üzerinden image ilişkilerini takip edebilir.

Immutable Deployment

Immutable deployment aynı artifact'ın testten production'a değişmeden taşınmasını ifade eder. Her environment için yeniden build yapmak farklı dependency veya base image nedeniyle farklı sonuç üretebilir. Promotion modelinde aynı digest korunur. Böylece test edilen artifact ile production'da çalışan artifact aynı olur. Bu yaklaşım release güvenini artırır.

Supply Chain Güvenliği

Supply chain güvenliği artifact'ın kaynağını ve değiştirilmediğini doğrulamayı amaçlar. Digest, signing ve provenance birlikte kullanıldığında güçlü bir kontrol zinciri oluşur. CI pipeline ürettiği image digest'ini kayıt altına almalıdır. Deployment platformu güvenilir digest ve signature kontrolü yapabilir. Registry bu zincirin merkezi artifact katmanı olur.

Kubernetes Manifest'lerinde Digest Kullanmak

Kubernetes manifest içinde image@sha256 biçimi kullanılabilir. Böylece workload belirli bir image içeriğini çeker. Tag değişse bile deployment etkilenmez. GitOps süreçlerinde digest güncellemesi kontrollü pull request üzerinden yapılabilir. Rollback sırasında eski digest değerine dönmek kolaylaşır.

Docker Image Push/Pull Akışı

Push ve pull akışını anlamak troubleshooting için oldukça faydalıdır. İstemci önce registry endpoint ile iletişim kurar ve gerekirse authentication challenge alır. Ardından manifest ve layer bilgileri karşılaştırılır. Mevcut layer'lar tekrar yüklenmeyebilir. Bu süreç content-addressable storage sayesinde daha verimli hale gelir.

docker login

docker login registry için credential bilgisini istemciye tanıtır. Production otomasyonunda parola komut satırında açık olarak verilmemelidir. password-stdin yaklaşımı daha güvenlidir. Credential dosyasının izinleri kontrol edilmelidir. CI ortamında secret loglara yazılmamalıdır.

docker tag

docker tag local image'a registry hostname ve repository adı ekler. Yanlış hostname kullanımı image'ın yanlış registry'ye gönderilmesine neden olabilir. Naming standard pipeline içinde otomatik uygulanmalıdır. Semantic version ve commit SHA birlikte kullanılabilir. Tag sonrası digest değişmez çünkü içerik aynı kalır.

docker push

docker push image manifest ve gerekli layer'ları registry'ye gönderir. Registry daha önce var olan layer'ları tekrar istemeyebilir. Büyük layer upload sırasında network timeout görülebilir. Push sonrası returned digest kaydedilmelidir. Vulnerability scan veya signing adımı bu işlemle entegre edilebilir.

docker pull

docker pull registry'den manifest ve gerekli layer içeriklerini indirir. İstemcide mevcut layer'lar tekrar indirilmez. Pull latency storage ve network performansına bağlıdır. Kubernetes scale-out sırasında çok sayıda eş zamanlı pull oluşabilir. Proxy cache ve regional replication bu yükü azaltabilir.

Manifest Transfer

Manifest image'ın layer ve metadata yapısını tanımlar. İstemci önce manifest bilgisini alarak hangi blob'lara ihtiyaç duyduğunu belirler. Multi-platform image'larda manifest listesi kullanılabilir. Manifest silme lifecycle yönetiminde önemli bir adımdır. Yanlış manifest işlemi artifact erişimini etkileyebilir.

Layer Deduplication

Layer deduplication ortak layer içeriklerinin bir kez saklanmasını sağlar. Aynı base image kullanan yüzlerce application ciddi storage tasarrufu elde edebilir. Ancak gereksiz Dockerfile değişiklikleri cache kullanımını bozabilir. Base image standardizasyonu deduplication verimliliğini artırır. Storage kapasite planında gerçek dedup oranı ölçülmelidir.

Content-Addressable Storage

Content-addressable storage veriyi dosya adına değil içerik hash değerine göre tanımlar. Aynı içerik aynı digest ile eşleşir. Bu yapı integrity kontrolünü ve deduplication işlemini kolaylaştırır. Registry layer verisini bu mantıkla yönetebilir. Garbage collection sırasında artık referans edilmeyen blob'lar tespit edilir.

Registry API Nasıl Çalışır?

Registry API otomasyon ve troubleshooting için önemli bir arayüzdür. /v2/ endpoint temel erişim ve authentication davranışını test etmek için kullanılabilir. Repository, tag ve manifest bilgileri API üzerinden sorgulanabilir. Silme işlemleri platform policy ile uyumlu biçimde yapılmalıdır. API token veya credential bilgileri güvenli saklanmalıdır.

/v2/

/v2/ endpoint registry API'nin temel kontrol noktasıdır. Başarılı bağlantı veya authentication challenge registry servisinin erişilebilir olduğunu gösterir. TLS problemi varsa istek bu aşamaya ulaşmadan başarısız olabilir. Reverse proxy route kontrolü için de kullanışlıdır. Troubleshooting akışında DNS ve TLS sonrasında ilk kontrol noktalarından biridir.

Repository Catalog

Repository catalog API bazı registry yapılarında mevcut repository listesini döndürebilir. Ancak büyük registry'lerde pagination dikkate alınmalıdır. Catalog erişimi güvenlik nedeniyle sınırlandırılabilir. Inventory otomasyonu için yararlıdır. Retention ve governance raporları repository listesi üzerinden üretilebilir.

Tag Listeleme

Tag listeleme belirli repository içindeki mevcut sürümleri görmeye yardımcı olur. Automation retention adaylarını bu bilgiyle belirleyebilir. Ancak yalnızca tag listesi digest ilişkisini göstermeyebilir. Manifest sorgusu ile digest bilgisi tamamlanmalıdır. Production cleanup işlemleri dry-run ile doğrulanmalıdır.

Manifest Sorgulama

Manifest sorgusu image'ın layer ve platform bilgilerini verir. Accept header doğru media type için önemlidir. Digest header üzerinden gerçek manifest digest alınabilir. Security tooling manifest verisini analiz edebilir. Silme işlemi yapılacaksa doğru digest belirlenmelidir.

Digest Alma

Digest image bütünlüğü ve promotion işlemlerinde merkezi kimlik olarak kullanılabilir. API response header veya manifest bilgisi üzerinden alınabilir. CI pipeline push sonrası digest değerini artifact metadata olarak saklamalıdır. Deployment manifesti bu digest ile güncellenebilir. Audit kaydında tag ve digest birlikte tutulmalıdır.

Manifest Silme

Manifest silme logical deletion sürecinin parçasıdır. Blob verisi diskte hemen silinmeyebilir. Garbage collection daha sonra referanssız blob'ları temizler. Production repository'lerinde silme yetkisi minimum sayıda kullanıcıya verilmelidir. Cleanup otomasyonu dry-run ve koruma kuralları içermelidir.

API Authentication

API authentication kullanıcı veya robot account credential üzerinden yapılabilir. Token scope yalnızca gerekli endpoint erişimine izin vermelidir. Script içinde sabit parola tutulmamalıdır. Secret manager veya kısa ömürlü token tercih edilmelidir. API çağrıları audit log içinde izlenebilir.

Image Lifecycle Management

Image lifecycle build ile başlar ancak production deployment ile bitmez. Scan, sign, push, promote, deploy ve retire aşamaları birlikte yönetilmelidir. Her adım policy ve audit bilgisi üretebilir. Retention politikasına göre eski image'lar kontrollü biçimde silinir. Yaşam döngüsü otomasyonu registry'nin sınırsız büyümesini engeller.

Build

Build aşamasında reproducible ve minimal image üretmek hedeflenmelidir. Base image sürümü pin edilmelidir. Build secret bilgileri final image içinde kalmamalıdır. Commit SHA ve build number metadata olarak eklenebilir. Build sonucunda digest kayıt altına alınmalıdır.

Scan

Scan aşamasında OS package ve application dependency zafiyetleri analiz edilir. Kritik bulgular pipeline policy ile değerlendirilebilir. False positive durumları kayıtlı exception süreciyle yönetilmelidir. Scan sonucu artifact digest ile ilişkilendirilmelidir. Zafiyet database güncellendiğinde re-scan yapılmalıdır.

Sign

Sign adımı güvenilir pipeline tarafından üretilen image'ın doğrulanmasını sağlar. Signing key erişimi pipeline ile sınırlandırılmalıdır. Signature registry içinde OCI artifact olarak saklanabilir. Deployment öncesi verification yapılmalıdır. Key compromise senaryosu için revocation planı bulunmalıdır.

Push

Push yalnızca güvenlik kontrollerini geçen artifact için yapılabilir. Robot account least privilege yetkisiyle kullanılmalıdır. Push sonrası digest doğrulanmalıdır. Registry webhook yeni artifact olayını diğer sistemlere bildirebilir. Audit log pipeline identity bilgisini kaydetmelidir.

Promote

Promotion aynı image'ın environment'lar arasında rebuild edilmeden taşınmasını sağlar. Digest korunarak test edilen artifact production'a aktarılır. Approval gate bu aşamaya eklenebilir. Production repository'de tag immutability uygulanabilir. Promotion işlemi otomatik audit kaydı üretmelidir.

Deploy

Deployment sırasında image digest ile referans edilmelidir. Kubernetes admission policy yalnızca approved registry kullanımını zorunlu kılabilir. Signature verification ve vulnerability gate uygulanabilir. Deployment metadata içinde artifact digest saklanmalıdır. Rollback aynı digest mekanizmasıyla güvenilir biçimde yapılabilir.

Retire

Retire aşaması artık kullanılmayan image'ın deployment listesinden çıkarılmasıdır. Production'da çalışan image yanlışlıkla silinmemelidir. Retention sistemi active deployment bilgisini dikkate alabilir. Legal veya audit gereksinimi varsa bazı artifact'lar daha uzun süre saklanabilir. Retire tarihi lifecycle metadata olarak tutulabilir.

Delete

Delete işleminden önce artifact'ın hiçbir aktif deployment tarafından kullanılmadığı doğrulanmalıdır. Tag veya manifest silinmesi storage alanını hemen boşaltmayabilir. Garbage collection sonraki aşamada fiziksel alanı temizler. Delete yetkisi sınırlı olmalıdır. Otomasyon işlemi dry-run raporu üretmelidir.

Image Retention Policy

Retention policy registry'nin kontrolsüz büyümesini önlemek için gereklidir. Development image'ları kısa süre tutulabilirken production artifact'ları daha uzun süre saklanabilir. Son N sürüm, yaş veya tag pattern kuralları birlikte kullanılabilir. Dry-run özelliği yanlış silme riskini azaltır. Policy değişiklikleri storage kapasite trendi ve business ihtiyacı üzerinden yapılmalıdır.

Retention Nedir?

Retention belirli artifact'ların ne kadar süre saklanacağını tanımlayan politikadır. Amaç hem storage maliyetini kontrol etmek hem gerekli rollback seçeneklerini korumaktır. Tek retention kuralı tüm project'lere uygulanmamalıdır. Development ve production farklı ihtiyaçlara sahiptir. Policy audit ve compliance gereksinimleriyle uyumlu olmalıdır.

Son N Image'ı Tutmak

Son N image yaklaşımı her repository'de belirli sayıda yeni sürümü korur. Development build'leri için pratik bir yöntemdir. Ancak uzun süre kullanılmayan production release'lerinin yanlışlıkla silinmesine neden olabilir. Production tag pattern'leri koruma listesine alınmalıdır. Dry-run sonuçları rollout öncesi incelenmelidir.

Yaşa Göre Retention

Yaşa göre retention belirli günden eski artifact'ları silmeye aday hale getirir. Dev build'lerinde 30 veya 60 günlük yaklaşım kullanılabilir. Production için daha uzun süre gerekebilir. Legal veya audit gereksinimleri ayrıca dikkate alınmalıdır. Aktif deployment image'ları otomatik koruma kapsamına alınabilir.

Tag Pattern Bazlı Retention

Tag pattern belirli release veya environment etiketlerini korumaya yardımcı olur. Örneğin release-* veya prod-* tag'leri daha uzun süre tutulabilir. Rastgele tag isimleri policy tasarımını zorlaştırır. Naming standard bu nedenle retention ile doğrudan ilişkilidir. Pattern değişiklikleri dry-run ile doğrulanmalıdır.

Production Image'larını Koruma

Production image'ları yanlışlıkla cleanup kapsamına girmemelidir. Immutable production tag veya ayrı project kullanımı bu riski azaltır. Deployment sisteminden aktif digest listesi alınabilir. Retention motoru bu digest'leri koruyabilir. Silme öncesi approval mekanizması kritik sistemlerde kullanılabilir.

Dry-Run

Dry-run policy uygulanmadan hangi artifact'ların silineceğini gösterir. Production retention değişikliklerinde mutlaka kullanılmalıdır. Sonuç ekip sorumluları tarafından incelenebilir. Beklenmeyen artifact listesi varsa kural düzeltilmelidir. Otomatik cleanup sistemlerinde dry-run raporu düzenli üretilmesi faydalıdır.

Garbage Collection Nedir?

Registry'de image silmek her zaman storage alanını anında boşaltmaz. Manifest kaldırıldıktan sonra bazı blob dosyaları referanssız halde kalabilir. Garbage collection bu orphan blob'ları tespit ederek fiziksel alanı temizler. İşlem kullanılan registry sürümüne göre online veya maintenance yaklaşımı gerektirebilir. Çalıştırmadan önce backup ve dry-run yapılması güvenli bir pratiktir.

Image Silmek Neden Diski Hemen Boşaltmaz?

Image silme çoğu zaman manifest veya tag referansını kaldırır. Layer blob'ları başka image'lar tarafından kullanılmaya devam ediyor olabilir. Registry bu ortak layer'ları hemen silemez. Referans kalmadığında blob garbage collection için aday olur. Bu nedenle logical deletion ile physical cleanup farklı işlemlerdir.

Manifest ve Blob İlişkisi

Manifest hangi blob layer'larının image'a ait olduğunu belirtir. Aynı blob birden fazla manifest tarafından referans edilebilir. Bu durum storage deduplication sağlar. Manifest silindiğinde blob başka manifest tarafından kullanılıyorsa korunmalıdır. Garbage collection referans ilişkisini dikkate alır.

Unreferenced Blob

Unreferenced blob artık hiçbir manifest tarafından kullanılmayan storage objesidir. Zaman içinde başarısız push veya silme işlemleri bu tür veriler bırakabilir. Storage kapasitesini gereksiz tüketir. Garbage collection bu verileri tespit eder. Silme öncesi registry consistency kontrolü yapılması faydalıdır.

Garbage Collection

Garbage collection orphan blob dosyalarını temizler. Büyük registry'lerde işlem süresi uzun olabilir. CPU ve storage I/O etkisi gözlemlenmelidir. Maintenance window gerekebilir. İşlem sonrası disk kullanımı ve registry health kontrol edilmelidir.

Dry-Run

GC dry-run silinecek blob listesini önceden gösterir. İlk çalıştırmada özellikle önemlidir. Beklenmeyen büyük veri listesi varsa işlem durdurulmalıdır. Backup mevcut olsa bile yanlış cleanup ciddi kesinti yaratabilir. Dry-run çıktısı operasyon kaydı olarak saklanabilir.

Read-Only / Maintenance Window

Bazı garbage collection yöntemleri push işlemlerinin durdurulmasını gerektirebilir. Registry read-only moda alınabilir. CI/CD ekiplerine bakım penceresi önceden bildirilmelidir. İşlem sırasında yeni manifest oluşturulması tutarsızlık riski doğurabilir. Kullanılan registry sürümünün resmi GC prosedürü izlenmelidir.

GC Sonrası Storage Kontrolü

Garbage collection tamamlandıktan sonra storage kullanım farkı ölçülmelidir. Registry push ve pull testleri yapılmalıdır. Error loglarında blob missing hatası bulunmadığı kontrol edilmelidir. Monitoring kısa süre daha yakından takip edilmelidir. Beklenen alan kazanımı yoksa retention veya orphan data analizi tekrar yapılabilir.

Retention ile Garbage Collection Arasındaki Fark

Retention hangi artifact'ın tutulacağını veya silineceğini belirleyen mantıksal politikadır. Garbage collection ise artık referans edilmeyen veriyi storage seviyesinde temizler. İki süreç birbirinin yerine geçmez. Doğru sıra önce retention ile gereksiz artifact'ları kaldırmak, ardından uygun zamanda garbage collection çalıştırmaktır. Bu süreç otomasyonla yönetildiğinde registry kapasitesi daha öngörülebilir hale gelir.

Logical Deletion

Logical deletion tag veya manifest referansını kaldırır. Kullanıcı artık artifact'ı normal yolla göremeyebilir. Ancak fiziksel blob storage içinde veri kalabilir. Başka manifest aynı blob'ı kullanıyorsa silinmemesi gerekir. Bu nedenle storage alanı hemen değişmeyebilir.

Physical Storage Cleanup

Physical cleanup referanssız blob verisinin gerçekten storage'dan silinmesidir. Garbage collection bu işlemi yürütür. Backup ve maintenance ihtiyacı registry implementasyonuna göre değişebilir. Büyük storage üzerinde işlem uzun sürebilir. Sonrasında kapasite metriği kontrol edilmelidir.

Doğru İşletim Sırası

Önce retention policy gereksiz artifact'ları seçmelidir. Silme işlemi tamamlandıktan sonra referanssız blob'lar oluşur. Ardından garbage collection çalıştırılabilir. GC öncesi dry-run ve backup tavsiye edilir. Bu sıralama yanlışlıkla aktif artifact silme riskini azaltır.

Otomasyon Stratejisi

Retention haftalık veya günlük schedule ile çalıştırılabilir. Garbage collection ise daha seyrek maintenance penceresinde yürütülebilir. Storage threshold alarmı gerektiğinde ek cleanup tetikleyebilir. Otomasyon her adımda log ve rapor üretmelidir. Production project'lerde approval gereksinimi uygulanabilir.

Vulnerability Scanning

Container image güvenliği registry yönetiminin ayrılmaz parçasıdır. Image içinde yalnızca uygulama kodu değil, işletim sistemi paketleri ve üçüncü taraf bağımlılıklar da bulunur. Scan işlemi bilinen CVE kayıtlarını bu bileşenlerle eşleştirir. Ancak çıkan her bulgu aynı risk seviyesinde değildir. Security gate tasarımında severity yanında exploitability ve business exposure da değerlendirilmelidir.

Container Image Neden Taranmalı?

Base image güncel görünse bile içinde bilinen zafiyetler bulunabilir. Uygulama dependency'leri de security risk taşıyabilir. Image scan build aşamasında sorunları erken tespit eder. Registry re-scan ise daha sonra yayınlanan yeni CVE'leri bulabilir. Bu iki yöntem birlikte kullanıldığında daha güçlü görünürlük sağlanır.

Trivy

Trivy container image ve bağımlılık taraması için yaygın kullanılan bir araçtır. Harbor ile entegre çalışabilir. Scanner database düzenli güncellenmelidir. Büyük image'larda scan süresi artabilir. CI ve registry scan sonuçlarının aynı policy diliyle değerlendirilmesi faydalıdır.

OS Package CVE'leri

OS package CVE'leri image içindeki dağıtım paketlerine ilişkin bilinen zafiyetleri gösterir. Minimal base image kullanmak gereksiz paket sayısını azaltabilir. Base image update süreci düzenli olmalıdır. Fixed version mevcutsa rebuild planlanabilir. Kullanılmayan paketleri kaldırmak saldırı yüzeyini azaltır.

Application Dependency CVE'leri

Application dependency zafiyetleri package manager üzerinden gelen kütüphanelerde bulunabilir. Lockfile kullanımı sürüm görünürlüğünü artırır. CI dependency scan bu bulguları build aşamasında yakalayabilir. Registry scan final image içindeki gerçek dependency setini kontrol eder. İki yaklaşım birbirini tamamlar.

Severity

Severity zafiyetin genel önem derecesini sınıflandırmak için kullanılır. Ancak yalnızca severity değerine göre karar vermek yanlış sonuç üretebilir. Internet exposure veya exploit availability risk seviyesini değiştirebilir. Production workload kritikliği ayrıca dikkate alınmalıdır. Security gate risk tabanlı model kullanmalıdır.

Low

Low bulgular düşük öncelikli olabilir ancak tamamen görmezden gelinmemelidir. Uzun süre biriken düşük riskli paketler teknik borç oluşturur. Düzenli base image update süreci bunların çoğunu temizleyebilir. Production gate genellikle low bulgular nedeniyle durdurulmaz. Ancak trend metriği izlenebilir.

Medium

Medium bulgular kullanım bağlamına göre önemli hale gelebilir. Internet-facing servis veya hassas veri işleyen workload için değerlendirme yapılmalıdır. Fixed version mevcutsa normal bakım döngüsünde güncelleme planlanabilir. Aynı dependency çok sayıda image'da kullanılıyorsa merkezi aksiyon alınmalıdır. SBOM analizi etkilenen image'ları hızlı bulmaya yardımcı olur.

High

High severity bulgular daha hızlı değerlendirme gerektirir. Exploitability ve reachability analizi yapılmalıdır. Fixed package version varsa rebuild önceliği artırılmalıdır. Production deployment gate koşullu olarak durdurulabilir. Exception verilecekse süreli risk acceptance kaydı tutulmalıdır.

Critical

Critical bulgular özellikle internet-facing ve yüksek ayrıcalıklı workload'larda acil değerlendirilmelidir. Bilinen exploit mevcutsa deployment engellenebilir. False positive ihtimali teknik kanıtla incelenmelidir. Exception ancak açık onay ve expiration date ile verilmelidir. Rebuild ve patch tamamlandığında exception otomatik kapanmalıdır.

Scan on Push

Scan on push yeni image registry'ye geldiği anda güvenlik analizi başlatır. Geliştirici sonuçları deployment öncesinde görebilir. Scanner queue yoğunluğu yüksekse sonuç gecikebilir. Pipeline scan tamamlanana kadar bekleyebilir. Production promotion yalnızca başarılı security gate sonrasında yapılabilir.

Scheduled Re-Scanning

Yeni CVE kayıtları her gün yayınlandığı için eski image'ların yeniden taranması gerekir. Scheduled re-scan bu ihtiyacı karşılar. Production'da çalışan image'lar öncelikli taranabilir. Yeni critical bulgu oluştuğunda security ekibine alarm gönderilebilir. Deployment inventory ile registry scan sonuçları ilişkilendirilmelidir.

Vulnerability Policy ve Security Gate

Security gate hangi vulnerability seviyesinde pipeline'ın duracağını tanımlar. Her critical bulgunun otomatik olarak aynı sonucu üretmesi pratik olmayabilir. Exploitability, exposure ve business criticality gibi faktörler birlikte değerlendirilmelidir. Exception süreci teknik gerekçe, owner ve expiration date içermelidir. Güvenlik politikası geliştiricilerin anlayabileceği kadar açık olmalıdır.

Kritik CVE'li Image Push Edilebilir mi?

Push işlemine izin verip deployment'ı engellemek bazı ekiplerde daha pratik bir modeldir. Böylece artifact registry'de saklanır ve analiz edilebilir. Ancak production project'e promotion engellenebilir. Kritik bulgu remediation sonrası yeni image üretilmesini gerektirir. Policy kurumun risk iştahına göre belirlenmelidir.

Kritik CVE'li Image Pull Edilebilir mi?

Pull engelleme production güvenliğini güçlendirebilir ancak operasyonel risk yaratır. Acil rollback sırasında eski image çekilemiyorsa sistem kurtarma zorlaşabilir. Bu nedenle bazı ortamlarda yalnızca yeni deployment engellenir. Running workload etkilenmeden risk yönetimi yapılabilir. Policy önceden test edilmelidir.

Pipeline'ı Durdurmak

Pipeline security gate belirli risk eşiğinde build veya deployment akışını durdurabilir. Hata mesajı hangi CVE ve hangi paket nedeniyle durduğunu açıkça göstermelidir. Geliştiricinin remediation yolunu anlaması önemlidir. False positive için exception bağlantısı bulunabilir. Gate sadece engellemek yerine yönlendirici bilgi sunmalıdır.

Exception Workflow

Exception workflow güvenlik politikasının kontrollü biçimde geçici olarak aşılmasını sağlar. Her exception teknik gerekçe, owner ve son kullanma tarihi içermelidir. Süresiz exception verilmemelidir. Onay security veya risk sahibi tarafından yapılabilir. Expiration geldiğinde gate otomatik tekrar aktif olmalıdır.

False Positive

Scanner bazı durumlarda gerçekte kullanılmayan dependency nedeniyle bulgu üretebilir. False positive kararı varsayımla değil kanıtla verilmelidir. Package gerçekten runtime path içinde kullanılmıyorsa dokümante edilebilir. Scanner güncellemesi sonrası bulgu tekrar kontrol edilmelidir. Kalıcı ignore kuralları minimum tutulmalıdır.

Risk Acceptance

Risk acceptance zafiyetin belirli süre için kabul edilmesidir. Business owner ve security ekibi karara dahil olabilir. Kabul nedeni ve remediation planı kayıt altına alınmalıdır. Yüksek riskli kabul için ek network veya runtime kontrolü uygulanabilir. Süre sonunda karar yeniden değerlendirilmelidir.

Expiration Date ile Exception

Expiration date exception'ın unutulmasını önler. Tarih geldiğinde policy tekrar enforcement moduna geçebilir. Owner'a önceden uyarı gönderilmelidir. Düzeltme tamamlanmışsa exception kapatılır. Tamamlanmamışsa yeniden onay süreci gerekir.

CVE Severity Tek Başına Yeterli mi?

Hayır, CVE severity önemli bir başlangıç göstergesidir ancak tek başına production riskini tanımlamaz. Aynı critical zafiyet internete açık bir uygulamada yüksek risk oluştururken erişilemeyen bir test container'ında daha düşük öncelikte olabilir. Exploitability, reachability ve fixed version bilgisi değerlendirilmelidir. Business criticality de kararın parçasıdır. Risk-based prioritization güvenlik ekibinin en önemli sorunlara önce müdahale etmesini sağlar.

Exploitability

Exploitability zafiyetin gerçek saldırıda ne kadar kolay kullanılabildiğini değerlendirir. Public exploit bulunması önceliği artırabilir. Saldırı için özel koşullar gerekiyorsa risk daha farklı ele alınabilir. Runtime configuration exploit yolunu kapatabilir. Security ekibi severity ile exploitability verisini birlikte değerlendirmelidir.

Reachability

Reachability zafiyetli kodun uygulama tarafından gerçekten çağrılıp çağrılmadığını inceler. Dependency image içinde bulunabilir ancak runtime sırasında kullanılmayabilir. Reachability analizi false positive ve önceliklendirme konusunda yardımcı olur. Yine de gelecekte kod yolu değişebileceği için bulgu tamamen unutulmamalıdır. Fixed version çıktığında güncelleme planlanabilir.

Internet Exposure

Internet-facing workload daha yüksek saldırı yüzeyine sahiptir. Aynı zafiyet yalnızca internal management network içinde çalışan serviste farklı risk taşıyabilir. Network segmentasyonu geçici azaltıcı kontrol olabilir. Ancak kritik zafiyeti kalıcı olarak kabul etmek için tek başına yeterli değildir. Exposure bilgisi vulnerability yönetim sistemine eklenmelidir.

Business Criticality

Ödeme, kimlik veya temel iş süreçlerini yöneten uygulamalar daha yüksek business criticality taşır. Bu workload'larda remediation süresi daha kısa tutulabilir. Development yardımcı servislerinde farklı SLA uygulanabilir. Uygulama owner bilgisi registry metadata ile ilişkilendirilebilir. Security ekibi önceliği buna göre belirleyebilir.

Fixed Version Mevcut mu?

Fixed version bulunması remediation kararını kolaylaştırır. Base image veya dependency güncellenerek yeni build oluşturulabilir. Fix yoksa ek azaltıcı kontroller gerekebilir. Risk acceptance süresi kısa tutulmalıdır. Fixed version yayınlandığında otomatik bildirim sistemi oluşturulabilir.

Risk-Based Prioritization

Risk-based prioritization severity, exploitability, exposure ve business criticality bilgilerini birleştirir. Böylece ekip yüzlerce bulgu arasında en önemli olanlara odaklanabilir. Production internet-facing critical zafiyet ilk sırada ele alınabilir. Low-risk development bulguları planlı bakım sırasında düzeltilebilir. Bu yöntem güvenlik kaynaklarının daha verimli kullanılmasını sağlar.

SBOM ve Registry

SBOM bir image içinde hangi yazılım bileşenlerinin bulunduğunu kayıt altına alır. Büyük organizasyonlarda belirli bir dependency zafiyetli olduğunda hangi image'ların etkilendiğini hızla bulmak için çok değerlidir. SPDX veya CycloneDX formatları kullanılabilir. SBOM build sırasında oluşturulup OCI artifact olarak registry içinde saklanabilir. Image digest ile SBOM arasında açık ilişki kurulmalıdır.

SBOM Nedir?

SBOM bir yazılım artifact'ının bileşen listesini sağlar. Paket adı, sürüm ve dependency bilgileri içerebilir. Güvenlik ekipleri yeni CVE yayınlandığında etkilenen artifact'ları bu veriden bulabilir. Compliance süreçlerinde de kullanılabilir. SBOM tek başına vulnerability scanner yerine geçmez ancak görünürlüğü artırır.

SPDX

SPDX yazılım bileşen ve lisans bilgilerini ifade etmek için kullanılan standart formatlardan biridir. Build pipeline içinde otomatik üretilebilir. Registry ile image digest üzerinden ilişkilendirilebilir. Tooling desteği sayesinde farklı sistemler arasında taşınabilir. Format seçimi kurumun mevcut security araçlarıyla uyumlu olmalıdır.

CycloneDX

CycloneDX özellikle security ve supply chain kullanımında yaygın bir SBOM formatıdır. Dependency ve component ilişkilerini temsil edebilir. CI pipeline içinde üretilebilir. Registry'de OCI artifact olarak saklanabilir. Vulnerability management sistemi bu bilgiyi kullanarak affected image listesini çıkarabilir.

Image Build Sırasında SBOM Üretmek

SBOM'un build sırasında üretilmesi artifact ile aynı source revision'a bağlanmasını sağlar. CI pipeline commit SHA ve image digest bilgisini SBOM metadata içine ekleyebilir. Build sonrası üretilen SBOM repository'ye gönderilebilir. Pipeline başarısız olursa eksik SBOM'lu image production'a promote edilmemelidir. Bu kontrol policy olarak uygulanabilir.

SBOM'u OCI Artifact Olarak Saklamak

OCI artifact yaklaşımı SBOM'u doğrudan registry içinde saklamaya imkan verir. Böylece ayrı dosya sunucusu yönetme ihtiyacı azalır. SBOM ilgili image digest ile ilişkilendirilebilir. Access control aynı project politikası üzerinden uygulanabilir. Retention sırasında image ve ilişkili SBOM birlikte ele alınmalıdır.

SBOM ile Etkilenen Image'ları Bulmak

Yeni kritik dependency zafiyeti yayınlandığında SBOM index üzerinden hangi image'ların ilgili sürümü içerdiği aranabilir. Bu yöntem manuel repository taramasından çok daha hızlıdır. Production deployment inventory ile sonuçlar birleştirilebilir. Önce aktif çalışan image'lar patch edilebilir. Böylece vulnerability response süresi önemli ölçüde azalır.

Container Image Signing

Image signing artifact'ın güvenilir üretim sürecinden geçtiğini kanıtlamaya yardımcı olur. CI pipeline başarılı test ve security gate sonrasında image'ı imzalayabilir. Deployment sistemi yalnızca güvenilir signer tarafından imzalanmış image'ları kabul edebilir. Key-based veya keyless modeller değerlendirilebilir. Signing key compromise senaryosu mutlaka incident response planında yer almalıdır.

Image Signing Neden Gereklidir?

Registry erişimi ele geçirilirse saldırgan kötü niyetli image push etmeye çalışabilir. İmza doğrulaması yalnızca registry'de bulunmanın güvenilirlik için yeterli olmadığını varsayar. Deployment öncesinde artifact signature kontrol edilir. Bu yaklaşım supply chain saldırılarına karşı ek koruma sağlar. İmza politikası production environment için zorunlu hale getirilebilir.

Cosign

Cosign container image ve OCI artifact imzalama işlemlerinde kullanılabilen bir araçtır. Image digest üzerinden signature üretilebilir. Verification deployment pipeline veya admission controller içinde çalıştırılabilir. Key-based ve keyless modeller desteklenebilir. Signature metadata registry içinde tutulabilir.

Key-Based Signing

Key-based signing private key kullanarak signature üretir. Private key yüksek güvenlikli secret yönetim sisteminde tutulmalıdır. CI runner'a kalıcı dosya olarak bırakılmamalıdır. Key rotation planı belirli aralıklarla uygulanmalıdır. Public key dağıtımı deployment sistemlerine kontrollü yapılmalıdır.

Keyless Signing

Keyless signing uzun ömürlü private key yönetimini azaltmayı amaçlar. Kimlik sağlayıcı ve kısa süreli certificate yapıları kullanılabilir. Bu model pipeline identity bilgisini signature ile ilişkilendirebilir. Network ve identity bağımlılıkları değerlendirilmelidir. Air-gapped ortamlarda uygulanabilirlik ayrıca test edilmelidir.

Signature Storage

Signature registry içinde image ile ilişkili OCI artifact olarak saklanabilir. Böylece artifact ve verification metadata aynı platformda yönetilir. Retention sırasında signature yanlışlıkla ayrı silinmemelidir. Access control signature push işlemini yalnızca güvenilir CI hesabıyla sınırlandırmalıdır. Audit log hangi signer'ın hangi digest'i imzaladığını göstermelidir.

Signature Verification

Verification production deployment öncesinde yapılmalıdır. Signature'ın geçerli olması kadar signer kimliğinin güvenilir listede bulunması da önemlidir. Revoked key ile üretilen signature kabul edilmemelidir. Policy enforcement Kubernetes admission katmanında uygulanabilir. Başarısız verification deployment'ı durdurmalıdır.

Signed Image Policy

Signed image policy production ortamına yalnızca doğrulanmış artifact alınmasını sağlar. Güvenilir signer listesi merkezi olarak yönetilmelidir. Key rotation sırasında eski ve yeni key geçişi kontrollü yapılmalıdır. Compromised key tespit edildiğinde ilgili signer hızla revoke edilmelidir. Policy exception süreci çok sınırlı tutulmalıdır.

Yalnızca İmzalı Image Kabul Etmek

Production admission policy unsigned image deployment'ını engelleyebilir. Development ortamında uyarı modu kullanılabilir. Böylece ekip süreçlere aşamalı olarak adapte olur. CI pipeline imza oluşturamadığında promotion işlemi durdurulur. Emergency deployment için exception prosedürü varsa kayıt altına alınmalıdır.

Güvenilir Signer Listesi

Her imza güvenilir değildir. Signer identity veya public key approved listede olmalıdır. Listenin kim tarafından değiştirilebileceği sınırlandırılmalıdır. Security ekibi değişiklikleri onaylayabilir. Liste rotation ve incident durumlarında hızlı güncellenebilmelidir.

Production Deployment Öncesi Verification

Verification image cluster'a çekilmeden veya pod başlamadan önce yapılabilir. Admission controller digest ve signature ilişkisini kontrol eder. Başarısız kontrol deployment'ı engeller. Log mesajı operasyon ekibine açık neden sunmalıdır. Verification bypass girişimleri audit alarmı üretmelidir.

Key Rotation

Signing key belirli aralıklarla değiştirilmelidir. Yeni key deployment policy'ye eklenmeden eski key kaldırılmamalıdır. Mevcut production image signature'ları rollback için hala gerekli olabilir. Rotation planı eski artifact'ların doğrulanabilirliğini korumalıdır. Key kullanım geçmişi audit kaydında tutulmalıdır.

Compromised Signing Key Senaryosu

Signing key sızdığında saldırgan güvenilir görünen kötü amaçlı artifact imzalayabilir. İlgili key hemen revoke edilmelidir. Bu key ile imzalanmış yakın dönem artifact'lar incelenmelidir. CI credential ve registry audit logları kontrol edilmelidir. Gerekirse production deployment digest'leri temiz backup veya güvenilir build kayıtlarıyla karşılaştırılmalıdır.

Software Supply Chain Provenance

Provenance bir artifact'ın hangi kaynak koddan, hangi pipeline ile ve hangi builder kimliği tarafından üretildiğini gösterir. Digest ile birlikte kullanıldığında artifact geçmişi doğrulanabilir hale gelir. Git commit, CI run ve builder identity bilgileri kayıt altına alınabilir. SLSA gibi yaklaşımlar bu güven zincirini standartlaştırmayı amaçlar. Registry provenance attestation verilerini OCI artifact olarak saklayabilir.

Artifact Provenance Nedir?

Artifact provenance yazılım çıktısının üretim geçmişidir. Hangi repository, commit ve pipeline run'ın artifact oluşturduğu bilgisi tutulabilir. Incident durumunda image'ın kaynağı hızlıca belirlenebilir. Reproducibility ve audit için faydalıdır. Provenance verisi de imzalanarak bütünlüğü korunabilir.

Build'in Kaynağını Doğrulamak

Build source bilgisi yalnızca tag adına bakılarak doğrulanmamalıdır. CI pipeline commit SHA ve repository URI bilgisini attestation içine ekleyebilir. Artifact digest ile bu veri ilişkilendirilir. Deployment sistemi güvenilir repository ve pipeline policy'si uygulayabilir. Böylece manuel olarak üretilmiş image'ın production'a girmesi zorlaşır.

Git Commit

Git commit artifact'ın source revision bilgisini sağlar. Commit SHA build metadata içinde tutulmalıdır. Branch adı tek başına yeterli değildir çünkü branch değişebilir. Protected branch policy release güvenliğini artırır. Commit signature veya review policy ek kontrol sağlayabilir.

CI Pipeline

CI pipeline artifact'ın hangi otomasyon sürecinden geçtiğini gösterir. Pipeline ID ve run URL audit kaydına eklenebilir. Security scan ve test sonuçları aynı run ile ilişkilendirilebilir. Production signer yalnızca onaylı pipeline içinde erişilebilir olmalıdır. Manuel local build'ler production signer kullanamamalıdır.

Builder Identity

Builder identity artifact'ı oluşturan runner veya workload kimliğini tanımlar. Shared static credential yerine workload identity tercih edilebilir. Böylece hangi build sistemi tarafından imzalama yapıldığı doğrulanabilir. Compromised runner durumunda ilgili identity revoke edilebilir. Provenance policy güvenilir builder listesi üzerinden çalışabilir.

SLSA

SLSA software supply chain güvenliği için olgunluk seviyeleri ve kontrol prensipleri sunar. Build provenance ve güvenilir builder yaklaşımını destekler. Kurumlar tüm seviyeleri bir anda uygulamak zorunda değildir. Önce reproducible build, provenance ve signing gibi temel kontrollerle başlanabilir. Registry bu artifact metadata'sının merkezi saklama noktası olabilir.

Provenance Attestation

Provenance attestation artifact'ın nasıl üretildiğine ilişkin imzalı metadata'dır. Image digest ile ilişkilendirilebilir. Deployment policy attestation içindeki builder veya source bilgisini kontrol edebilir. Registry OCI artifact desteği sayesinde attestation saklayabilir. Retention policy image ile ilişkili metadata'yı birlikte korumalıdır.

Public Registry Proxy Cache

Proxy cache public image kullanımını merkezi ve kontrollü hale getirir. CI/CD sistemleri doğrudan dış registry yerine kurum içi cache endpoint'ini kullanır. İlk istek dış kaynaktan image'ı alır, sonraki istekler local cache üzerinden karşılanabilir. Bu yöntem bandwidth tüketimini ve pull latency değerini azaltabilir. Security scanning eklendiğinde public image'lar kurum içine girmeden önce daha kontrollü biçimde yönetilir.

Proxy Cache Nedir?

Proxy cache dış registry içeriğini talep üzerine kurum içine kopyalayan ara katmandır. Kullanıcı aynı image'ı tekrar istediğinde local kopya sunulabilir. Network çıkışı azalır. Rate limit sorunları daha az yaşanabilir. Cache retention ve security politikaları ayrıca belirlenmelidir.

Docker Hub Cache

Public Docker image kaynakları için cache kullanımı CI/CD sürelerini daha öngörülebilir hale getirir. Sık kullanılan base image bir kez indirilir. Sonraki build'ler kurum içi registry üzerinden layer çekebilir. Bu yapı direct internet access ihtiyacını azaltır. Cache içindeki image'lar da security scan kapsamına alınmalıdır.

Public Image'ı Bir Kez İndirmek

Aynı base image yüzlerce build tarafından kullanılıyorsa her seferinde dışarıdan çekmek gereksiz trafik oluşturur. Proxy cache image layer'larını local olarak saklar. CI runner'lar internal network üzerinden daha hızlı erişebilir. Cache miss durumunda dış bağlantı kullanılır. Bu trafik egress policy ile sınırlandırılabilir.

Bandwidth Tasarrufu

Container image'lar yüzlerce MB veya birkaç GB olabilir. Aynı image tekrar tekrar çekildiğinde ciddi network çıkışı oluşur. Cache bu trafiği büyük ölçüde azaltabilir. Özellikle çoklu runner ortamında etkisi belirgin olur. Bandwidth metriği cache öncesi ve sonrası ölçülerek fayda görülebilir.

Pull Latency Azaltma

Registry build veya cluster node'larına yakınsa pull latency düşebilir. Internet latency ve dış servis yoğunluğu devreden çıkar. Kubernetes autoscaling sırasında pod başlangıç süresi iyileşebilir. Cache hit ratio önemli bir metrik olabilir. Sık kullanılan image'lar için yüksek hit ratio hedeflenebilir.

Docker Hub Rate Limit Azaltma

Proxy cache dış registry'ye yapılan gerçek istek sayısını azaltabilir. Aynı layer local cache'den sunulduğunda yeni dış pull gerekmez. CI build'lerinin kota nedeniyle başarısız olma ihtimali düşer. Cache refresh davranışı izlenmelidir. Base image güncelliği için version pinning kullanılmalıdır.

Security Scanning ile Cache

Cache'e giren public image'ların güvenli olduğu varsayılmamalıdır. Scanner cache artifact'larını analiz edebilir. Kritik bulgu varsa internal promotion engellenebilir. Approved base image listesi oluşturulabilir. Böylece public image kullanımı merkezi security policy ile yönetilir.

Public Image'ları Kurum İçine Kontrollü Almak

Public image kullanımında temel hedef geliştiricilerin ihtiyaçlarını tamamen engellemek değil, kaynağı ve güvenliği kontrol etmektir. Direct internet pull yerine approved registry listesi kullanılabilir. Base image önce mirror project'e alınır, scan edilir ve gerekirse imzalanır. Ardından internal production namespace'e promote edilir. Böylece hangi public artifact'ın kurum içinde kullanıldığı izlenebilir hale gelir.

Direct Internet Pull'u Engellemek

Kubernetes node ve CI runner'ların doğrudan internete çıkması supply chain görünürlüğünü azaltır. Firewall veya admission policy ile dış registry erişimi sınırlandırılabilir. Kullanıcılar approved internal proxy üzerinden image çekebilir. Gereken yeni image için talep süreci oluşturulabilir. Bu model security scanning ve audit kontrolünü merkezileştirir.

Approved Registry List

Approved registry list yalnızca güvenilir kaynaklardan artifact kullanımına izin verir. Kubernetes admission policy bu listeyi enforce edebilir. Liste değişiklikleri security approval gerektirebilir. Wildcard izinler minimum tutulmalıdır. Internal registry varsayılan kaynak olarak kullanılmalıdır.

Approved Base Image

Approved base image listesi geliştiricilerin rastgele base image seçmesini engeller. Security ekibi belirli minimal ve güncel image sürümlerini yayınlayabilir. Pipeline yalnızca bu registry path'lerinden build yapmaya izin verebilir. Güncellemeler merkezi olarak duyurulur. Eski base image kullanımı policy ile aşamalı olarak engellenebilir.

Image Mirroring

Image mirroring dış artifact'ı internal registry'ye kopyalar. Digest korunarak source artifact ile eşleşme doğrulanabilir. Mirror sonrası vulnerability scan çalıştırılmalıdır. Güvenilirlik için signature veya provenance kontrolü yapılabilir. Internal kullanıcılar yalnızca mirror path'ini kullanmalıdır.

Security Scan

Public image kurum içine alınmadan önce zafiyet taramasından geçirilmelidir. Critical bulgular remediation veya exception gerektirir. Scanner sonucunun tarihi önemlidir çünkü CVE database sürekli değişir. Production promotion öncesinde yeniden tarama yapılabilir. Scan sonucu image digest ile saklanmalıdır.

Signing

Approved internal image security kontrollerinden geçtikten sonra kurum signer kimliğiyle imzalanabilir. Böylece deployment sistemi dış source signature yerine internal approval signature'ını kontrol eder. Signing yalnızca güvenilir pipeline tarafından yapılmalıdır. Private key güvenliği kritik öneme sahiptir. Revoke edilen signer ile yeni deployment engellenmelidir.

Internal Promotion

Internal promotion image'ı approved veya production project'e taşır. Bu işlem rebuild yapmadan gerçekleştirilmelidir. Digest korunur ve test edilen artifact değişmez. Approval gate security ve application owner onayı isteyebilir. Promotion olayı audit log içinde tutulmalıdır.

Base Image Governance

Base image seçimi tüm container güvenliğini etkileyen temel kararlardan biridir. Her ekip farklı ve kontrolsüz base image kullandığında patch yönetimi zorlaşır. Golden image yaklaşımı kurum tarafından onaylanmış sürümlerin merkezi olarak yayınlanmasını sağlar. Minimal veya distroless image kullanımı saldırı yüzeyini azaltabilir. Version pinning ve düzenli update süreci governance modelinin parçası olmalıdır.

Golden Image Nedir?

Golden image kurum tarafından güvenlik ve operasyon kriterlerine göre onaylanmış temel image'dır. İçinde gerekli certificate, timezone veya security configuration bulunabilir. Gereksiz araçlar eklenmemelidir. Merkezi ekip image'ı düzenli günceller. Uygulama ekipleri kendi Dockerfile'larında approved registry path'ini kullanır.

Approved Base Images

Approved base image listesi desteklenen image ve sürümleri tanımlar. Eski veya unsupported sürümler listeden çıkarılabilir. CI policy izin verilmeyen base image kullanımında build'i durdurabilir. Security ekibi vulnerability durumunu düzenli takip eder. Yeni base image talebi kontrollü süreçten geçebilir.

Minimal Image

Minimal image yalnızca uygulamanın çalışması için gereken bileşenleri içerir. Daha az paket daha küçük saldırı yüzeyi anlamına gelir. Image boyutu da genellikle küçülür. Troubleshooting araçları bulunmayabileceği için debug süreci ayrı yöntem gerektirir. Development ve production image'ları farklı olabilir.

Distroless Image

Distroless yaklaşımında shell ve package manager gibi birçok klasik araç image içinde bulunmaz. Bu durum saldırı yüzeyini azaltabilir. Ancak runtime troubleshooting daha planlı yapılmalıdır. Uygulamanın ihtiyaç duyduğu library'ler doğru paketlenmelidir. Security scanner distroless image içeriğini desteklemelidir.

Version Pinning

Version pinning build'in beklenmedik şekilde farklı base image kullanmasını engeller. floating tag yerine belirli sürüm veya digest kullanılabilir. Rebuild sırasında reproducibility artar. Güncellemeler kontrollü pull request ile yapılabilir. Security patch geldiğinde otomatik dependency update süreci tetiklenebilir.

Base Image Update Süreci

Base image güvenlik yamaları için düzenli olarak rebuild edilmelidir. Yeni sürüm vulnerability scan ve testlerden geçmelidir. Uygulama ekiplerine güncelleme bildirimi yapılabilir. Kritik CVE varsa otomatik pull request üretilebilir. Eski sürüm belirli grace period sonrasında policy ile engellenebilir.

Harbor Registry Replication

Replication çoklu lokasyon ve disaster recovery senaryolarında image dağıtımını kolaylaştırır. Push-based model merkezi registry'den hedefe artifact gönderirken pull-based model hedefin kaynaktan almasını sağlar. Scheduled veya event-based replication kullanılabilir. Filter kuralları yalnızca gerekli project ve tag'lerin taşınmasını sağlar. Replication failure ve lag değerleri monitoring kapsamına alınmalıdır.

Replication Nedir?

Replication registry içeriğinin başka bir registry noktasına kopyalanmasıdır. Amaç düşük latency, DR veya ayrık network bölgeleri arasında artifact dağıtımı olabilir. Digest korunması bütünlük açısından önemlidir. Replication policy yanlış yapılandırılırsa gereksiz büyük veri transferi oluşabilir. Hedef registry kapasitesi ayrıca planlanmalıdır.

Push-Based Replication

Push-based model kaynak registry'nin artifact'ı hedefe göndermesidir. Merkezi yönetim yaklaşımına uygundur. Event sonrası otomatik tetiklenebilir. Network firewall hedef yönüne göre açılmalıdır. Başarısız replication retry politikası bulunmalıdır.

Pull-Based Replication

Pull-based model hedef registry'nin kaynaktan artifact çekmesidir. Hedef lokasyonun network politikasına daha uygun olabilir. Schedule ile düzenli senkronizasyon yapılabilir. Credential yalnızca pull yetkisine sahip olabilir. Network partition sonrasında catch-up davranışı test edilmelidir.

Scheduled Replication

Scheduled replication belirli saat veya aralıkta çalışır. Düşük trafik dönemleri tercih edilebilir. Büyük veri transferlerinde network kapasitesi korunur. Ancak yeni critical release hedefe ulaşana kadar gecikme oluşabilir. Production RTO ihtiyacına göre schedule belirlenmelidir.

Event-Based Replication

Event-based replication yeni push geldiğinde otomatik çalışabilir. Release artifact'ı diğer lokasyona daha hızlı ulaşır. Çok yoğun build ortamında fazla job oluşabilir. Filter kullanımı önemlidir. Replication queue ve failure alarmı kurulmalıdır.

Filter

Filter hangi project, repository veya tag'in replicate edileceğini belirler. Development build'lerinin tüm lokasyonlara taşınması gerekmeyebilir. Yalnızca production release'leri filtrelemek bandwidth tasarrufu sağlar. Pattern değişiklikleri dikkatli test edilmelidir. Yanlış filter kritik artifact'ın hedefe ulaşmasını engelleyebilir.

Multi-Site Registry

Multi-site registry coğrafi olarak dağıtılmış ekip ve cluster'lara yakın image kaynağı sağlar. Her site local pull yapabilir. Merkezi governance replication policy ile korunabilir. Network partition durumunda local cache veya replica çalışmaya devam edebilir. Conflict ve ownership modeli önceden tanımlanmalıdır.

Çoklu Veri Merkezi Registry Mimarisi

Çoklu veri merkezi mimarisinde yalnızca replication değil, network partition ve conflict yönetimi de düşünülmelidir. Merkezi registry modeli governance açısından basittir ancak uzak lokasyonlarda latency yaratabilir. Bölgesel registry'ler performansı iyileştirir. Active/passive DR daha kolay yönetilebilirken active/active model daha fazla coordination gerektirir. İş hedefleri mimari seçimi belirlemelidir.

Merkezi Registry

Merkezi registry tüm image operasyonlarını tek noktada toplar. Governance ve audit daha kolaydır. Uzak veri merkezleri yüksek latency yaşayabilir. Merkezi servis arızası geniş etki oluşturur. Regional cache veya replication bu riski azaltabilir.

Bölgesel Registry

Bölgesel registry cluster'lara yakın image erişimi sağlar. Pull latency ve WAN bandwidth kullanımı azalır. Artifact governance merkezi policy ile yönetilmelidir. Replication lag monitoring gerektirir. Hangi bölgenin source of truth olduğu açıkça belirlenmelidir.

Active/Passive

Active/passive model bir primary ve hazır standby registry kullanır. DR senaryosu daha anlaşılırdır. Replication primary'den secondary'ye yapılır. Failover DNS veya load balancer değişikliğiyle gerçekleşebilir. Düzenli failover testi zorunludur.

Active/Active

Active/active model birden fazla registry noktasının aynı anda yazma kabul etmesini sağlar. Ancak conflict yönetimi daha zordur. Aynı tag farklı digest ile iki lokasyonda oluşabilir. Immutable tag ve source ownership kuralları gereklidir. Bu model gerçekten ihtiyaç varsa seçilmelidir.

Latency

WAN latency büyük image pull sürelerini uzatabilir. Bölgesel replica veya cache bu etkiyi azaltır. P95 pull latency site bazında ölçülmelidir. Network bandwidth de latency kadar önemlidir. Kubernetes scale-out testleri gerçek workload ile yapılmalıdır.

Network Partition

Network partition veri merkezleri arasındaki iletişimin kesilmesidir. Local registry pull işlemleri devam edebilir. Yeni artifact replication beklemeye alınmalıdır. Connection döndüğünde senkronizasyon kontrollü yapılmalıdır. Active/active yapıda conflict ortaya çıkma ihtimali değerlendirilmelidir.

Conflict Yönetimi

Conflict aynı tag veya repository üzerinde farklı değişikliklerin oluşmasıdır. Immutable tag kullanımı bu problemi büyük ölçüde azaltır. Tek write owner yaklaşımı daha güvenli olabilir. Conflict tespit edilirse otomatik overwrite yapılmamalıdır. Digest karşılaştırması ve audit log incelemesi yapılmalıdır.

Disaster Recovery

DR mimarisi primary site tamamen kaybedildiğinde registry hizmetinin nasıl döneceğini tanımlar. Secondary registry'nin güncelliği replication lag ile ölçülmelidir. DNS failover süresi RTO hedefiyle uyumlu olmalıdır. Authentication ve certificate yapılandırmaları secondary ortamda da hazır olmalıdır. Yılda birkaç kez restore veya failover drill yapılması faydalıdır.

Air-Gapped Ortamda Docker Registry

Air-gapped registry dış internet bağlantısı olmayan ortamlarda artifact dağıtımının merkezidir. Image, vulnerability database ve installer paketleri kontrollü transfer sürecinden geçer. Removable media veya transfer gateway üzerinden gelen dosyalar checksum ve signature ile doğrulanmalıdır. Approved artifact bundle yaklaşımı hangi içeriğin içeri alınacağını standartlaştırır. Offline ortamın güvenli olması dışarıdan gelen artifact'ların güvenilir olduğu anlamına gelmez.

Air Gap Nedir?

Air gap kritik network ile dış dünya arasında doğrudan bağlantı bulunmamasını ifade eder. Artifact transferi kontrollü mekanizmalar üzerinden yapılır. CI/CD sistemi tamamen içeride çalışabilir. Security update paketlerinin taşınması planlı süreç gerektirir. Her transfer audit kaydına alınmalıdır.

Offline Harbor Installer

Offline installer gerekli platform image'larını internet olmadan kurmayı sağlar. Paket dış ortamda indirildikten sonra integrity kontrolü yapılmalıdır. İç ortama alınırken removable media policy uygulanabilir. Installer version bilgisi CMDB veya operasyon dokümanında tutulmalıdır. Upgrade paketleri aynı süreçten geçmelidir.

Image Transfer Pipeline

Image transfer pipeline dış source artifact'ını indirir, scan eder ve imza kontrolü yapar. Onaylandıktan sonra güvenli transfer formatına paketlenir. İç ortamda tekrar digest doğrulaması yapılır. Registry'ye yalnızca approved artifact push edilir. Manuel USB transfer yerine standart pipeline kullanılması hata riskini azaltır.

Offline Vulnerability Database

Scanner internet olmadan güncel CVE database alamaz. Database paketleri kontrollü olarak dış ortamdan içeri taşınmalıdır. Güncelleme sıklığı risk politikasına göre belirlenmelidir. Database yaşı monitoring ile takip edilmelidir. Çok eski database ile yapılan scan güvenilir kabul edilmemelidir.

Approved Artifact Bundle

Artifact bundle image, SBOM, signature ve provenance bilgilerini birlikte taşıyabilir. Bundle manifest içinde digest listesi bulunabilir. İç ortama girişte tüm digest'ler doğrulanır. Eksik veya değiştirilmiş artifact kabul edilmez. Bu yapı transfer sürecini daha izlenebilir hale getirir.

Removable Media Kontrolleri

Removable media güvenlik politikası yalnızca fiziksel cihaz kontrolü değildir. Malware scan, device inventory ve transfer kaydı uygulanmalıdır. Medya yalnızca belirli sistemlerde kullanılabilir. Yazma koruma veya şifreleme değerlendirilebilir. Kullanım sonrası saklama veya imha prosedürü bulunmalıdır.

Signature Verification

Air-gapped ortamda signature verification artifact kaynağını doğrulamak için çok önemlidir. Verification key önceden güvenli biçimde iç ortama dağıtılmalıdır. Revocation bilgisi de düzenli güncellenmelidir. Başarısız signature artifact'ın iç registry'ye alınmasını engellemelidir. Doğrulama sonucu audit kaydında tutulmalıdır.

CI/CD Pipeline ile Registry Entegrasyonu

CI/CD entegrasyonu registry kullanımını manuel süreçten güvenilir release hattına dönüştürür. Build, test, scan, SBOM, signing, push ve deployment adımları belirli sırada çalışmalıdır. Her artifact commit SHA ve digest ile izlenmelidir. Pipeline başarısız güvenlik kontrolünü atlayamamalıdır. Kurum İçi Docker Registry Kurulumu ve Yönetimi açısından en güçlü sonuç, registry'nin bu pipeline zincirinin güvenilir artifact merkezi haline gelmesidir.

Build

Pipeline kaynak koddan reproducible image oluşturmalıdır. Base image version pin edilmelidir. Secret değerler build layer içinde kalmamalıdır. Build metadata commit SHA ile ilişkilendirilmelidir. Sonuç image digest'i sonraki adımlara aktarılmalıdır.

Unit Test

Unit test application davranışındaki temel hataları build sonrasında erken yakalar. Başarısız test image'ın promotion sürecini durdurmalıdır. Test sonucu pipeline ID ile saklanabilir. Coverage threshold uygulanabilir. Production artifact yalnızca başarılı testlerden geçmelidir.

SAST

SAST kaynak kod içindeki güvenlik sorunlarını build öncesi veya build sırasında analiz eder. Registry scan ile aynı işi yapmaz. SAST application code riskine odaklanırken image scan final artifact içindeki dependency ve package risklerini inceler. İki kontrol birlikte uygulanmalıdır. Critical SAST bulgusu policy'ye göre pipeline'ı durdurabilir.

Dependency Scan

Dependency scan kullanılan package version'larında bilinen zafiyetleri kontrol eder. Lockfile üzerinden erken uyarı sağlar. Fixed version önerisi geliştiriciye hızlı remediation yolu sunar. Final image scan ile sonuç karşılaştırılabilir. Dependency update automation bu sürece entegre edilebilir.

Container Build

Container build minimal ve immutable artifact üretmelidir. Multi-stage build gereksiz araçları final image'dan çıkarabilir. Build cache performansı iyileştirir ancak güvenilirliği kontrol edilmelidir. Base image digest pin edilebilir. Final image registry'ye push edilmeden önce local veya pipeline scanner ile kontrol edilebilir.

SBOM

SBOM build sırasında üretilirse artifact içeriğiyle doğrudan eşleştirilebilir. Image digest SBOM metadata içine eklenmelidir. Pipeline SBOM yoksa production promotion'ı engelleyebilir. SBOM registry içinde OCI artifact olarak saklanabilir. Security ekibi yeni zafiyetlerde affected image sorgusu yapabilir.

Vulnerability Scan

Vulnerability scan final image'ı analiz etmelidir. Build ortamındaki dependency listesi ile final image içeriği farklı olabilir. Critical bulgular security gate'e gönderilir. Exception varsa expiration date kontrol edilir. Scan sonucu digest ile kayıt altına alınmalıdır.

Image Signing

Signing adımı tüm test ve scan kontrollerinden sonra yapılmalıdır. Böylece imza başarılı pipeline sonucunu temsil eder. Signing credential yalnızca bu stage tarafından erişilebilir olmalıdır. Signature registry'ye push edilir. Production admission policy imzayı doğrular.

Registry Push

Registry push robot account ile yapılmalıdır. Credential pipeline secret store üzerinden alınmalıdır. password-stdin yöntemi tercih edilmelidir. Push sonrası returned digest beklenen digest ile karşılaştırılabilir. Webhook security veya deployment süreçlerini tetikleyebilir.

Deployment

Deployment production ortamında image digest kullanmalıdır. Admission policy approved registry ve signature kontrolü yapabilir. Deployment kaydı pipeline run ile ilişkilendirilmelidir. Failure durumunda önceki digest'e rollback yapılabilir. Image tag değişiklikleri production sonucunu etkilememelidir.

CI/CD Registry Credentials Nasıl Yönetilmeli?

CI/CD credential yönetimi registry güvenliğinin sık zayıf kalan alanlarından biridir. Admin parolasını secret variable içine koymak güvenli bir çözüm değildir. Robot account, project scope ve kısa ömürlü credential tercih edilmelidir. Secret hiçbir zaman pipeline loglarına yazılmamalıdır. Rotation süreci otomatik ve kesintisiz çalışacak biçimde tasarlanmalıdır.

Secret Variable

Secret variable pipeline credential bilgisini source code dışında tutar. Masking özelliği log sızıntısını azaltır. Ancak kullanıcı script ile secret'ı farklı biçimde yazdırabiliyorsa ek koruma gerekir. Secret access yalnızca ilgili pipeline stage ile sınırlandırılmalıdır. Rotation sonrası eski value devre dışı bırakılmalıdır.

Robot Account

Robot account CI/CD için insan kullanıcı hesabından daha doğru seçimdir. Scope yalnızca gerekli project ve işlemle sınırlandırılabilir. Credential expiration tanımlanabilir. Audit log pipeline kimliğini açıkça gösterir. Pipeline başına veya proje başına ayrı account kullanılabilir.

Short-Lived Credentials

Kısa ömürlü credential sızıntı etkisini azaltır. Pipeline başladığında token üretilebilir ve işlem bitince geçerliliğini kaybedebilir. Kalıcı parola yönetimi ihtiyacı azalır. Token scope minimum yetkiyle sınırlandırılmalıdır. Identity integration bu modeli destekliyorsa tercih edilebilir.

Least Privilege

Build pipeline'ın global admin yetkisine ihtiyacı yoktur. Yalnızca kendi repository'sine push yetkisi verilmelidir. Deployment pipeline ise çoğu durumda yalnızca pull yetkisine ihtiyaç duyar. Production promotion için ayrı account kullanılabilir. Permission review düzenli yapılmalıdır.

Password-stdin

Password-stdin credential bilgisinin command line argument olarak görünmesini engeller. Shell history ve process list riskini azaltır. Secret pipeline variable üzerinden stdin'e aktarılabilir. Debug mode secret'ı yazdırmamalıdır. Komut başarısız olduğunda error output kontrol edilmelidir.

Credential Rotation

CI credential düzenli olarak yenilenmelidir. Yeni credential pipeline secret store'a yazılır. Kısa overlap döneminden sonra eski credential revoke edilir. Rotation sonrası test push veya pull yapılmalıdır. Expiration alarmı rotation başarısızlığını erkenden gösterir.

Pipeline Loglarında Secret Sızıntısını Önlemek

Pipeline logları uzun süre saklandığı için secret sızıntısı ciddi risk oluşturur. Shell debug modunda environment variable değerleri yazdırılmamalıdır. Secret masking etkinleştirilmelidir. Token içeren URL kullanılmamalıdır. Log access da least privilege ile sınırlandırılmalıdır.

Development'tan Production'a Image Promotion

Promotion modelinin temel kuralı production için image'ı yeniden build etmemektir. Development ve test aşamalarında doğrulanan aynı digest production'a taşınmalıdır. Rebuild yapılırsa dependency veya base image değişikliği nedeniyle farklı artifact ortaya çıkabilir. Approval gate release kontrolü sağlar. Production repository'de immutable artifact policy uygulanmalıdır.

Rebuild Etmeden Promotion

Promotion mevcut image digest'ini başka project veya repository'ye taşır. Source code tekrar build edilmez. Böylece test edilen artifact ile production artifact aynı kalır. Signature ve SBOM ilişkisi korunur. Audit kaydı promotion event'ini gösterir.

Dev Project

Dev project sık build üreten geliştirme alanıdır. Retention süresi daha kısa olabilir. Developer push yetkisi burada bulunabilir. Scan on push aktif tutulmalıdır. Production geçişi doğrudan developer hesabıyla yapılmamalıdır.

Test Project

Test project otomatik testlerden geçen aday image'ları saklar. QA süreçleri bu artifact'ları kullanabilir. Başarısız release'ler belirli süre sonra temizlenebilir. Digest test sonuçlarıyla ilişkilendirilmelidir. Promotion yalnızca başarılı test sonrası tetiklenmelidir.

Production Project

Production project güçlü RBAC ve immutability policy kullanmalıdır. Yalnızca promotion robot account push yapabilmelidir. Human direct push kapatılmalıdır. Retention daha uzun tutulabilir. Production artifact signature verification'dan geçmelidir.

Digest'in Korunması

Promotion sırasında digest değişmemelidir. Registry copy işlemi sonrası source ve destination digest karşılaştırılabilir. Digest değişiyorsa artifact gerçekten aynı değildir. Deployment metadata destination digest'i kullanmalıdır. Bu kontrol pipeline içinde otomatik yapılabilir.

Approval Gate

Approval gate production geçişinden önce insan veya policy onayı ister. Security scan, test ve change kaydı kontrol edilebilir. Approval kaydı audit için saklanmalıdır. Acil durum bypass süreci ayrıca tanımlanmalıdır. Süresiz bekleyen release'ler otomatik expire edilebilir.

Immutable Production Artifact

Production artifact push sonrasında değiştirilemez hale getirilmelidir. Aynı tag'e farklı digest gönderilmesi engellenmelidir. Yeni release için yeni version oluşturulur. Bu model rollback güvenini artırır. Incident incelemesinde hangi artifact'ın ne zaman kullanıldığı net kalır.

Kubernetes ile Private Registry Entegrasyonu

Kubernetes private registry'den image çekebilmek için network, DNS, TLS ve authentication katmanlarının birlikte çalışması gerekir. imagePullSecrets veya ServiceAccount üzerinden credential verilebilir. Internal CA kullanılıyorsa cluster node runtime trust store güncellenmelidir. Registry hostname node'lardan çözülebilir olmalıdır. ImagePullBackOff hatalarında yalnızca secret'a değil, TLS ve network katmanına da bakılmalıdır.

imagePullSecrets

imagePullSecrets Kubernetes pod'un private registry credential'ına erişmesini sağlar. Secret ilgili namespace içinde bulunmalıdır. Credential read-only pull yetkisine sahip olmalıdır. Secret manifest içinde açık metin olarak source control'e yazılmamalıdır. Rotation süreci otomatik yönetilebilir.

ServiceAccount

ServiceAccount varsayılan imagePullSecret bilgisini taşıyabilir. Aynı namespace içindeki workload'lar otomatik olarak bu secret'ı kullanabilir. Her namespace için ayrı credential tercih edilebilir. ServiceAccount yetkileri gereksiz geniş olmamalıdır. Registry credential ile Kubernetes RBAC ayrı güvenlik katmanlarıdır.

Namespace Bazlı Secret

Namespace bazlı secret tenant veya uygulama isolation sağlar. Bir namespace'in credential'ı başka project registry alanına erişmemelidir. Secret replication otomasyonu kontrollü yapılmalıdır. Production ve development namespace'leri farklı credential kullanabilir. Secret rotation workload kesintisi oluşturmadan test edilmelidir.

Containerd Registry Configuration

Modern Kubernetes node'larında containerd registry configuration önemlidir. Internal CA ve mirror endpoint ayarları runtime seviyesinde yapılabilir. Docker daemon ayarlarının containerd üzerinde etkili olmadığı unutulmamalıdır. Node configuration automation ile dağıtılmalıdır. Cluster upgrade sonrası ayarların korunduğu doğrulanmalıdır.

Internal CA Certificate

Registry internal CA kullanıyorsa Kubernetes node runtime'ın bu CA'ya güvenmesi gerekir. Sadece pod içine certificate eklemek image pull için yeterli değildir. Trust store node seviyesinde yapılandırılmalıdır. CA rotation tüm node'larda koordineli yapılmalıdır. Eksik node güncellemesi bazı pod'larda aralıklı ImagePullBackOff hatası oluşturabilir.

ImagePullBackOff Troubleshooting

ImagePullBackOff birçok farklı nedenden kaynaklanabilir. Önce pod event mesajı okunmalıdır. DNS, TLS, authentication ve image path sırasıyla kontrol edilmelidir. Registry audit log pull isteğinin ulaşıp ulaşmadığını gösterebilir. Yanlış tag veya digest de aynı hatayı oluşturabilir.

Kubernetes'te Yalnızca Kurum İçi Registry Kullanımını Zorunlu Kılmak

Yalnızca dokümantasyonda internal registry kullanın demek yeterli değildir. Admission control ile dış registry kaynakları teknik olarak engellenebilir. Allowed registry policy belirli hostname listesine izin verir. Digest ve signature zorunluluğu aynı enforcement katmanına eklenebilir. Böylece supply chain politikaları deployment anında otomatik uygulanır.

Admission Control

Admission control Kubernetes API'ye gelen workload manifestlerini cluster'a kaydedilmeden önce kontrol eder. Image hostname, tag ve digest bilgisi doğrulanabilir. Policy ihlalinde deployment reddedilir. Audit mode ile önce yalnızca raporlama yapılabilir. Daha sonra enforcement aşamasına geçilebilir.

Kyverno

Kyverno Kubernetes resource policy'lerini YAML tabanlı kurallarla yönetebilir. Allowed registry, digest ve signature kontrolleri uygulanabilir. Policy önce audit modunda test edilmelidir. Yanlış kural production deployment'larını durdurabilir. Policy repository üzerinden version control ile yönetilebilir.

OPA Gatekeeper

OPA Gatekeeper admission policy enforcement için kullanılabilir. Image source veya label kuralları tanımlanabilir. Constraint template yaklaşımı ortak policy'leri yeniden kullanılabilir hale getirir. Audit sonuçları merkezi olarak izlenebilir. Policy değişiklikleri staging cluster'da test edilmelidir.

Allowed Registry Policy

Allowed registry policy yalnızca belirlenmiş internal hostname'lerden image kullanımına izin verir. Public registry direct pull bu şekilde engellenebilir. Exception gereken namespace veya workload için kontrollü süreç kullanılabilir. Wildcard pattern'ler dikkatli tanımlanmalıdır. Policy violation logları security ekibine gönderilebilir.

Digest Zorunluluğu

Digest zorunluluğu mutable tag riskini azaltır. Manifestte image@sha256 formatı beklenir. GitOps pipeline tag'i digest'e resolve edip deployment dosyasını güncelleyebilir. Bu yaklaşım reproducibility sağlar. Rollback hangi artifact'a dönüleceğini netleştirir.

Signed Image Verification

Signed image verification admission sırasında artifact signature kontrolü yapar. Yalnızca trusted signer kabul edilir. Revoked key ile imzalanan image reddedilir. Verification service erişilebilirliği deployment SLO üzerinde etkili olabilir. Failure mode açıkça belirlenmelidir.

Harbor'ı Kubernetes Üzerinde Çalıştırmak

Harbor Kubernetes üzerinde çalıştırıldığında orchestration ve scaling avantajlarından yararlanabilir. Helm Chart installation yönetimini kolaylaştırır. Persistent volume ve object storage seçimi yine kritik konudur. External database ve Redis kullanımı HA tasarımını güçlendirebilir. Ingress ve TLS configuration büyük layer upload yüküne göre ayarlanmalıdır.

Helm Chart

Helm Chart Harbor bileşenlerini Kubernetes üzerinde declarative biçimde kurmayı kolaylaştırır. values dosyası version control altında tutulmalıdır. Secret değerler ayrı secret yönetim sistemiyle sağlanmalıdır. Upgrade öncesinde chart release note okunmalıdır. Staging cluster'da aynı upgrade test edilmelidir.

Persistent Volume

Persistent volume stateful bileşenlerin verisini pod lifecycle'dan bağımsız tutar. StorageClass performansı registry workload'una uygun olmalıdır. ReadWriteMany ihtiyacı kullanılan mimariye göre değerlendirilmelidir. Backup volume snapshot ile sınırlı kalmamalıdır. Database ve object storage tutarlılığı birlikte planlanmalıdır.

Ingress

Ingress registry external URL trafiğini service'lere yönlendirir. Büyük body upload limitleri kontrol edilmelidir. Timeout değerleri uzun layer transferlerine uygun olmalıdır. TLS certificate lifecycle ingress controller üzerinde yönetilebilir. Access log troubleshooting için açık tutulmalıdır.

TLS

Kubernetes üzerindeki Harbor TLS olmadan production'a çıkarılmamalıdır. Certificate secret erişimi sınırlandırılmalıdır. Internal CA kullanılıyorsa tüm client runtime'lara trust dağıtılmalıdır. Automatic renewal sonrasında ingress reload davranışı test edilmelidir. Certificate expiration alarmı kurulmalıdır.

External URL

External URL Harbor'ın kullanıcı ve client tarafından görülen gerçek hostname bilgisidir. Yanlış ayar redirect ve authentication hatası oluşturabilir. URL certificate SAN ile uyumlu olmalıdır. Reverse proxy ve ingress forwarded header ayarları bu değerle eşleşmelidir. Migration sırasında URL değişikliği tüm client'ları etkiler.

External Database

External database Harbor application pod'larından stateful data katmanını ayırır. Managed veya clustered PostgreSQL benzeri bir yapı HA sağlar. Connection security TLS ile korunmalıdır. Backup database seviyesinde düzenli yapılmalıdır. Connection pool ve latency monitoring önemlidir.

External Redis

External Redis job ve cache katmanını pod lifecycle'dan ayırır. HA Redis kullanımı servis sürekliliğini artırabilir. Authentication ve TLS etkinleştirilmelidir. Memory kapasitesi izlenmelidir. Redis failover sırasında job service davranışı test edilmelidir.

Horizontal Scaling

Stateless Harbor bileşenleri replica artırılarak yatay ölçeklenebilir. Ancak database, Redis ve storage darboğazları çözülmeden replica artırmak sınırlı fayda sağlar. CPU ve request latency metric'leri autoscaling için kullanılabilir. Scanner workload ayrı ölçeklenebilir. Load test gerçek eş zamanlı push ve pull senaryosuyla yapılmalıdır.

Harbor High Availability Mimarisi

HA mimarisi registry'nin tek sunucu arızasından etkilenmemesini amaçlar. Multiple application replica, external database, Redis ve shared object storage birlikte tasarlanmalıdır. Load balancer sağlıklı replica'lara trafik yönlendirir. Stateful bileşenlerin HA olmaması tüm yapıyı yine kırılgan bırakır. Gerçek HA düzenli node failure ve database failover testleriyle doğrulanmalıdır.

HA Neden Gereklidir?

Registry deployment süreçlerinin merkezindeyse kesinti doğrudan production operasyonunu etkiler. Yeni pod'lar image çekemeyebilir. CI pipeline push yapamaz. Rollback için gerekli artifact erişilemez hale gelebilir. Bu nedenle iş kritikliği yüksek ortamlarda HA yatırımının değeri büyüktür.

Multiple Core Replica

Core service için birden fazla replica API ve yönetim işlemlerinin sürekliliğini sağlar. Load balancer trafiği sağlıklı pod'lara dağıtır. Session state ve shared dependency yapısı uyumlu olmalıdır. Rolling upgrade sırasında replica'lar sırayla güncellenebilir. Health check yalnızca process durumuna bakmamalıdır.

Multiple Portal Replica

Portal replica sayısının artırılması web erişiminin tek pod'a bağımlı olmasını önler. Stateless yapı ölçeklemeyi kolaylaştırır. Ingress health check çalışmalıdır. Portal kesintisi registry data path'iyle aynı önem seviyesinde olmayabilir. Monitoring bu bileşenleri ayrı SLI olarak takip edebilir.

Multiple Job Service Replica

Job service replica sayısı replication ve scan task throughput'unu artırabilir. Queue paylaşımı doğru yapılandırılmalıdır. Aynı job'ın iki kez çalışmaması önemlidir. Backlog metric'i autoscaling sinyali olabilir. Job failure retry policy kontrollü olmalıdır.

External PostgreSQL HA

External PostgreSQL HA metadata katmanını tek database node arızasından korur. Automatic failover kullanılabilir. Harbor connection string failover endpoint'e bağlanmalıdır. Backup HA'nın yerine geçmez. Database restore testi ayrıca yapılmalıdır.

External Redis

HA Redis cache ve job coordination servisinin sürekliliğini artırır. Sentinel veya clustered mimari değerlendirilebilir. Application connection retry davranışı test edilmelidir. Authentication ve TLS uygulanmalıdır. Redis monitoring genel Harbor dashboard'una dahil edilmelidir.

Shared Object Storage

Multiple registry replica aynı blob verisine erişebilmelidir. Shared object storage bu ihtiyacı karşılar. Durability ve availability registry SLO hedefiyle uyumlu olmalıdır. Object storage credential rotation planlanmalıdır. Cross-region replication DR için ayrıca kullanılabilir.

Load Balancer

Load balancer registry endpoint için tek giriş noktası sağlar. Backend health check uygulama seviyesinde yapılmalıdır. Büyük upload işlemleri için connection timeout ayarlanmalıdır. TLS termination yapılacaksa certificate lifecycle merkezi yönetilir. Load balancer'ın kendisi de redundant olmalıdır.

Registry Kapasite Planlama

Kapasite planlama yalnızca mevcut disk kullanımına bakmak değildir. Günlük build sayısı, ortalama image boyutu, retention süresi ve layer deduplication oranı birlikte değerlendirilmelidir. Scanner cache ve database growth da storage tüketebilir. Backup alanı primary storage'dan ayrı hesaplanmalıdır. En az birkaç aylık büyüme için capacity headroom bırakılmalıdır.

Günlük Image Build Sayısı

Günlük build sayısı registry growth rate için temel metriktir. CI sisteminden gerçek veri alınmalıdır. Başarısız build image'larının registry'ye push edilip edilmediği kontrol edilmelidir. Development ekipleri build hacminin büyük kısmını oluşturabilir. Retention policy bu yüksek churn alanlarında daha agresif olabilir.

Ortalama Image Boyutu

Ortalama image boyutu kapasite tahmininde kullanılır. Ancak logical image size ile gerçek incremental storage artışı aynı değildir. Shared layer'lar deduplication sağlar. Base image değişiklikleri growth rate'i yükseltebilir. Monitoring gerçek günlük storage artışını göstermelidir.

Retention Süresi

Retention süresi storage büyüklüğünü doğrudan etkiler. Development için kısa, production için uzun süre uygulanabilir. Compliance gereksinimi bazı artifact'ların yıllarca saklanmasını gerektirebilir. Archived artifact ayrı düşük maliyetli storage'a taşınabilir. Policy maliyet ve rollback ihtiyacı arasında denge kurmalıdır.

Layer Deduplication

Deduplication aynı layer'ın birden fazla image tarafından paylaşılmasını sağlar. Ortak base image standardı bu oranı artırabilir. Dockerfile değişiklik sırası cache verimliliğini etkiler. Gerçek dedup ratio zaman içinde ölçülmelidir. Capacity model teorik varsayım yerine gerçek storage metriği kullanmalıdır.

Growth Rate

Growth rate günlük veya haftalık storage artış hızını gösterir. Trend üzerinden disk doluluk tarihi tahmin edilebilir. Ani artış yanlış pipeline veya retention sorununun göstergesi olabilir. Capacity alarmı yüzde kullanımın yanında tahmini kalan gün sayısına göre de üretilebilir. Bu yaklaşım operasyon ekibine daha erken aksiyon süresi verir.

Scan Storage

Vulnerability scan sonuçları ve cache verileri ek storage tüketebilir. Büyük registry'lerde bu veri göz ardı edilmemelidir. Scanner retention ayarları incelenmelidir. Database büyümesi monitoring ile takip edilmelidir. Backup boyutuna bu metadata da dahil edilir.

Backup Storage

Backup storage primary kapasitenin birden fazla kopyasını gerektirebilir. Full ve incremental stratejisi toplam alanı etkiler. Immutable backup ek kopya ihtiyacı oluşturabilir. Retention süresi compliance politikasına göre belirlenir. Off-site transfer bandwidth de planlamaya dahil edilmelidir.

Capacity Headroom

Registry sürekli yüzde doksan beş disk doluluğunda çalıştırılmamalıdır. Ani release veya replication işleri beklenmeyen büyüme oluşturabilir. Yüzde yirmi veya daha fazla headroom güvenli çalışma alanı sağlar. Gerçek oran işletim politikasına göre belirlenir. Storage expansion süresi de hesaba katılmalıdır.

Registry Performans Optimizasyonu

Registry performansı network, storage, database ve proxy katmanlarının toplam sonucudur. Yalnızca CPU artırmak çoğu sorunu çözmez. Büyük image pull trafiğinde storage latency ve bandwidth daha önemli hale gelebilir. Database connection pool portal ve API performansını etkileyebilir. Geographical replication uzak lokasyonlarda pull süresini azaltabilir.

Network Bandwidth

Image transferleri yüksek bandwidth tüketebilir. CI ve Kubernetes trafiği aynı anda yoğunlaşabilir. Network interface ve switch kapasitesi izlenmelidir. Regional cache WAN kullanımını azaltabilir. Pull latency ile bandwidth metriği birlikte değerlendirilmelidir.

Storage IOPS

Storage IOPS çok sayıda küçük object erişiminde önemlidir. Büyük sequential throughput tek başına yeterli olmayabilir. Registry workload gerçek test ile ölçülmelidir. NFS veya block storage davranışı farklıdır. Queue depth ve latency metric'leri bottleneck analizi için kullanılabilir.

Object Storage Latency

Object storage request latency her layer transferine ek süre katabilir. Registry ile storage aynı network bölgesinde tutulmalıdır. Connection pooling performansı iyileştirebilir. P95 ve P99 latency değerleri izlenmelidir. Ani latency artışı cloud veya network problemi gösterebilir.

Database Connection Pool

Yetersiz connection pool yoğun portal ve API trafiğinde bekleme oluşturabilir. Çok yüksek pool ise database resource tüketimini artırabilir. Gerçek concurrency ölçülmelidir. Database slow query logları incelenebilir. Pool değeri load test sonucu üzerinden ayarlanmalıdır.

Redis

Redis performansı job ve cache işlemlerini etkileyebilir. Memory pressure latency artışına yol açabilir. Connection count ve CPU izlenmelidir. Network latency application ile Redis arasında düşük olmalıdır. Failover sırasında geçici performans etkisi test edilmelidir.

Concurrent Push/Pull

Eş zamanlı push ve pull workload'u production load testlerinin temel parçası olmalıdır. Tek kullanıcı testi gerçek bottleneck'i göstermez. CI release saatlerinde yoğun push oluşabilir. Kubernetes scale-out aynı anda yoğun pull üretebilir. Load balancer ve storage bu concurrency seviyesine göre boyutlandırılmalıdır.

Reverse Proxy

Reverse proxy yanlış timeout veya buffering ayarı performansı etkileyebilir. Connection limitleri kontrol edilmelidir. TLS termination CPU kullanımı oluşturabilir. Large upload için body size limitleri uygun olmalıdır. Proxy metric'leri backend metric'leriyle birlikte analiz edilmelidir.

Geographical Replication

Uzak bölgelerde regional registry kullanmak WAN latency sorununu azaltabilir. Production artifact'ları event-based replication ile taşınabilir. Development image'larının tamamını replicate etmek gereksiz maliyet oluşturabilir. Replication lag SLO ile izlenmelidir. Network partition sonrası sync davranışı test edilmelidir.

Registry Monitoring

Monitoring registry'nin yalnızca çalışıp çalışmadığını değil, ne kadar iyi çalıştığını göstermelidir. Push rate, pull rate, error rate ve request latency temel metriklerdir. Storage kapasitesi, scan queue ve replication failure operasyon riskini erken gösterir. Prometheus metric toplayabilir, Grafana dashboard görselleştirme sağlayabilir. Alarm kuralları gerçek kullanıcı etkisine göre tasarlanmalıdır.

Prometheus Metrics

Prometheus registry ve platform servislerinden metric toplayabilir. Request count, latency ve error rate izlenebilir. Custom exporter certificate expiration gibi ek veriler sağlayabilir. Label cardinality kontrol edilmelidir. Metric retention kapasite planına göre belirlenmelidir.

Grafana Dashboard

Grafana dashboard operasyon ekibine registry sağlığını tek ekranda gösterir. Push ve pull trendleri görülebilir. Storage growth ve scan backlog birlikte izlenebilir. Dashboard yalnızca görsel rapor olmamalı, incident sırasında karar vermeyi kolaylaştırmalıdır. Kritik metric'ler üst bölümde yer almalıdır.

Push Rate

Push rate CI/CD aktivitesini gösterir. Ani artış release dönemi veya yanlış loop yapan pipeline nedeniyle oluşabilir. Normal baseline belirlenmelidir. Error rate ile birlikte izlenmelidir. Capacity planı günlük push trendinden yararlanabilir.

Pull Rate

Pull rate Kubernetes deployment ve build aktivitelerini gösterir. Autoscaling sırasında ani spike görülebilir. Regional cache ihtiyacı bu metric üzerinden değerlendirilebilir. Failed pull oranı ayrıca takip edilmelidir. Public proxy cache hit oranıyla ilişkilendirilebilir.

Error Rate

Error rate kullanıcı etkisini hızlı gösteren temel SLI'lardan biridir. 4xx ve 5xx hataları ayrı değerlendirilmelidir. 401 artışı authentication problemi gösterebilir. 5xx artışı application veya storage sorunu olabilir. Alarm yalnızca toplam request sayısıyla normalize edilmiş oran üzerinden üretilmelidir.

Request Latency

Request latency ortalama yerine P95 ve P99 değerlerle takip edilmelidir. Storage veya network slowdown tail latency'yi artırabilir. Push ve pull endpoint'leri ayrı ölçülebilir. Kullanıcı deneyimi büyük image transfer süresiyle birlikte değerlendirilmelidir. Latency SLO belirlenebilir.

Storage Kullanımı

Storage usage yüzde doluluk ve büyüme hızıyla birlikte izlenmelidir. Yalnızca yüzde doksana geldiğinde alarm üretmek geç olabilir. Tahmini dolma tarihi hesaplanabilir. Retention sonrası alan düşüşü kontrol edilmelidir. Garbage collection etkisi ayrı metrik olarak raporlanabilir.

Scan Queue

Scan queue yeni image'ların ne kadar sürede güvenlik sonucu aldığını gösterir. Backlog büyüyorsa scanner kapasitesi yetersiz olabilir. Production promotion scan tamamlanmasını bekliyorsa release gecikir. Autoscaling veya worker artırımı değerlendirilebilir. Queue time SLO olarak tanımlanabilir.

Replication Failure

Replication failure DR veya regional registry güncelliğini etkiler. Tek hata kısa süreli network problemi olabilir. Sürekli failure alarm üretmelidir. Hangi repository ve digest'in taşınamadığı loglarda görülmelidir. Retry başarısı monitoring ile doğrulanmalıdır.

Job Queue

Job queue replication, scan ve maintenance görevlerinin bekleme durumunu gösterir. Queue sürekli büyüyorsa worker kapasitesi veya dependency problemi olabilir. Eski stuck job'lar temizlenmelidir. Job failure nedeni görünür olmalıdır. Dashboard backlog trendini göstermelidir.

Registry SLI ve SLO'ları

SLI ölçülen hizmet göstergesidir, SLO ise hedeflenen hizmet seviyesini tanımlar. Registry için availability kadar push ve pull başarısı da önemlidir. P95 pull latency kullanıcı deneyimini daha gerçekçi gösterir. Scan completion ve replication lag security ile DR süreçlerinin kalitesini ölçer. Storage threshold da operasyonel SLO olarak takip edilebilir.

Availability

Availability registry endpoint'in belirli süre boyunca erişilebilir olma oranıdır. Sadece portal değil data path ayrı ölçülebilir. Planlı bakım politikaya göre hesaplamaya dahil edilebilir. Çok yüksek availability hedefi HA maliyetini artırır. İş gereksinimiyle dengeli hedef belirlenmelidir.

Push Success Rate

Push success rate CI pipeline'ların registry'ye artifact gönderebilme başarısını gösterir. Authentication hataları ve storage sorunları oranı düşürebilir. Başarısız denemeler repository bazında incelenebilir. SLO ihlalinde otomatik incident açılabilir. Release saatlerinde ayrıca izlenmelidir.

Pull Success Rate

Pull success rate deployment sürekliliği için kritik metriktir. Kubernetes node'larının image çekememesi doğrudan workload başlangıcını etkiler. 401 ve 404 hataları yanlış configuration nedeniyle oluşabilir. 5xx storage veya registry problemi gösterebilir. Production cluster pull oranı ayrı izlenebilir.

P95 Pull Latency

P95 pull latency isteklerin yüzde doksan beşinin hangi süre altında tamamlandığını gösterir. Ortalama değer nadir ama ciddi yavaşlamaları gizleyebilir. Regional registry kararında bu metric değerlidir. Image boyutuna göre normalize edilmiş ölçüm de kullanılabilir. Uzun trendler capacity problemine işaret edebilir.

Vulnerability Scan Completion

Scan completion yeni image'ın belirli sürede analiz edilme oranını ölçer. Security gate buna bağlıysa yüksek önem taşır. Scanner queue veya database update sorunu completion süresini uzatabilir. SLO örneğin image'ların büyük bölümünün belirli dakika içinde taranmasını hedefleyebilir. Gerçek değer workload hacmine göre belirlenmelidir.

Replication Lag

Replication lag source ve target registry arasındaki artifact güncellik farkını gösterir. DR ortamı çok geride kalıyorsa RPO hedefi sağlanamaz. Event-based replication için dakika seviyesinde hedef konabilir. Büyük release sırasında geçici artış kabul edilebilir. Uzun süreli ihlal alarm üretmelidir.

Storage Capacity Threshold

Storage threshold kritik doluluk seviyesine yaklaşmadan önce uyarı üretmelidir. Warning ve critical seviyeler ayrı tanımlanabilir. Growth trend üzerinden tahmini dolma süresi daha anlamlı olabilir. Retention ve expansion aksiyonu runbook içinde belirtilmelidir. Backup storage için de ayrı threshold oluşturulmalıdır.

Registry Logging ve Audit

Registry audit kayıtları olay incelemesi ve compliance açısından çok değerlidir. Login, push, pull, delete ve permission change gibi işlemler kaydedilmelidir. Logların yalnızca registry sunucusunda tutulması yeterli değildir. Merkezi SIEM sistemine gönderilmeleri tavsiye edilir. Audit log retention süresi kurumun güvenlik ve yasal politikalarına göre belirlenmelidir.

User Login

Login olayları başarılı ve başarısız girişleri göstermelidir. Çok sayıda başarısız deneme brute force işareti olabilir. Admin login ayrıca alarm üretebilir. Source IP ve identity bilgisi tutulmalıdır. Credential veya token değeri loglarda bulunmamalıdır.

Image Push

Image push kaydı hangi kullanıcının hangi repository ve digest'e artifact gönderdiğini göstermelidir. Production push özellikle yakından izlenmelidir. İnsan kullanıcıdan production push gelmesi policy ihlali olabilir. CI robot identity bilgisi audit kaydında görünmelidir. Push sonrası scanner ve signature event'leri ilişkilendirilebilir.

Image Pull

Pull logları hangi cluster veya kullanıcının hangi image'ı kullandığını anlamaya yardımcı olabilir. Çok yüksek hacim nedeniyle her pull logunu uzun süre saklamak maliyetli olabilir. Production project için daha uzun retention uygulanabilir. Anormal pull trafiği credential sızıntısı gösterebilir. SIEM correlation kuralları kullanılabilir.

Image Delete

Delete olayı kritik audit event'tir. Hangi artifact ve digest'in kim tarafından silindiği kayıt altına alınmalıdır. Production delete işlemi onay gerektirebilir. Beklenmeyen silme alarm üretmelidir. Incident durumunda backup ve replication kopyaları kontrol edilmelidir.

Permission Change

Permission change kullanıcıların erişim seviyesini doğrudan etkiler. Admin veya project admin role ataması security ekibine bildirilebilir. Grup mapping değişiklikleri de audit kapsamına alınmalıdır. Geçici yetki expiration ile verilmelidir. Düzenli access review audit loglardan doğrulanabilir.

Policy Change

Retention, vulnerability veya immutability policy değişikliği önemli etki yaratabilir. Değişikliği yapan kullanıcı ve timestamp kaydedilmelidir. Production policy değişiklikleri approval sürecinden geçebilir. Eski ve yeni değerlerin kaydı troubleshooting için faydalıdır. SIEM kritik policy disable olayında alarm üretebilir.

Audit Log Retention

Audit log retention güvenlik soruşturması süresiyle uyumlu olmalıdır. Çok kısa retention geçmiş olayların analizini imkansız hale getirir. Çok uzun retention ise storage ve privacy maliyeti yaratabilir. Production ve admin event'leri için farklı süre düşünülebilir. Logların değiştirilmesini zorlaştıran immutable storage kullanılabilir.

SIEM Entegrasyonu

SIEM registry loglarını diğer güvenlik event'leriyle ilişkilendirir. Credential compromise durumunda login, push ve Kubernetes deployment event'leri aynı timeline üzerinde görülebilir. Alert rule anormal admin activity tespit edebilir. Log formatı parse edilebilir ve timestamp senkron olmalıdır. NTP time sync olay korelasyonu için önemlidir.

Registry Webhook Kullanımı

Webhook registry içinde gerçekleşen event'leri diğer sistemlere gerçek zamanlı olarak iletmeyi sağlar. Push sonrası CI/CD veya security otomasyonu tetiklenebilir. Scan completed event sonucunda notification gönderilebilir. Delete olayı SIEM veya incident kanalına aktarılabilir. Webhook endpoint authentication ve retry davranışı güvenli biçimde yapılandırılmalıdır.

Image Push Event

Push event yeni artifact geldiğini bildirir. Security scanner veya SBOM kontrolü tetiklenebilir. Payload içinde repository, tag ve digest bilgisi bulunmalıdır. Webhook receiver event'i idempotent biçimde işleyebilmelidir. Başarısız delivery retry edilmelidir.

Image Pull Event

Pull event artifact kullanımını izlemek için kullanılabilir. Çok yoğun sistemlerde event sayısı yüksek olabilir. Security analytics beklenmeyen source network'leri tespit edebilir. Usage verisi retention kararlarında yardımcı olabilir. Privacy ve log retention politikası dikkate alınmalıdır.

Scan Completed Event

Scan completed event security gate veya bildirim süreçlerini tetikleyebilir. Critical bulgu varsa release pipeline durdurulabilir. Sonuç artifact digest ile ilişkilendirilmelidir. False positive ve exception bilgisi security platformuna aktarılabilir. Event başarısız olursa polling fallback düşünülebilir.

Image Deleted Event

Delete event lifecycle ve audit automation için önemlidir. Production artifact silindiğinde alarm oluşturulabilir. Storage cleanup workflow daha sonra tetiklenebilir. Event payload deleted digest bilgisini içermelidir. Backup retention sistemi bu olayı hemen takip ederek kopyayı silmemelidir.

CI/CD Trigger

Registry webhook belirli artifact geldiğinde downstream deployment pipeline başlatabilir. Ancak production deployment yalnızca push event'e güvenmemelidir. Security scan, signing ve approval kontrolü tamamlanmalıdır. Event duplicate gelebileceği için pipeline idempotent olmalıdır. Digest üzerinden aynı artifact ikinci kez deploy edilmesi kontrol edilebilir.

Security Automation

Webhook security platformuna artifact bilgisi göndererek ek scan veya policy kontrolü başlatabilir. Critical bulgu SIEM alarmına dönüşebilir. Signer veya provenance kontrolü yapılabilir. Automation başarısız olduğunda artifact otomatik approved kabul edilmemelidir. Fail-closed veya fail-open davranışı risk politikasına göre belirlenmelidir.

Notification

Notification ekiplerin registry olaylarından haberdar olmasını sağlar. Her push için mesaj göndermek gürültü oluşturabilir. Critical vulnerability, replication failure veya production delete gibi olaylar öncelikli olmalıdır. Bildirim içinde repository ve digest bilgisi bulunabilir. Secret veya credential bilgisi mesaj içeriğine eklenmemelidir.

Backup Stratejisi

Registry backup stratejisi yalnızca image blob dosyalarını kopyalamak değildir. Database, configuration, certificates, secrets ve signing metadata birlikte değerlendirilmelidir. Backup RPO hedefi iş gereksinimine göre belirlenir. Off-site ve immutable kopyalar ek koruma sağlar. En önemli kural backup'ın düzenli restore testinden geçirilmesidir.

Neler Yedeklenmeli?

Backup kapsamı platform architecture dokümanından çıkarılmalıdır. Blob storage temel veri katmanıdır. Database kullanıcı, project ve policy metadata'sını içerir. Configuration ve certificates yeniden kurulum süresini ciddi biçimde etkiler. Secrets ve signing metadata ise yüksek güvenlikli backup yöntemi gerektirir.

Registry Blob Storage

Blob storage image layer ve manifest verisinin büyük bölümünü içerir. Backup kapasitesi yüksek olabilir. Incremental veya object versioning yöntemleri değerlendirilebilir. Consistency için application write davranışı dikkate alınmalıdır. Restore sonrası digest doğrulaması yapılmalıdır.

Harbor Database

Database project, user ve policy metadata bilgilerini saklar. Düzenli database dump veya native backup yöntemi kullanılabilir. Backup şifrelenmelidir. Restore prosedürü platform sürümüyle uyumlu olmalıdır. DR testinde database ile blob storage birlikte doğrulanmalıdır.

Configuration

Configuration dosyaları registry'nin nasıl çalıştığını belirler. Version control altında tutulan configuration yeniden kurulum süresini azaltır. Secret içerikleri ayrı tutulmalıdır. Upgrade sonrası eski configuration compatibility kontrol edilmelidir. Backup kopyasında değişiklik tarihi bulunmalıdır.

Certificates

Certificate ve private key kaybı servis erişimini etkileyebilir. Private key backup yüksek güvenlikli ve şifreli tutulmalıdır. Internal CA certificate ayrıca korunmalıdır. Restore sonrasında hostname ve chain doğrulanmalıdır. Expired certificate backup'tan geri yüklenmemelidir.

Secrets

Secrets database password, robot credential veya encryption key gibi kritik değerleri içerebilir. Plain text backup kabul edilmemelidir. Secret vault export yöntemi kullanılabilir. Erişim yalnızca sınırlı recovery ekibine verilmelidir. Restore sonrası bazı secrets rotation gerektirebilir.

Signing Metadata

Signature ve provenance metadata artifact trust zincirinin parçasıdır. Image blob restore edilip signature kaybolursa production verification başarısız olabilir. OCI artifact backup kapsamına dahil edilmelidir. Signing private key ise ayrı ve daha yüksek güvenlik seviyesinde korunmalıdır. Restore sonrası verification testi yapılmalıdır.

Full Backup

Full backup belirli anda tüm gerekli registry verisinin kopyasını alır. Restore işlemi daha basit olabilir. Ancak büyük registry'lerde süre ve storage maliyeti artar. Haftalık full ve günlük incremental yaklaşım kullanılabilir. Backup süresi production performansını etkilememelidir.

Incremental Backup

Incremental backup yalnızca değişen veriyi saklar. Büyük blob storage için daha verimli olabilir. Restore sırasında birden fazla backup zinciri gerekebilir. Zincirin herhangi bir halkası bozuksa recovery etkilenir. Düzenli full restore testi yapılmalıdır.

Off-Site Backup

Off-site backup primary veri merkezi kaybına karşı koruma sağlar. İkinci lokasyon veya bağımsız storage kullanılabilir. Network transfer şifrelenmelidir. Backup location erişimi production account'lardan ayrılmalıdır. RPO hedefi transfer sıklığını belirler.

Immutable Backup

Immutable backup belirli süre boyunca backup verisinin değiştirilememesini sağlar. Credential compromise veya ransomware durumunda güçlü koruma sunar. Retention süresi business ve compliance ihtiyacına göre belirlenmelidir. Recovery hesabı production admin hesabından ayrı olmalıdır. Düzenli restore testi yine gereklidir.

Restore ve Disaster Recovery

Backup alınmış olması tek başına recovery garantisi değildir. Restore prosedürü database, blob storage, configuration ve certificate adımlarını açık sırayla tanımlamalıdır. RPO kabul edilen veri kaybını, RTO hizmetin geri dönüş süresini ifade eder. DNS failover ve client trust davranışı da test edilmelidir. Restore drill gerçek süreyi ölçerek planın uygulanabilirliğini gösterir.

RPO Nedir?

RPO kabul edilebilir maksimum veri kaybı süresini ifade eder. Örneğin bir saatlik RPO son bir saatlik registry değişikliğinin kaybolabileceği anlamına gelir. Backup ve replication sıklığı bu hedefe göre belirlenir. Production release hacmi yüksekse daha kısa RPO gerekebilir. Business owner hedefi onaylamalıdır.

RTO Nedir?

RTO registry hizmetinin kabul edilen maksimum geri dönüş süresidir. DNS, infrastructure provisioning ve restore süresi birlikte hesaba katılır. Kağıt üzerindeki tahmin yerine gerçek drill sonucu kullanılmalıdır. Çok düşük RTO ek altyapı maliyeti yaratır. İş gereksinimiyle dengeli hedef belirlenmelidir.

Database Restore

Database restore doğru platform sürümü üzerine yapılmalıdır. Backup integrity önceden kontrol edilmelidir. Restore sonrasında migration gereksinimi olabilir. Kullanıcı ve project metadata'sı doğrulanmalıdır. Blob storage ile manifest tutarlılığı test edilmelidir.

Blob Storage Restore

Blob storage restore image layer verisini geri getirir. Büyük veri hacmi nedeniyle en uzun recovery adımı olabilir. Parallel transfer performansı test edilmelidir. Restore sonrası random sample digest kontrolü yapılabilir. Missing blob hataları registry loglarında aranmalıdır.

Configuration Restore

Configuration restore application'ın doğru hostname, storage ve authentication ayarlarıyla başlamasını sağlar. Environment-specific değerler kontrol edilmelidir. DR site farklı network kullanıyorsa endpoint değişiklikleri gerekebilir. Secret referansları yeniden bağlanmalıdır. Service startup öncesi configuration validation yapılmalıdır.

Certificate Restore

Certificate restore registry client bağlantısı için kritiktir. DR hostname aynıysa mevcut certificate kullanılabilir. Farklı hostname varsa yeni certificate gerekebilir. Private key backup erişimi sınırlı olmalıdır. Client trust store'un yeni chain'e güvenmesi doğrulanmalıdır.

DNS Failover

DNS failover kullanıcı trafiğini recovery endpoint'ine yönlendirir. TTL değeri değişimin yayılma süresini etkiler. Internal DNS cache davranışı test edilmelidir. Failover sonrası TLS hostname uyumu kontrol edilmelidir. Geri dönüş süreci de runbook içinde bulunmalıdır.

Restore Testi

Restore testi backup'ın gerçekten kullanılabilir olduğunu doğrular. İzole environment içinde yapılabilir. Süre ölçülerek gerçek RTO elde edilir. Eksik configuration veya secret gibi sorunlar production incident öncesinde ortaya çıkar. Test sonucu aksiyonlarla birlikte kaydedilmelidir.

Backup Varsa Disaster Recovery Hazır mıdır?

Hayır, backup yalnızca disaster recovery'nin bir parçasıdır. Restore edilmemiş backup dosyasının sağlam olup olmadığı bilinmez. Runbook, sorumlu ekip, DNS geçişi ve RTO ölçümü olmadan recovery planı eksik kalır. Veri tutarlılığı image blob ile database arasında doğrulanmalıdır. Düzenli restore drill gerçek hazırlık seviyesini gösterir.

Restore Edilmemiş Backup'ın Riski

Backup job başarılı görünebilir ancak dosya bozuk olabilir. Encryption key kayıp olabilir. Database dump yanlış sürümle uyumsuz çıkabilir. Blob storage eksik object içerebilir. Bu sorunlar yalnızca gerçek restore testiyle ortaya çıkar.

Düzenli Restore Drill

Restore drill belirli aralıklarla recovery prosedürünü uygular. Ekip runbook adımlarını pratik eder. Gerçek RTO ölçülür. Otomasyon eksikleri görünür hale gelir. Kritik registry'lerde yılda bir kez yerine daha sık test düşünülebilir.

Veri Tutarlılığı

Database metadata ile blob storage aynı zamansal noktaya yakın olmalıdır. Aksi durumda manifest kaydı olup blob eksik olabilir. Snapshot veya coordinated backup yöntemi kullanılabilir. Restore sonrası sample pull testi yapılmalıdır. Registry consistency araçları varsa kullanılabilir.

Runbook

Runbook recovery adımlarını sıralı biçimde açıklar. Hangi backup'ın seçileceği, kimin erişim sağlayacağı ve DNS değişikliğinin nasıl yapılacağı yazılmalıdır. Komutlar mümkün olduğunca otomatikleştirilmelidir. Runbook version control altında tutulabilir. Her drill sonrası güncellenmelidir.

Sorumlu Ekip

DR sırasında kimin karar vereceği önceden belirlenmelidir. Infrastructure, security ve application ekiplerinin sorumlulukları ayrılmalıdır. On-call iletişim bilgisi güncel tutulmalıdır. Yetki eksikliği recovery süresini uzatmamalıdır. Drill sırasında sorumluluklar gerçek senaryo gibi uygulanmalıdır.

Ölçülen RTO

RTO tahmini ile ölçülen RTO farklı olabilir. Restore transferi beklenenden uzun sürebilir. DNS cache propagation ek gecikme yaratabilir. Gerçek drill süresi iş hedefiyle karşılaştırılmalıdır. Hedef aşılıyorsa otomasyon veya warm standby yatırımı değerlendirilebilir.

Registry Upgrade ve Migration

Registry upgrade işlemi backup ve rollback planı olmadan yapılmamalıdır. Release note ile breaking change ve deprecated configuration bilgileri incelenmelidir. Database migration gereksinimi staging ortamında test edilmelidir. Downtime gerekiyorsa CI/CD ekipleri önceden bilgilendirilmelidir. Upgrade sonrası push, pull, scan ve authentication testleri tamamlanmalıdır.

Upgrade Öncesi Backup

Upgrade öncesi güncel database ve configuration backup alınmalıdır. Blob storage backup veya snapshot durumu kontrol edilmelidir. Restore prosedürü uygulanabilir olmalıdır. Backup timestamp kayıt altına alınmalıdır. Upgrade başarısız olursa rollback planı bu kopyayı kullanabilir.

Release Note İncelemesi

Release note deprecated ayar ve schema değişikliklerini gösterir. Security fix'ler ayrıca değerlendirilmelidir. Major version geçişlerinde migration adımları daha kapsamlı olabilir. Kullanılan eklenti ve scanner uyumluluğu kontrol edilmelidir. Staging test planı release note bilgilerine göre hazırlanmalıdır.

Configuration Migration

Yeni sürüm bazı configuration key'lerini değiştirebilir. Eski dosya doğrudan kullanılmadan önce validation yapılmalıdır. Secret ve endpoint değerleri kontrol edilmelidir. Version control diff incelemesi faydalıdır. Rollback için eski configuration kopyası saklanmalıdır.

Database Migration

Database schema upgrade uygulama sürümüyle uyumlu olmalıdır. Migration süresi büyük database'lerde uzun olabilir. Staging ortamında production benzeri veriyle süre ölçülmelidir. Migration ortasında rollback desteklenmeyebilir. Backup bu nedenle kritik öneme sahiptir.

Staging Testi

Staging upgrade production adımlarını mümkün olduğunca aynı şekilde tekrar etmelidir. Push, pull ve scan testleri yapılmalıdır. SSO ve robot account authentication doğrulanmalıdır. Performance regression ölçülebilir. Başarılı sonuç olmadan production upgrade başlatılmamalıdır.

Downtime Planı

Downtime gerekiyor ise en düşük deployment trafiği olan dönem seçilebilir. CI/CD pipeline'lar geçici olarak durdurulabilir. Maintenance page veya clear error mesajı kullanılabilir. Beklenen süre yerine adım bazlı completion criteria belirlenmelidir. İşlem sonrası servis doğrulaması yapılmalıdır.

Rollback Planı

Rollback yalnızca eski container image'ı çalıştırmak değildir. Database schema downgrade gereksinimi olabilir. Configuration ve blob compatibility kontrol edilmelidir. Hangi noktada rollback kararı verileceği önceden belirlenmelidir. Plan staging ortamında mümkünse test edilmelidir.

Docker Registry v2'den Distribution v3'e Geçiş

Major registry sürüm geçişleri mevcut deployment'ın ayrıntılı envanterini gerektirir. Configuration, storage driver, authentication ve reverse proxy ayarları kontrol edilmelidir. Staging migration gerçek veri örneğiyle test edilmelidir. Push ve pull compatibility doğrulanmalıdır. Rollback için eski sistem belirli süre read-only biçimde tutulabilir.

Mevcut Deployment'ı Envanterlemek

Önce mevcut registry sürümü, configuration ve storage backend kaydedilmelidir. Authentication ve TLS mimarisi dokümante edilmelidir. Repository sayısı ve storage büyüklüğü ölçülmelidir. Custom middleware veya proxy ayarları listelenmelidir. Bu envanter migration risklerini belirlemeye yardımcı olur.

Configuration Compatibility

Major sürümde bazı configuration seçenekleri değişebilir. Deprecated key'ler release note üzerinden bulunmalıdır. Yeni format staging ortamında test edilmelidir. Default davranışların değişip değişmediği kontrol edilmelidir. Configuration diff review yapılmalıdır.

Storage Compatibility

Existing blob storage yeni sürüm tarafından okunabilir olmalıdır. Migration sırasında format değişikliği gerekiyorsa backup alınmalıdır. Sample repository pull testi yapılabilir. Garbage collection davranışı değişmiş olabilir. Storage permission ve driver compatibility doğrulanmalıdır.

Authentication

Token veya basic authentication davranışı yeni sürümde test edilmelidir. Reverse proxy challenge header'ları kontrol edilmelidir. Docker client eski ve yeni sürümlerle denenebilir. Robot account entegrasyonu etkilenmemelidir. 401 ve 403 hata davranışları staging ortamında incelenmelidir.

Staging Migration

Production benzeri data subset staging ortamına kopyalanmalıdır. Upgrade gerçek adımlarla uygulanmalıdır. Push, pull, delete ve GC testleri yapılmalıdır. Monitoring metric formatı değişmişse dashboard güncellenmelidir. Başarılı test sonrası production runbook oluşturulur.

Push/Pull Testleri

Migration sonrası farklı image boyutlarıyla push ve pull yapılmalıdır. Multi-architecture manifest test edilmelidir. Authentication ve TLS hatası olmadığı doğrulanmalıdır. Digest source system ile karşılaştırılabilir. CI ve Kubernetes gerçek client olarak kullanılmalıdır.

Rollback

Rollback kararı belirli hata kriterlerine bağlanmalıdır. Eski registry storage'a yeniden yazma yapılmamışsa dönüş daha kolay olabilir. DNS geri çevrilebilir. Database migration varsa restore gerekebilir. Rollback sonrası artifact consistency kontrol edilmelidir.

Certificate Lifecycle Yönetimi

Certificate lifecycle yalnızca ilk TLS kurulumu değildir. Expiration monitoring, automatic renewal, CA rotation ve revocation süreçleri birlikte yönetilmelidir. Registry onlarca veya yüzlerce client tarafından kullanıldığında trust store güncellemesi ciddi operasyon konusu olur. Süresi dolmuş certificate CI/CD ve Kubernetes deployment'larını aynı anda durdurabilir. Bu nedenle certificate süreçleri otomasyona ve alarma bağlanmalıdır.

Certificate Expiration Monitoring

Certificate expiry tarihi monitoring sistemi tarafından düzenli kontrol edilmelidir. Warning alarmı haftalar öncesinden verilmelidir. Intermediate CA süresi de takip edilmelidir. Dashboard kalan gün sayısını gösterebilir. Alarm yalnızca email yerine on-call sistemine entegre edilebilir.

Automatic Renewal

Automatic renewal insan unutkanlığını azaltır. Ancak certificate yenilenmesi servis reload işlemini de gerektirebilir. Yeni chain istemciler tarafından güvenilir olmalıdır. Renewal sonrası otomatik health check çalıştırılabilir. Hata durumunda eski certificate'a geri dönme mekanizması bulunmalıdır.

Internal CA Rotation

Internal CA rotation tüm client trust store'ları etkileyebilir. Geçiş döneminde eski ve yeni CA birlikte dağıtılabilir. Registry certificate yeni CA ile yenilenir. Tüm istemciler doğrulandıktan sonra eski CA kaldırılır. Süreç aşamalı yapılmalıdır.

Client Trust Store Güncellemesi

Docker ve containerd istemcilerinin trust store yapısı farklı olabilir. Configuration management sistemiyle CA dağıtımı otomatik yapılmalıdır. Node'ların bir kısmının güncellenmemesi aralıklı image pull hataları oluşturabilir. Deployment sonrası coverage raporu çıkarılabilir. CA version bilgisi node inventory içinde tutulabilir.

Certificate Revocation

Private key compromise durumunda certificate yalnızca yenilenmemeli, revoke edilmelidir. CRL veya uygun revocation mekanizması kullanılabilir. Client sistemlerin revocation kontrolü yapıp yapmadığı doğrulanmalıdır. Yeni certificate hızlı biçimde dağıtılmalıdır. Olay audit kaydına alınmalıdır.

Expired Certificate Incident

Expired certificate registry erişimini aniden durdurabilir. İlk adım yeni geçerli certificate yüklemektir. Chain ve private key eşleşmesi kontrol edilmelidir. Service reload sonrası /v2/ endpoint test edilmelidir. Olay sonrası expiration alarmının neden çalışmadığı incelenmelidir.

Registry Incident Response

Registry supply chain içinde merkezi konumda olduğu için güvenlik olayı geniş etki yaratabilir. Credential sızıntısı, malicious image push veya signing key compromise için önceden runbook hazırlanmalıdır. İlk amaç saldırganın yeni artifact değiştirmesini durdurmaktır. Audit log ve image digest bilgileri olay kapsamını belirlemek için kullanılır. Incident sonrasında credential rotation ve trusted artifact doğrulaması yapılmalıdır.

Registry Credential Sızıntısı

Sızan credential hemen revoke edilmelidir. Hangi repository'lere erişimi olduğu belirlenmelidir. Audit log üzerinden şüpheli push, pull veya delete event'leri incelenmelidir. Aynı secret başka sistemlerde kullanılıyorsa hepsi rotate edilmelidir. Yeni credential least privilege scope ile oluşturulmalıdır.

Admin Account Compromise

Admin compromise registry'nin tamamını etkileyebilir. Hesap hemen disable edilmelidir. Diğer admin kullanıcı ve role değişiklikleri audit edilir. Saldırgan yeni robot account oluşturmuş olabilir. Production artifact digest listesi güvenilir kayıtlarla karşılaştırılmalıdır.

Malicious Image Push

Şüpheli image push tespit edildiğinde ilgili digest quarantine veya erişim dışına alınmalıdır. Hangi deployment'ların bu digest'i kullandığı kontrol edilmelidir. Signature ve provenance verisi incelenmelidir. CI pipeline logları artifact'ın kaynağını göstermelidir. Temiz digest belirlenerek workload rollback yapılabilir.

Signing Key Compromise

Signing key compromise yüksek öncelikli supply chain incident'tır. Key hemen revoke edilmelidir. İlgili key ile imzalanmış yeni artifact'lar taranmalıdır. Trusted signer policy güncellenmelidir. Yeni key güvenli ortamda üretilip dağıtılmalıdır.

Registry Database Compromise

Database compromise kullanıcı, token veya policy bilgilerinin değişmesine yol açabilir. Uygulama erişimi gerekirse geçici olarak read-only moda alınmalıdır. Temiz backup ile mevcut veri karşılaştırılmalıdır. Credential rotation yapılmalıdır. Database erişim logları ve network event'leri incelenmelidir.

Image Silinmesi

Production image silindiyse önce deployment'ın halen local node cache üzerinde çalışıp çalışmadığı kontrol edilir. Replication veya backup kopyası aranır. Artifact digest güvenilir kayıtlardan doğrulanır. Restore sonrası immutability ve delete permission politikası gözden geçirilir. Olayın insan hatası mı saldırı mı olduğu audit log ile belirlenir.

Artifact Tampering

Artifact tampering image içeriğinin beklenmeyen şekilde değiştirilmesi girişimidir. Digest değişikliği bunu görünür hale getirir. Signature verification başarısız olabilir. Running deployment digest'leri trusted build kayıtlarıyla karşılaştırılmalıdır. Registry storage integrity incelemesi yapılmalıdır.

Incident Sonrası Credential Rotation

Incident scope belirsizse ilgili admin, robot ve automation credential'ları rotate edilmelidir. Yeni credential'lar eski scope'u otomatik kopyalamamalıdır. Least privilege review yapılmalıdır. Rotation sırasında pipeline kesintisi kontrollü yönetilmelidir. Eski token ve session'lar revoke edilmelidir.

Registry Ele Geçirilirse Ne Yapılmalı?

Registry compromise durumunda ilk hedef yeni kötü amaçlı değişiklikleri durdurmaktır. Push işlemleri geçici olarak kapatılabilir. Şüpheli digest listesi audit log ve timestamp üzerinden çıkarılır. Signing key ve credential'lar rotate veya revoke edilir. Kubernetes workload'ları güvenilir digest listesiyle karşılaştırılarak temiz backup'tan restore planı hazırlanır.

Push İşlemlerini Durdurmak

Incident sırasında yeni artifact girişini durdurmak kapsamın büyümesini engeller. Registry read-only moda alınabilir. CI/CD pipeline'lar geçici olarak pause edilir. Pull erişimi business continuity için açık tutulabilir. Bu karar incident commander tarafından koordine edilmelidir.

Şüpheli Image Digest'lerini Belirlemek

Audit log hangi timestamp'te hangi image'ın push edildiğini gösterir. Compromise penceresi belirlenir. Bu zaman aralığındaki digest'ler inceleme listesine alınır. Provenance ve signature bilgisi karşılaştırılır. Production deployment inventory ile eşleştirme yapılır.

Signing Key'leri Revoke Etmek

Saldırgan signing key'e erişmiş olabileceğinden ilgili key revoke edilmelidir. Trusted signer policy güncellenir. Yeni key ayrı güvenli ortamda üretilir. Eski key ile yeni deployment engellenir. Mevcut production artifact'ların güvenilirliği bağımsız kayıtlarla kontrol edilir.

Credentials Rotate Etmek

Admin, robot ve service account credential'ları rotate edilmelidir. Özellikle incident döneminde kullanılan token'lar iptal edilir. CI/CD secrets güvenli biçimde güncellenir. Yeni credential minimum scope ile oluşturulur. Rotation logları incident timeline'a eklenir.

Audit Log İncelemek

Audit log olayın başlangıç ve kapsamını belirlemeye yardımcı olur. Login, push, delete ve permission change event'leri incelenir. Source IP ve identity bilgileri ilişkilendirilir. SIEM üzerinde diğer sistem loglarıyla correlation yapılır. Eksik log varsa monitoring coverage iyileştirme aksiyonu çıkarılır.

Kubernetes Deployment'larını Kontrol Etmek

Cluster'larda çalışan image digest listesi çıkarılmalıdır. Şüpheli digest ile çalışan workload varsa izolasyon veya rollback yapılır. Tag yerine digest kullanımı bu analizi kolaylaştırır. Admission policy geçici olarak daha sıkı hale getirilebilir. Pod restart sırasında registry'den yeniden image çekileceği dikkate alınmalıdır.

Temiz Backup'tan Restore

Registry state güvenilir biçimde doğrulanamıyorsa temiz backup'tan restore gerekebilir. Backup compromise zamanından önce alınmış olmalıdır. Restore sonrası tüm credential'lar yeni değerlerle değiştirilmelidir. Image digest ve signature kontrolleri yapılmalıdır. Service yeniden açılmadan önce security review tamamlanmalıdır.

Registry Güvenlik Hardening

Registry hardening katmanlı güvenlik yaklaşımı gerektirir. Sistem internete doğrudan açılmamalı, network firewall ve private access kullanılmalıdır. TLS, mTLS, MFA ve RBAC farklı saldırı yollarına karşı ayrı kontroller sağlar. Vulnerability scanning, signing ve audit logging artifact güvenliğini destekler. En güçlü yapı tek bir güvenlik özelliğine değil, birbirini tamamlayan kontrollerin birlikte çalışmasına dayanır.

İnternete Doğrudan Açmamak

Registry internet üzerinden erişilebilir olmak zorunda değilse private network içinde tutulmalıdır. Remote kullanıcılar VPN üzerinden bağlanabilir. Attack surface bu şekilde azalır. Public access gerekirse WAF, authentication ve rate limit gibi ek kontroller uygulanmalıdır. Management interface ayrı network üzerinden erişilebilir olmalıdır.

Firewall

Firewall yalnızca gerekli source network ve portlara izin vermelidir. CI/CD, developer ve Kubernetes segmentleri ayrı rule ile yönetilebilir. Default deny yaklaşımı tercih edilebilir. Rule değişiklikleri audit edilmelidir. Kullanılmayan erişimler düzenli temizlenmelidir.

VPN / Private Network

Private network registry trafiğini public internetten ayırır. Remote erişim VPN üzerinden sağlanabilir. DNS çözümleme internal zone ile çalışabilir. VPN kullanıcı yetkileri least privilege olmalıdır. Network access tek başına application authentication yerine geçmez.

TLS

TLS credential ve image transfer trafiğini şifreler. Server identity certificate ile doğrulanır. Internal CA veya public CA kullanılabilir. Expiration monitoring zorunludur. Insecure registry production ortamında kullanılmamalıdır.

mTLS

mTLS istemci cihaz kimliğini certificate ile doğrular. CI runner veya Kubernetes node erişiminde güçlü kontrol sağlar. Client certificate süreli ve revocable olmalıdır. Aynı certificate birçok makinede paylaşılmamalıdır. User authentication ile birlikte kullanılabilir.

MFA

MFA yönetici ve yüksek yetkili kullanıcı hesaplarında zorunlu olmalıdır. Password compromise etkisini azaltır. Robot account için MFA yerine machine identity uygulanır. Break-glass hesap farklı güvenlik sürecine tabi tutulur. MFA bypass logları alarm üretmelidir.

RBAC

RBAC kullanıcıların yalnızca görevleri kadar yetki almasını sağlar. Production push ve delete rolleri sınırlı tutulmalıdır. Group-based role assignment yönetimi kolaylaştırır. Access review düzenli yapılmalıdır. Admin role kullanım oranı minimum olmalıdır.

Least Privilege

Least privilege insan ve service account'lar için aynı şekilde uygulanmalıdır. Global yetki yerine project scope kullanılmalıdır. Pull-only workload'a push yetkisi verilmemelidir. Temporary access expiration ile sınırlandırılmalıdır. Kullanılmayan account'lar otomatik kapatılmalıdır.

Vulnerability Scanning

Registry'ye gelen image'lar otomatik taranmalıdır. Scheduled re-scan yeni CVE'leri ortaya çıkarır. Critical bulgular security gate ile yönetilir. Exception süresi sınırlı tutulur. Scanner database güncelliği monitoring ile kontrol edilir.

Signing

Signing artifact'ın güvenilir CI sürecinden geldiğini doğrulamaya yardımcı olur. Production deployment signature verification yapmalıdır. Signing key yüksek güvenlikle korunmalıdır. Key rotation ve revocation politikası bulunmalıdır. Unsigned artifact production'a alınmamalıdır.

Audit Logging

Audit log login, push, delete ve policy change event'lerini kaydeder. Loglar merkezi SIEM sistemine gönderilmelidir. Admin aktiviteleri ayrı alert oluşturabilir. Retention süresi compliance ihtiyacına göre belirlenir. Log bütünlüğü korunmalıdır.

Registry İçin Network Segmentasyonu

Network segmentasyonu registry'ye erişen sistemlerin risk seviyesine göre ayrılmasını sağlar. Developer network, CI/CD runner, Kubernetes cluster ve management network farklı güvenlik politikalarına sahip olabilir. Internet egress yalnızca proxy cache veya approved transfer sistemlerine verilebilir. Firewall kuralları açıkça dokümante edilmelidir. Zero Trust yaklaşımında iç network'te olmak otomatik güven anlamına gelmez.

Developer Network

Developer network kullanıcı push ve pull işlemlerini destekler. Production project push erişimi bu segment için kapalı tutulabilir. VPN kullanıcıları aynı policy'ye tabi olmalıdır. DNS yalnızca internal registry endpoint'i göstermelidir. Anormal trafik rate monitoring ile takip edilebilir.

CI/CD Network

CI/CD runner'lar registry'ye automation account ile erişir. Network rule yalnızca gerekli portlara izin vermelidir. Runner'ların internet erişimi proxy üzerinden sınırlandırılabilir. Production signer gibi kritik hizmetler ayrı subnet'te bulunabilir. Credential ve network kimliği birlikte kontrol edilebilir.

Kubernetes Cluster

Kubernetes node'ları çoğu durumda yalnızca registry pull erişimine ihtiyaç duyar. Node subnet'inden push trafiği engellenebilir. Internal CA trust node runtime'a dağıtılmalıdır. NetworkPolicy pod trafiğini yönetirken registry pull host seviyesinde gerçekleşebileceği için node network dikkate alınmalıdır. Cluster bazlı pull account kullanılabilir.

Management Network

Admin portal ve SSH erişimi management network ile sınırlandırılabilir. Developer subnet yönetim portlarına erişmemelidir. Bastion veya privileged access workstation kullanılabilir. Admin session'ları audit log altında tutulmalıdır. Management network internetten doğrudan erişilebilir olmamalıdır.

Internet Egress

Registry'nin internete sınırsız çıkması gerekmeyebilir. Vulnerability database update veya proxy cache için belirli endpoint'lere erişim verilebilir. Egress proxy kullanımı görünürlüğü artırır. Air-gapped ortamda egress tamamen kapalıdır. Dış artifact transferi ayrı kontrol sürecinden geçer.

Firewall Rules

Firewall rule source, destination, port ve business owner bilgisi içermelidir. Temporary rule expiration ile oluşturulmalıdır. Geniş subnet izinleri yerine gerekli network aralığı kullanılmalıdır. Rule review belirli aralıklarla yapılmalıdır. Deneme amacıyla açılan portlar unutulmamalıdır.

Zero Trust Yaklaşımı

Zero Trust iç ağdaki hiçbir bağlantıyı otomatik güvenilir kabul etmez. User identity, machine identity ve least privilege birlikte uygulanır. Registry erişimi TLS ve authentication ile korunur. Network segmentation ek güvenlik katmanıdır. Continuous verification yaklaşımı credential ve certificate lifecycle yönetimini önemli hale getirir.

Kurumsal Container Registry Governance

Teknik platform kadar ownership ve policy modeli de registry başarısını belirler. Registry owner altyapı operasyonundan, security owner güvenlik politikasından sorumlu olabilir. Project ve image owner sorumlulukları açıkça tanımlanmalıdır. Naming, retention, vulnerability ve signing politikaları yazılı hale getirilmelidir. Exception management süreci olmayan sert politikalar zaman içinde kontrolsüz bypass yöntemlerine yol açabilir.

Registry Owner

Registry owner platform availability, upgrade ve capacity süreçlerinden sorumludur. Infrastructure roadmap bu ekip tarafından yönetilebilir. Security policy kararlarını tek başına vermemelidir. SLO ve incident runbook ownership açık olmalıdır. Backup ve restore drill sonuçlarını takip etmelidir.

Security Owner

Security owner vulnerability, signing ve access policy standartlarını belirler. Exception taleplerini değerlendirebilir. Incident sırasında artifact trust analizine liderlik edebilir. Scanner database ve CVE policy güncelliğini takip eder. Developer ekipleriyle remediation SLA üzerinde anlaşmalıdır.

Project Owner

Project owner belirli uygulama veya takım namespace'inden sorumludur. Üye erişimlerini gözden geçirir. Retention ve quota ihtiyacını belirler. Production artifact sahipliği project owner ile ilişkilendirilebilir. Kullanılmayan repository'lerin kapatılmasını onaylayabilir.

Image Owner

Image owner artifact içeriğinin uygulama sorumluluğunu taşır. Yeni vulnerability çıktığında remediation aksiyonunu yönetir. Base image update ihtiyacını takip eder. Production release hangi source commit'ten geldiğini doğrular. Ownership metadata registry veya CMDB içinde tutulabilir.

Naming Policy

Naming policy repository ve tag isimlerini standardize eder. Automation ve retention kuralları daha güvenilir çalışır. Uygulama, environment ve version bilgisi açık biçimde tanımlanabilir. Rastgele tag kullanımına izin verilmemelidir. Policy CI pipeline tarafından otomatik kontrol edilebilir.

Retention Policy

Retention policy environment ve business ihtiyacına göre farklılık gösterir. Development kısa süre tutulabilir. Production release'leri daha uzun korunabilir. Active deployment digest'leri silinmemelidir. Dry-run ve approval süreçleri risk azaltır.

Vulnerability Policy

Vulnerability policy hangi severity veya risk seviyesinde aksiyon alınacağını belirler. Exploitability ve business criticality birlikte değerlendirilebilir. Remediation SLA tanımlanmalıdır. Exception süreli ve onaylı olmalıdır. Scheduled re-scan policy'nin güncelliğini korur.

Signing Policy

Signing policy hangi artifact'ın kim tarafından imzalanacağını belirler. Production image'ları için zorunlu olabilir. Trusted signer listesi security owner tarafından yönetilir. Key rotation ve revocation süreçleri tanımlanmalıdır. Deployment verification enforcement mode'da çalıştırılabilir.

Exception Management

Exception management policy'nin kontrollü biçimde geçici olarak aşılmasını sağlar. Her exception owner, gerekçe ve expiration date içerir. Süre sonunda otomatik kapanma veya yeniden onay gerekir. Kalıcı exception yerine root cause remediation hedeflenmelidir. Raporlama ile açık exception sayısı izlenebilir.

Registry İçin Kullanılması Gereken Politikalar

Registry policy seti kurumun risk profiline göre belirlenmelidir. Direct public pull, mutable tag, SBOM ve signing gibi konular teknik enforcement ile desteklenebilir. Sadece dokümantasyon uzun vadede yeterli değildir. Policy önce audit mode'da uygulanarak ekiplerin etkisi ölçülebilir. Daha sonra production ortamında enforcement etkinleştirilebilir.

Public Registry Direct Pull Yasak mı?

Birçok kurumsal ortamda direct public pull sınırlandırılmalıdır. Approved proxy cache kullanımı daha kontrollüdür. Public image önce scan ve gerektiğinde signing sürecinden geçebilir. Developer ihtiyaçları tamamen engellenmeden talep süreci oluşturulmalıdır. Network ve admission policy birlikte kullanılabilir.

latest Tag Yasak mı?

Production ortamında latest tag kullanımı güçlü biçimde sınırlandırılmalıdır. Hangi artifact'ın deploy edildiği belirsiz hale gelir. Rollback ve audit zorlaşır. Version ve digest kullanımı daha güvenlidir. Development ortamında geçici kullanım kabul edilebilir.

Immutable Tag Zorunlu mu?

Production tag'leri için immutability güçlü bir kontroldür. Aynı release tag'inin başka digest'e taşınmasını engeller. Yanlış artifact push edilirse yeni version oluşturulur. Audit geçmişi korunur. Development project'lerde daha esnek policy kullanılabilir.

SBOM Zorunlu mu?

SBOM özellikle regulated veya büyük ölçekli yapılarda güçlü görünürlük sağlar. Yeni dependency zafiyetlerinde affected image analizi hızlanır. Production promotion için SBOM varlığı zorunlu hale getirilebilir. Küçük ekipler aşamalı rollout yapabilir. Format standardı belirlenmelidir.

Signing Zorunlu mu?

Production image'ları için signing supply chain güvenliğini artırır. Registry compromise tek başına artifact trust kaybına yol açmaz. Deployment signature verification yapabilir. Signing key yönetimi ayrıca tasarlanmalıdır. Development ortamında warning mode ile başlanabilir.

Critical CVE Deployment Engellenmeli mi?

Critical CVE otomatik engelleme güçlü kontrol sağlar ancak bağlam değerlendirilmelidir. False positive veya erişilemeyen dependency durumları olabilir. Exception workflow bulunmalıdır. Internet-facing production workload için daha sıkı policy uygulanabilir. Risk acceptance süreli tutulmalıdır.

Image Retention Kaç Gün Olmalı?

Tek bir gün sayısı tüm kurumlar için doğru değildir. Development image'ları 30 veya 60 gün tutulabilir. Production release'leri aylar veya yıllar saklanabilir. Compliance ve rollback ihtiyacı belirleyicidir. Storage maliyeti ve business risk birlikte değerlendirilmelidir.

Kurum İçi Registry'nin Toplam Maliyeti

Toplam maliyet hesaplanırken compute ve storage dışında DevOps operasyonu, security operasyonu, monitoring ve DR maliyeti de dikkate alınmalıdır. Backup kopyaları storage tüketimini artırır. Multi-site replication network maliyeti oluşturabilir. Platform ücretsiz olsa bile mühendislik zamanı önemli giderdir. Total Cost of Ownership kararı managed veya self-hosted yaklaşım karşılaştırmasında daha gerçekçi sonuç verir.

Compute

Compute maliyeti registry application, scanner, database ve cache servislerinin CPU ve RAM ihtiyacını kapsar. HA ortamında replica sayısı maliyeti artırır. Development ve production için farklı kapasite ayrılabilir. Autoscaling bazı bileşenlerde verim sağlayabilir. Peak workload göz önünde bulundurulmalıdır.

Storage

Storage maliyeti image volume, retention ve deduplication oranına bağlıdır. Object request ve snapshot maliyetleri ayrıca olabilir. Production artifact'ların uzun retention süresi kapasiteyi büyütür. Lifecycle ve cleanup politikaları gereksiz maliyeti azaltır. Growth rate aylık raporlanmalıdır.

Backup

Backup primary verinin bir veya daha fazla kopyasını saklar. Off-site ve immutable seçenekler maliyeti artırabilir. Incremental backup alan tasarrufu sağlar. Restore test ortamı da kaynak tüketir. Ancak backup maliyetinden kaçınmak ciddi business risk oluşturur.

Network

Network maliyeti multi-site replication ve cloud egress senaryolarında önemli hale gelir. Public image cache dış trafik miktarını azaltabilir. Region'lar arası transfer ücretleri hesaplanmalıdır. Internal bandwidth kapasitesi de altyapı yatırımı gerektirebilir. Network maliyeti workload büyüdükçe yeniden değerlendirilmelidir.

DevOps Operasyonu

DevOps ekibi upgrade, monitoring, backup ve troubleshooting süreçlerine zaman ayırır. Bu zaman TCO hesaplamasına dahil edilmelidir. Otomasyon manuel operasyonu azaltabilir. Ancak otomasyonun bakım maliyeti de vardır. Platform basitliği ekip kapasitesiyle dengelenmelidir.

Security Operasyonu

Security ekibi vulnerability policy, signing ve audit süreçlerini yönetir. CVE remediation ve exception incelemesi sürekli operasyon gerektirir. SIEM ve scanner altyapısı ek maliyet oluşturabilir. Compliance raporları zaman gerektirir. Güçlü governance uzun vadede incident riskini azaltır.

Monitoring

Monitoring metric storage, dashboard ve alerting sistemi gerektirir. Log retention maliyeti özellikle yüksek trafik ortamlarında büyüyebilir. Kritik metric'ler seçilerek gereksiz veri azaltılabilir. SIEM lisans veya altyapı maliyeti ayrı olabilir. Monitoring olmadan operasyon riski daha yüksektir.

Disaster Recovery

DR ikinci site, backup ve replication maliyeti oluşturabilir. Warm standby daha yüksek maliyetli ancak daha kısa RTO sağlar. Cold restore daha ucuz olabilir ancak dönüş süresi uzar. İş gereksinimi uygun modeli belirler. Düzenli drill için de mühendislik zamanı ayrılmalıdır.

Total Cost of Ownership

TCO tüm teknik ve insan maliyetlerini birlikte değerlendirir. Yalnızca sunucu faturası karar vermek için yeterli değildir. Operasyon, security ve downtime riski dahil edilmelidir. Üç yıllık perspektif daha gerçekçi sonuç verir. Registry büyüme tahmini senaryo bazlı hesaplanabilir.

Kurum İçi Registry vs Managed Registry

Self-hosted ve managed registry yaklaşımları farklı kontrol ve operasyon seviyeleri sunar. Kurum içi model data residency, network isolation ve policy kontrolü açısından avantajlı olabilir. Managed model bazı altyapı sorumluluklarını azaltabilir. Ancak veri konumu, erişim modeli ve entegrasyon gereksinimleri ayrıca değerlendirilmelidir. Karar yalnızca başlangıç kurulum süresine göre verilmemelidir.

Self-Hosted Harbor

Self-hosted Harbor platform üzerinde yüksek kontrol sağlar. Network, storage ve identity integration kurum politikalarına göre tasarlanabilir. Vulnerability scanning, replication ve project governance gibi özellikler kullanılabilir. Buna karşılık upgrade, backup ve HA sorumluluğu kurumda kalır. Güçlü DevOps operasyon ekibi bulunan yapılarda esnek bir seçenektir.

Güvenlik

Self-hosted model güvenlik kontrolünü doğrudan kuruma verir. Ancak yanlış configuration güvenlik riskini artırabilir. Managed yaklaşımda bazı altyapı güvenliği servis sağlayıcı tarafından yönetilir. Her iki modelde de kullanıcı, secret ve supply chain policy kuruma aittir. Shared responsibility modeli açıkça anlaşılmalıdır.

Maliyet

Maliyet yalnızca hizmet faturası veya sunucu maliyeti değildir. Self-hosted platform mühendislik zamanı gerektirir. Managed model network ve storage kullanımına göre değişken ücret oluşturabilir. Backup ve DR her iki modelde de değerlendirilmelidir. Üç yıllık TCO karşılaştırması yapılmalıdır.

Kontrol

Kurum içi registry network ve data path üzerinde daha yüksek kontrol sağlayabilir. Custom authentication ve internal CA daha kolay uygulanabilir. Managed modelde bazı platform davranışları sabit olabilir. Gereken compliance veya air-gap ihtiyacı kontrol seviyesini belirler. Operasyon kolaylığı ile esneklik dengelenmelidir.

Operasyon Yükü

Self-hosted modelde patch, backup ve monitoring kurumun sorumluluğundadır. Managed model bu yükün bir bölümünü azaltabilir. Ancak policy ve incident response sorumluluğu devam eder. CI/CD ve Kubernetes entegrasyonu yine yapılandırılmalıdır. Ekip kapasitesi kararın önemli parçasıdır.

Data Residency

Data residency image ve metadata verisinin hangi bölgede tutulduğunu ifade eder. On-premise model fiziksel konum üzerinde doğrudan kontrol sağlayabilir. Managed modelde region seçimi veya hizmet koşulları değerlendirilmelidir. Backup kopyalarının konumu da aynı derecede önemlidir. Compliance ekibi tasarım aşamasına dahil edilmelidir.

Sık Karşılaşılan Docker Registry Hataları

Registry sorunlarında hata mesajını ezberlemek yerine katmanlı troubleshooting yapmak daha etkilidir. DNS, TLS, authentication, reverse proxy, registry application ve storage sırasıyla kontrol edilmelidir. 401 ve 403 authorization sorunlarına işaret ederken 413 genellikle proxy body limitinden kaynaklanır. ImagePullBackOff Kubernetes tarafında farklı kök nedenlerin ortak belirtisidir. Disk Full ise registry'nin hem push hem de metadata işlemlerini etkileyebilir.

x509 Certificate Signed by Unknown Authority

Bu hata istemcinin registry certificate chain'e güvenmediğini gösterir. Internal CA certificate client trust store'a eklenmemiş olabilir. Intermediate certificate eksik olabilir. Hostname ile certificate SAN uyuşmazlığı da kontrol edilmelidir. Insecure registry kullanmak yerine trust chain düzeltilmelidir.

HTTP Response to HTTPS Client

Bu hata istemcinin HTTPS beklediği endpoint'in HTTP yanıt verdiğini gösterir. Reverse proxy veya port mapping yanlış olabilir. Registry URL configuration kontrol edilmelidir. TLS termination beklenen katmanda aktif olmayabilir. Client'ın yanlış port kullandığı da doğrulanmalıdır.

401 Unauthorized

401 kimlik doğrulama yapılmadığını veya credential'ın geçersiz olduğunu gösterir. docker login tekrar denenebilir. Token issuer ve external URL ayarları kontrol edilmelidir. Expired robot credential sık karşılaşılan nedendir. Audit log login attempt hakkında ek bilgi verir.

403 Forbidden

403 kullanıcı authenticated olsa bile gerekli yetkiye sahip olmadığını gösterir. Project role ve repository permission kontrol edilmelidir. CI account yanlış project scope kullanıyor olabilir. Production push policy kasıtlı olarak işlemi engelliyor olabilir. Permission change audit logdan doğrulanabilir.

413 Request Entity Too Large

413 reverse proxy'nin request body boyutunu reddettiğini gösterir. Büyük layer upload sırasında görülür. client body size veya benzeri proxy limiti artırılmalıdır. Registry route'una özel configuration yapılabilir. Değişiklik sonrası büyük test image'ı push edilmelidir.

Manifest Unknown

Manifest Unknown istenen tag veya digest'in repository içinde bulunmadığını gösterir. Image path yazım hatası olabilir. Retention policy artifact'ı silmiş olabilir. Replication henüz tamamlanmamış olabilir. Registry catalog ve tag listesi kontrol edilmelidir.

Blob Unknown

Blob Unknown manifest'in referans verdiği layer verisinin bulunamadığını gösterebilir. Storage corruption veya yanlış garbage collection ihtimali vardır. Registry logları incelenmelidir. Backup ve replication kopyası karşılaştırılabilir. Storage consistency kontrolü yapılmalıdır.

ImagePullBackOff

ImagePullBackOff Kubernetes'in image çekme işlemini tekrar tekrar denediğini gösterir. Pod event hata nedenini açıklayabilir. DNS, TLS, credential ve image path kontrol edilmelidir. Internal CA node runtime'a tanıtılmamış olabilir. Registry audit log pull isteğinin gelip gelmediğini gösterir.

Disk Full

Disk Full registry'nin yeni layer yazmasını engeller. Database veya log partition da etkilenebilir. Önce güvenli biçimde boş alan oluşturulmalıdır. Retention ve garbage collection uygulanabilir. Sonrasında capacity alarmının neden daha önce tetiklenmediği incelenmelidir.

Push Timeout

Push timeout network, proxy veya storage yavaşlığından kaynaklanabilir. Büyük layer boyutu sorunu artırır. Reverse proxy timeout değerleri kontrol edilmelidir. Storage latency metriği incelenmelidir. CI retry policy sonsuz tekrar yapmamalıdır.

Registry Troubleshooting Akışı

Registry troubleshooting en hızlı sonuç için katmanlı sırayla yapılmalıdır. Önce DNS çözümleme, ardından TLS bağlantısı ve /v2/ endpoint kontrol edilir. Authentication challenge ve docker login doğrulanır. Daha sonra proxy logları, registry logları, storage ve network incelenir. Kubernetes problemi varsa son aşamada pod event ve node runtime logları değerlendirilir.

DNS Kontrolü

Registry hostname istemciden doğru IP adresine çözülmelidir. Internal DNS ve VPN resolver davranışı kontrol edilmelidir. Split DNS kullanılıyorsa farklı networklerden sonuç karşılaştırılmalıdır. DNS cache eski IP tutuyor olabilir. nslookup veya dig benzeri araçlarla doğrulama yapılabilir.

TLS Kontrolü

TLS handshake certificate chain ve hostname bilgisiyle doğrulanmalıdır. Expired certificate kontrol edilmelidir. Internal CA istemcide mevcut olmalıdır. Reverse proxy doğru certificate'i sunmalıdır. SNI kullanılan yapılarda yanlış hostname farklı certificate döndürebilir.

/v2/ Endpoint Kontrolü

/v2/ endpoint registry servisinin temel API erişimini doğrular. 200 veya authentication challenge beklenebilir. 404 alınıyorsa proxy route yanlış olabilir. 502 backend service erişim sorunu gösterebilir. Bu test Docker client'tan bağımsız ilk kontrol sağlar.

Authentication Challenge

Registry authentication challenge istemciye token veya basic auth mekanizmasını bildirir. Header içindeki realm ve service değerleri doğru hostname'i göstermelidir. Reverse proxy header değiştiriyor olabilir. External URL yanlışsa token flow başarısız olabilir. Browser yerine CLI header kontrolü yapılmalıdır.

Docker Login

docker login kullanıcı credential'ını doğrular. Robot account expiration kontrol edilmelidir. Password-stdin ile test yapılabilir. Başarılı login sonrası gerçek pull yetkisi ayrıca denenmelidir. Login başarısı push izni olduğu anlamına gelmez.

Reverse Proxy Logları

Proxy logları request'in backend'e ulaşıp ulaşmadığını gösterir. 413, 502 ve timeout hataları burada açıkça görülebilir. Upstream response time storage veya application yavaşlığını gösterebilir. Client IP forwarded header ile korunmalıdır. Log timestamp registry loglarıyla eşleştirilmelidir.

Registry Logları

Registry logları authorization, manifest ve storage hatalarının ana kaynağıdır. Request ID varsa proxy loguyla eşleştirilebilir. Error message yanında repository ve digest bilgisi incelenmelidir. Debug log geçici olarak açılabilir. Secret veya token loglanmamasına dikkat edilmelidir.

Storage

Storage free space ve latency kontrol edilmelidir. Object storage credential expire olmuş olabilir. NFS mount read-only hale gelmiş olabilir. Permission değişikliği registry yazmasını engelleyebilir. Basit read ve write testleri yapılabilir.

Network

Network packet loss veya MTU sorunu büyük layer transferlerinde etkili olabilir. Küçük API request başarılıyken büyük upload başarısız olabilir. Firewall idle timeout kontrol edilmelidir. WAN bağlantısı throughput testiyle ölçülmelidir. Network ekibiyle timestamp bazlı correlation yapılabilir.

Kubernetes Event'leri

Kubernetes event'leri ImagePullBackOff nedenini hızlı gösterir. Unauthorized, x509 veya manifest unknown mesajı doğrudan kök nedene yönlendirebilir. Node bazlı hata varsa runtime configuration kontrol edilmelidir. Aynı namespace'te imagePullSecret varlığı doğrulanmalıdır. Pod spec'teki image path dikkatle incelenmelidir.

Production'a Çıkmadan Önce Registry Kontrol Listesi

Production'a çıkmadan önce yalnızca başarılı image push testi yeterli değildir. TLS, RBAC, SSO, vulnerability scanning, signing, retention, backup ve monitoring birlikte kontrol edilmelidir. Restore testi yapılmamış sistem production-ready kabul edilmemelidir. Certificate ve capacity alarmı erken uyarı sağlar. Disaster recovery planı teknik ekip tarafından gerçekten uygulanabilir olmalıdır.

TLS Aktif mi?

Registry trafiği HTTPS üzerinden çalışmalıdır. Certificate hostname ile uyumlu olmalıdır. Internal CA istemcilere dağıtılmış olmalıdır. Expiration alarmı kurulmalıdır. Insecure registry ayarı production client'larda bulunmamalıdır.

Anonymous Push Kapalı mı?

Anonymous push production ortamında kapalı olmalıdır. Her push belirli kullanıcı veya robot identity ile ilişkilendirilmelidir. Public pull gerekiyorsa ayrı project kullanılabilir. Push yetkisi role ile sınırlandırılmalıdır. Audit log işlemi kaydetmelidir.

RBAC Tanımlandı mı?

Administrator, developer ve automation rolleri ayrılmalıdır. Production push yalnızca gerekli identity'lere verilmelidir. Project scope kullanılmalıdır. Unused accounts temizlenmelidir. Access review takvimi belirlenmelidir.

MFA/SSO Var mı?

SSO kullanıcı yaşam döngüsünü merkezi hale getirir. MFA yüksek yetkili hesaplarda zorunlu olmalıdır. Local admin break-glass kullanımına sınırlandırılabilir. SSO failure senaryosu test edilmelidir. Group mapping düzenli gözden geçirilmelidir.

Robot Account Kullanılıyor mu?

CI/CD insan kullanıcısı credential'ıyla çalışmamalıdır. Robot account project scope ile sınırlandırılmalıdır. Expiration ve rotation politikası bulunmalıdır. Secret pipeline loglarına düşmemelidir. Production ve development için ayrı account kullanılabilir.

Vulnerability Scanning Aktif mi?

Scan on push yeni image'ları analiz etmelidir. Scheduled re-scan eski image'lar için etkin olmalıdır. Scanner database güncelliği takip edilmelidir. Security gate threshold tanımlanmalıdır. Exception workflow süreli çalışmalıdır.

Signing Politikası Var mı?

Production image signing politikası tanımlanmalıdır. Trusted signer listesi yönetilmelidir. Key rotation ve revocation planı bulunmalıdır. Deployment verification uygulanmalıdır. Unsigned artifact için exception süreci açık olmalıdır.

SBOM Üretiliyor mu?

SBOM build sırasında üretilmelidir. Image digest ile ilişkilendirilmelidir. SPDX veya CycloneDX formatı seçilebilir. Registry içinde OCI artifact olarak saklanabilir. Security ekibi affected image sorgusu yapabilmelidir.

Retention Policy Var mı?

Retention olmadan registry storage sürekli büyür. Development ve production süreleri farklı olmalıdır. Active deployment artifact'ları korunmalıdır. Dry-run desteklenmelidir. Policy sonucu düzenli raporlanmalıdır.

Garbage Collection Planlandı mı?

Retention sonrası orphan blob'lar storage içinde kalabilir. Garbage collection planlı schedule ile çalıştırılmalıdır. Backup ve dry-run yapılmalıdır. Maintenance ihtiyacı registry sürümüne göre değerlendirilmelidir. İşlem sonrası storage health kontrol edilmelidir.

Backup Var mı?

Blob storage, database ve configuration backup kapsamına alınmalıdır. Backup başka hata alanında tutulmalıdır. Encryption uygulanmalıdır. RPO hedefi belirlenmelidir. Backup job failure alarm üretmelidir.

Restore Test Edildi mi?

Backup restore edilmeden güvenilir kabul edilmemelidir. İzole ortamda full restore yapılmalıdır. Süre ölçülerek gerçek RTO belirlenmelidir. Image push ve pull testi tamamlanmalıdır. Eksikler runbook'a işlenmelidir.

Monitoring Var mı?

Availability, error rate ve latency izlenmelidir. Storage growth ve scan queue monitoring kapsamına girmelidir. Alertler on-call sistemine bağlanmalıdır. Dashboard operasyon ekibi tarafından kullanılabilir olmalıdır. Alarm testleri yapılmalıdır.

Audit Log Saklanıyor mu?

Login, push, delete ve permission change logları tutulmalıdır. Merkezi SIEM entegrasyonu yapılabilir. Retention süresi security policy ile uyumlu olmalıdır. Admin event'leri ayrı alarm üretebilir. Log bütünlüğü korunmalıdır.

Certificate Expiry Alarmı Var mı?

Certificate expiry gün sayısı monitoring ile izlenmelidir. Warning alarmı yeterince erken verilmelidir. Intermediate CA süresi ayrıca takip edilmelidir. Automatic renewal başarısızlığı alarm üretmelidir. Renewal sonrası health check yapılmalıdır.

Capacity Alarmı Var mı?

Disk yüzde kullanımı ve growth rate izlenmelidir. Warning ve critical seviyeler ayrı olmalıdır. Tahmini dolma günü hesaplanabilir. Retention ve expansion runbook'u bulunmalıdır. Backup storage kapasitesi de ayrıca takip edilmelidir.

Disaster Recovery Planı Hazır mı?

DR planı yalnızca backup linkinden oluşmamalıdır. RPO, RTO, DNS failover ve sorumlu ekip tanımlanmalıdır. Restore drill yapılmalıdır. Secondary site veya recovery infrastructure erişimi test edilmelidir. Plan düzenli güncellenmelidir.

Sık Yapılan Registry Yönetim Hataları

Registry sorunlarının önemli bölümü karmaşık teknik arızalardan değil, başlangıçta alınan basit ama yanlış kararlardan kaynaklanır. HTTP kullanmak, admin hesabını CI/CD'ye vermek veya latest tag'e güvenmek zaman içinde ciddi risk oluşturur. Retention ve GC olmadan storage kontrolsüz büyür. Backup alıp hiç restore test etmemek sahte güven yaratır. Single point of failure olan registry ise kritik deployment anında tüm operasyonu durdurabilir.

Registry'yi HTTP Olarak Çalıştırmak

HTTP credential ve metadata trafiğini korumaz. Production ortamında kabul edilmemelidir. Internal network tek başına güvenli varsayılmamalıdır. TLS configuration otomasyonla yönetilebilir. Client certificate trust sorunu doğru CA dağıtımıyla çözülmelidir.

Self-Signed Certificate'i insecure-registry ile Geçiştirmek

Insecure registry ayarı TLS doğrulamasını devre dışı bırakarak gerçek sorunu gizler. Internal CA kullanmak daha doğru yaklaşımdır. CA certificate client trust store'a dağıtılmalıdır. Configuration management bu işlemi otomatikleştirebilir. Production sisteminde insecure flag bırakılmamalıdır.

Tüm Kullanıcılara Push Yetkisi Vermek

Herkese push yetkisi vermek accidental veya malicious değişiklik riskini artırır. Development project için daha geniş izin verilebilir. Production push yalnızca pipeline robot account'a bırakılmalıdır. Delete yetkisi ayrıca sınırlandırılmalıdır. Access review düzenli yapılmalıdır.

CI/CD'de Admin Hesabı Kullanmak

Admin credential sızarsa saldırgan registry'nin tamamına erişebilir. Pipeline yalnızca kendi repository'sine push yapmalıdır. Robot account kullanılmalıdır. Scope ve expiration tanımlanmalıdır. Credential secret manager içinde tutulmalıdır.

latest Tag'e Güvenmek

latest tag immutable değildir. Aynı tag farklı zamanlarda farklı digest gösterebilir. Production deployment hangi artifact'ın çalıştığını kaybedebilir. Version ve digest kullanımı daha güvenlidir. latest yalnızca kontrollü development senaryolarında kullanılabilir.

Vulnerability Scan Sonuçlarını Görmezden Gelmek

Scanner kurmak tek başına güvenlik sağlamaz. Bulgular remediation workflow'a bağlanmalıdır. Critical risk için SLA tanımlanmalıdır. False positive exception olarak kaydedilmelidir. Scheduled re-scan yeni CVE'leri görünür hale getirmelidir.

Image Signing Yapmamak

Signing olmadan registry'deki artifact'ın güvenilir pipeline tarafından üretildiği ek olarak doğrulanamaz. Registry compromise durumunda risk büyür. Production verification policy uygulanabilir. Key management doğru yapılmalıdır. Provenance ile birlikte kullanıldığında güven zinciri güçlenir.

Retention Olmadan Registry Çalıştırmak

Retention olmayan registry sürekli büyür. Development build'leri kısa sürede büyük storage tüketebilir. Manuel cleanup sürdürülebilir değildir. Policy environment'a göre otomatik çalışmalıdır. Dry-run yanlış silme riskini azaltır.

Garbage Collection Yapmamak

Manifest silmek blob verisini her zaman storage'dan kaldırmaz. Zaman içinde orphan data birikir. Garbage collection düzenli planlanmalıdır. Registry sürümüne uygun prosedür kullanılmalıdır. İşlem sonrası disk kazanımı ölçülmelidir.

Backup Alıp Restore Test Etmemek

Backup job'ın başarılı olması dosyanın geri yüklenebilir olduğunu kanıtlamaz. Encryption key eksik olabilir. Database dump bozuk olabilir. Full restore drill gerçek güven verir. Ölçülen RTO iş hedefiyle karşılaştırılmalıdır.

Registry'yi Tek Noktadan Arızaya Açık Bırakmak

Tek node küçük ortam için yeterli olabilir ancak kritik production için risklidir. Host arızası tüm image erişimini durdurabilir. HA veya standby mimari iş kritikliğine göre planlanmalıdır. Storage ve database de tek hata noktası olmamalıdır. Failover test edilmelidir.

Sık Sorulan Sorular

Private Docker Registry nasıl kurulur?

Private registry kurulumu için önce DNS, TLS, persistent storage ve authentication planlanmalıdır. Küçük sistemlerde Compose tabanlı temel registry kurulabilir. Kurumsal ortamlarda Harbor gibi governance özellikleri sunan platformlar değerlendirilebilir. Registry container'ı başlatıldıktan sonra push ve pull testleri yapılmalıdır. Production kullanımından önce backup, monitoring, RBAC ve vulnerability scanning mutlaka eklenmelidir.

Docker Registry ücretsiz midir?

Açık kaynak registry bileşenleri lisans ücreti olmadan kullanılabilir. Ancak altyapı ve işletim maliyeti devam eder. Compute, storage, backup ve network kaynakları gerekir. DevOps ve security ekiplerinin operasyon zamanı da maliyetin parçasıdır. Bu nedenle ücretsiz yazılım ile sıfır maliyetli sistem aynı şey değildir.

Harbor nedir?

Harbor kurumsal container registry kullanımına yönelik project, RBAC, scanner, replication ve retention gibi özellikler sunan bir platformdur. Registry servisinin üzerine governance katmanı ekler. Robot account ve external authentication desteği CI/CD entegrasyonunu kolaylaştırır. Production ortamında HA ve external storage seçenekleri değerlendirilebilir. Backup ve upgrade sorumluluğu yine platformu işleten ekibe aittir.

Docker Registry ile Harbor arasındaki fark nedir?

Temel registry daha sade push ve pull servisidir. Harbor kullanıcı yönetimi, project, scanner, replication ve policy özellikleri ekler. Küçük ekiplerde basit registry yeterli olabilir. Çok ekipli production ortamlarında Harbor merkezi governance sağlar. Seçim operasyon kapasitesi ve güvenlik ihtiyacına göre yapılmalıdır.

Harbor production ortamında kullanılabilir mi?

Evet, doğru mimari ve operasyon süreçleriyle production ortamında kullanılabilir. TLS, external storage ve backup planlanmalıdır. Kritik sistemlerde HA deployment tercih edilebilir. Database ve Redis tek hata noktası olmamalıdır. Monitoring ve restore drill production readiness'in önemli parçalarıdır.

Private Docker Registry güvenli midir?

Private olması tek başına güvenli olduğu anlamına gelmez. TLS, authentication, RBAC ve network segmentation gerekir. Vulnerability scanning ve signing artifact güvenliğini artırır. Audit log olay görünürlüğü sağlar. Backup ve incident response da güvenli operasyonun parçasıdır.

Docker Registry'de HTTPS zorunlu mudur?

Production için HTTPS temel gereksinim kabul edilmelidir. Credential ve image metadata trafiğini korur. Internal CA kullanılabilir. Client trust store doğru yapılandırılmalıdır. Insecure registry ayarı kalıcı çözüm olarak kullanılmamalıdır.

Docker Registry'ye kullanıcı yetkisi nasıl verilir?

Basit registry external authentication ve token sistemiyle yetkilendirilebilir. Harbor gibi platformlarda project role kullanılabilir. Administrator, developer ve read-only roller ayrılmalıdır. CI/CD için robot account tercih edilmelidir. Production push yetkisi sınırlı tutulmalıdır.

Harbor LDAP ile entegre edilebilir mi?

Harbor kurumsal directory sistemleriyle authentication entegrasyonu sağlayabilir. LDAP bağlantısı TLS üzerinden korunmalıdır. Group mapping role yönetimini kolaylaştırır. Merkezi kullanıcı lifecycle erişim kapatmayı hızlandırır. Break-glass local admin hesabı ayrıca planlanmalıdır.

Harbor Active Directory ile çalışır mı?

Directory entegrasyonu üzerinden kurumsal kullanıcı ve grup yapısı kullanılabilir. Group-to-role mapping ile project erişimi yönetilebilir. Identity bağlantısı güvenli network üzerinden yapılmalıdır. Kullanıcı ayrıldığında merkezi hesap kapatılması erişimi sona erdirir. Authentication kesintisi için acil erişim hesabı planlanmalıdır.

Docker image nasıl imzalanır?

Image digest üzerinden Cosign benzeri araçlarla signature üretilebilir. Signing key güvenli secret store içinde tutulmalıdır. CI pipeline başarılı scan ve test sonrası imzalama yapabilir. Signature registry içinde OCI artifact olarak saklanabilir. Production deployment signature verification gerçekleştirmelidir.

Registry'de vulnerability scanning nasıl yapılır?

Harbor ile Trivy gibi scanner entegrasyonu kullanılabilir. Scan on push yeni image geldiğinde otomatik analiz başlatır. Scheduled re-scan eski artifact'lar için yeni CVE'leri kontrol eder. Security gate severity ve risk context'e göre karar verir. Exception workflow süreli ve kayıtlı olmalıdır.

SBOM registry'de saklanabilir mi?

Evet, OCI artifact destekleyen registry yapılarında SBOM image ile ilişkili olarak saklanabilir. SPDX veya CycloneDX formatları kullanılabilir. Build pipeline SBOM'u image digest ile ilişkilendirir. Security ekipleri dependency sorgusu yapabilir. Retention policy image ve SBOM'u birlikte ele almalıdır.

Docker Hub için kurum içi mirror kurulabilir mi?

Public registry proxy cache yaklaşımıyla kurum içi mirror benzeri yapı oluşturulabilir. Sık kullanılan image'lar bir kez çekilir. Sonraki istekler internal cache'den karşılanabilir. Bandwidth ve rate limit baskısı azalır. Cache image'ları da security scan kapsamına alınmalıdır.

Harbor proxy cache nedir?

Proxy cache dış registry içeriğini talep üzerine internal sistemde tutar. Kullanıcı aynı image'ı tekrar istediğinde local kopya kullanılabilir. Network çıkışı azalır. Public artifact governance merkezi hale gelir. Approved source ve vulnerability policy ile birlikte kullanılmalıdır.

Docker Registry garbage collection nasıl yapılır?

Önce gereksiz manifest veya artifact'lar retention ile silinir. Ardından referanssız blob'lar garbage collection ile temizlenir. Registry sürümüne göre read-only maintenance gerekebilir. Dry-run ve backup yapılmalıdır. İşlem sonrası storage ve pull testleri kontrol edilmelidir.

Docker image'ları otomatik nasıl temizlenir?

Retention policy tag, yaş veya son N image kriterine göre otomatik çalıştırılabilir. Development project'lerde daha kısa süre uygulanabilir. Production image'ları koruma listesine alınmalıdır. Dry-run ile ilk sonuç incelenmelidir. Ardından garbage collection storage alanını fiziksel olarak temizleyebilir.

Registry nasıl yedeklenir?

Blob storage, database, configuration ve certificate verileri yedeklenmelidir. Off-site veya immutable kopya kullanılabilir. Backup sıklığı RPO hedefiyle uyumlu olmalıdır. Encryption uygulanmalıdır. Düzenli full restore testi yapılmalıdır.

Harbor high availability nasıl kurulur?

Multiple application replica, load balancer, external database, Redis ve shared storage birlikte kullanılabilir. Stateful bileşenlerin de HA olması gerekir. Storage object tabanlı veya shared olabilir. Failure testleri yapılmalıdır. Monitoring replica ve dependency health durumunu ayrı ayrı takip etmelidir.

Kubernetes private registry'den image nasıl çeker?

Kubernetes imagePullSecrets veya ServiceAccount üzerinden registry credential kullanabilir. Registry hostname node'lardan çözülebilir olmalıdır. Internal CA varsa container runtime trust store güncellenmelidir. Credential yalnızca pull yetkisine sahip olabilir. ImagePullBackOff durumunda pod event logu incelenmelidir.

Air-gapped ortamda Docker Registry nasıl yönetilir?

Offline installer ve kontrollü artifact transfer pipeline kullanılır. Dış ortamdan gelen image, signature ve digest bilgisi doğrulanır. Vulnerability database çevrimdışı paketlerle güncellenir. Approved artifact bundle yaklaşımı transfer sürecini standardize eder. Her transfer audit ve removable media kontrol politikasına tabi tutulmalıdır.

Kurum İçi Docker Registry Hakkında Ek Sorular

Kurum içi Docker Registry nasıl kurulur ve yapılandırılır?

Kurum içi Docker Registry kurulumu DNS, TLS, persistent storage, authentication ve backup tasarımıyla başlamalıdır. Ardından registry veya Harbor benzeri platform kurularak private project ve kullanıcı rolleri tanımlanmalıdır. CI/CD hesapları robot account olarak ayrılmalı, scan on push ve retention policy etkinleştirilmelidir. Production ortamında reverse proxy, monitoring ve restore testleri tamamlanmadan servis canlıya alınmamalıdır. Docker Registry ve DevOps danışmanlığı yakınımda aramasıyla yalnızca kurulum yapan bir hizmet yerine güvenlik, CI/CD ve disaster recovery süreçlerini birlikte ele alan bir ekip aramak uzun vadede daha sağlıklı sonuç verir.

Private Docker Registry için hangi çözüm tercih edilmelidir?

Seçim yaparken ekip sayısı, RBAC ihtiyacı, SSO, vulnerability scanning, replication ve operasyon kapasitesi dikkate alınmalıdır. Çok küçük ortamda temel registry yeterli olabilir. Birden fazla takım, production policy ve merkezi governance gerektiren yapılarda Harbor güçlü bir seçenektir. Platform seçiminin yalnızca bugünkü image sayısına göre yapılması ileride migration ihtiyacı oluşturabilir. Proje yaklaşımı ve teknik çalışmalar hakkında https://www.diyarbakiryazilim.com.tr/projects adresi üzerinden farklı uygulama ve DevOps çalışmalarını inceleyebilirsiniz.

Kurum içi Docker Registry’de SSL/TLS, kullanıcı yetkilendirmesi ve erişim güvenliği nasıl sağlanır?

İlk olarak registry HTTPS üzerinden yayınlanmalı ve geçerli certificate chain kullanılmalıdır. Internal CA varsa tüm istemci ve Kubernetes node'larına güven zinciri dağıtılmalıdır. Kullanıcılar SSO veya merkezi directory üzerinden doğrulanmalı ve project bazlı RBAC uygulanmalıdır. CI/CD servisleri robot account ile çalışmalı, admin hesabı pipeline içinde kesinlikle kullanılmamalıdır. Yüksek güvenlikli ortamlarda mTLS, MFA ve network segmentation birlikte uygulanarak hem makine hem kullanıcı kimliği kontrol edilebilir.

Docker image’larının versiyonlama, zafiyet taraması, yedekleme ve yaşam döngüsü yönetimi nasıl yapılmalıdır?

Image sürümleri semantic version, commit SHA ve build number ile izlenebilir hale getirilmelidir. Production deployment tag yerine digest kullanmalı ve immutable artifact politikası uygulanmalıdır. Scan on push ile yeni image taranmalı, scheduled re-scan ile yeni CVE'ler takip edilmelidir. Retention policy ve garbage collection storage büyümesini kontrol altında tutarken blob storage, database ve configuration düzenli yedeklenmelidir. Backup kadar restore drill de planlanmalı ve gerçek RTO değeri ölçülmelidir.

Kurum içi Docker Registry kurulumu ve yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Registry danışmanlığında yalnızca sunucu kurulumu değil, CI/CD, security, Kubernetes ve disaster recovery deneyimi birlikte aranmalıdır. Kurulum yapan ekibin TLS, RBAC, vulnerability scanning, signing, SBOM, retention ve backup konularını aynı mimari içinde ele alabilmesi önemlidir. Kurumsal private Docker Registry kurulum ve DevOps hizmeti için Diyarbakır Yazılım Topluluğu'nun çalışma yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilirsiniz. Özellikle production sistemlerde ilk kurulum kadar operasyon standardının hazırlanması da önemlidir. İyi tasarlanmış bir registry altyapısı ekip büyüdükçe yeni uygulamaların daha güvenli ve daha hızlı şekilde devreye alınmasını kolaylaştırır.

Sonuç: Production-Ready Kurum İçi Docker Registry Nasıl Yönetilir?

Kurum İçi Docker Registry Kurulumu ve Yönetimi başarılı olduğunda registry yalnızca image dosyalarının saklandığı bir sunucu olmaktan çıkar. CI/CD, Kubernetes, vulnerability management, signing, SBOM, access control ve disaster recovery süreçlerinin ortak güven katmanına dönüşür. Production-ready bir yapı TLS, robot account, immutable artifact, digest tabanlı deployment, retention, backup ve monitoring özelliklerini birlikte kullanır. Bunun yanında policy ve ownership modeli teknik altyapı kadar önemlidir. Başlangıçta doğru mimari kurulursa ekip sayısı ve deployment trafiği arttığında sistemi yeniden tasarlama ihtiyacı önemli ölçüde azalır.

Registry'yi Yalnızca Image Deposu Olarak Görmeyin

Registry software delivery zincirinin merkezi kontrol noktalarından biridir. Artifact kaynağı, imza, SBOM ve vulnerability sonucu burada ilişkilendirilebilir. Deployment platformu güvenilir artifact seçimini registry metadata üzerinden yapabilir. Audit log olay incelemesini kolaylaştırır. Bu nedenle registry operasyonu yalnızca storage yönetimi olarak ele alınmamalıdır.

Harbor Gibi Governance Özellikleri Olan Bir Platformu İhtiyaca Göre Değerlendirin

Küçük ekiplerde sade registry yeterli olabilir. Ekip ve project sayısı arttığında merkezi RBAC, scanning ve retention ihtiyacı büyür. Harbor bu governance özelliklerini tek platformda toplamaya yardımcı olabilir. Ancak platform seçimi gerçek ihtiyaç ve operasyon kapasitesi üzerinden yapılmalıdır. Gereksiz bileşen eklemek de operasyon yükünü artırabilir.

TLS ve Kimlik Doğrulamayı Temel Gereksinim Yapın

HTTP production ortamında kullanılmamalıdır. Internal CA veya güvenilir certificate ile HTTPS etkinleştirilmelidir. Kullanıcı kimliği merkezi sistemden doğrulanmalıdır. Machine identity için robot account veya mTLS kullanılabilir. Certificate lifecycle ve credential rotation otomatikleştirilmelidir.

İnsan ve CI/CD Hesaplarını Ayırın

Pipeline içinde kişisel kullanıcı hesabı kullanmak sürdürülebilir değildir. Robot account yalnızca gerekli repository scope'una sahip olmalıdır. Production push için ayrı automation identity kullanılabilir. Credential expiration ve rotation uygulanmalıdır. Audit log bu ayrım sayesinde daha anlamlı hale gelir.

Image'ları Scan Edin, İmzalayın ve SBOM ile Takip Edin

Vulnerability scan image içindeki bilinen riskleri görünür hale getirir. Signing artifact'ın güvenilir build sürecinden geldiğini doğrulamaya yardımcı olur. SBOM hangi dependency'nin hangi image içinde bulunduğunu gösterir. Bu üç kontrol birlikte kullanıldığında incident ve CVE response süresi azalır. Production policy bu kontrolleri otomatik enforce edebilir.

Production Deployment'larda Tag Yerine Digest Kullanın

Tag değiştirilebilir olduğu için production artifact kimliği açısından yeterli değildir. Digest immutable içerik referansı sağlar. Kubernetes manifestleri digest ile güncellenebilir. Promotion sırasında aynı digest korunmalıdır. Rollback işlemi de eski güvenilir digest'e dönerek yapılabilir.

Public Image'ları Proxy Cache ve Policy Üzerinden Kontrol Edin

Direct internet pull supply chain görünürlüğünü azaltır. Proxy cache public image'ları kurum içine kontrollü biçimde alır. Security scan ve approved base image policy uygulanabilir. Network bandwidth ve rate limit sorunları azalabilir. Kullanıcı deneyimi korunurken güvenlik kontrolü merkezileşir.

Retention ve Garbage Collection'ı Otomatikleştirin

Registry storage sınırsız değildir. Retention gereksiz artifact'ları lifecycle kuralına göre temizler. Garbage collection referanssız blob verisini fiziksel storage'dan kaldırır. Dry-run ve production protection policy kullanılmalıdır. Capacity monitoring cleanup sürecinin etkisini göstermelidir.

Backup Kadar Restore'u da Test Edin

Başarılı backup job gerçek recovery garantisi değildir. Database, blob storage ve configuration birlikte restore edilmelidir. İzole DR testinde push ve pull doğrulanmalıdır. Gerçek RTO ölçülmelidir. Eksikler runbook güncellemesine dönüştürülmelidir.

Registry'yi Software Supply Chain'in Merkezi Güven Katmanı Olarak Yönetin

Registry build ve production arasındaki güven zincirinin merkezinde yer alır. Artifact digest, signature, SBOM, provenance ve vulnerability sonucu aynı image ile ilişkilendirilebilir. CI/CD ve Kubernetes policy bu metadata'yı kullanarak otomatik karar verebilir. Böylece güvenlik sonradan yapılan manuel kontrol olmaktan çıkar ve deployment sürecinin doğal parçası haline gelir. Kurulum, güvenlik mimarisi, CI/CD entegrasyonu veya production operasyonu konusunda destek almak için https://www.diyarbakiryazilim.com.tr adresi üzerinden Diyarbakır Yazılım Topluluğu ile iletişime geçebilirsiniz.