Ana menüyü aç veya kapat

Kubernetes

Docker Hub Limitleri, Güvenlik Riskleri ve Kubernetes İçin Local Harbor Registry Kullanımı

Docker Hub pull limitleri, Bitnami katalog değişiklikleri ve container image güvenliği için Kubernetes ortamlarında local Harbor registry kullanımını açıklayan rehber.

Teknik rehber

Kubernetes, DevOps ve kurumsal altyapı yönetimi için uygulanabilir teknik öneriler.

Kubernetes kullanan kurumlar için container image yönetimi artık yalnızca "imajı çek ve çalıştır" seviyesinde ele alınabilecek bir konu değil. Docker Hub pull limitleri, üçüncü taraf imaj sağlayıcılarının kullanım şartlarını değiştirmesi (Bitnami örneği), supply chain saldırıları (xz-utils backdoor) ve artan ağ trafiği maliyetleri kurumları kendi local veya private container registry altyapılarını kurmaya yönlendiriyor.

Bu noktada öne çıkan çözümlerden biri Harbor. Harbor; Kubernetes ve Docker ortamlarında container image'larını güvenli şekilde saklamak, taramak, imzalamak, erişim politikalarıyla yönetmek ve gerektiğinde dış registry'lerden cache'lemek için kullanılan açık kaynaklı, CNCF Graduated bir container registry çözümüdür. VMware tarafından 2016'da açık kaynak yapılan Harbor, 2018'de CNCF'e katılmış ve Haziran 2020'de graduated statüsüne ulaşmıştır.

Docker Hub Neden Artık Tek Başına Yeterli Değil?

Docker Hub, uzun yıllardır container dünyasının varsayılan merkezi registry noktası oldu. Ancak üretim ortamlarında doğrudan Docker Hub'a bağımlı kalmak ciddi operasyonel riskler doğurabiliyor.

Güncel Docker Hub Pull Limitleri (2026)

Docker'ın resmi dokümantasyonuna göre güncel pull rate limitleri şu şekildedir:

Kullanıcı TipiPull Limiti
Anonim (kimliksiz)100 pull / 6 saat / IP
Docker Personal (kimlikli, ücretsiz)200 pull / 6 saat
Docker Pro, Team, BusinessUnlimited (fair use)

Not: Docker, 1 Nisan 2025 tarihinde uygulamayı planladığı daha sıkı limitleri (anonim için 10 pull/saat, Personal için 100 pull/saat) topluluk geri bildirimleri sonrası geri çekti. 10 Haziran 2025 tarihli Docker blog yazısına göre eski limitler korunmakta ve herhangi bir yeni uygulama en az 6 ay önceden duyurulacaktır. Yine de bu durum, limit politikalarının her an değişebileceğini gösteriyor.

Kaynaklar:

Bu Limitlerin Sorun Yarattığı Senaryolar

Mevcut limitler bile aşağıdaki durumlarda kolayca aşılabilir:

  • Çok node'lu Kubernetes cluster'larında aynı imajların tekrar tekrar çekilmesi
  • CI/CD pipeline'larında sık build ve deploy yapılması
  • Auto scaling sırasında yeni node'ların hızla artması ve image pull patlaması
  • Aynı public imajların dev, test, staging ve production ortamlarında ayrı ayrı çekilmesi
  • NAT arkasından çıkan kurum networklerinde tüm developer'ların tek bir public IP ile dış dünyaya görünmesi (rate limit IP başına uygulandığı için en kritik nokta budur)
  • İnternet erişimi kısıtlı veya air-gapped çalışan kurum ortamları

Kısacası, production Kubernetes ortamlarında doğrudan docker.io, ghcr.io, quay.io veya benzeri public registry'lere bağımlı kalmak sürdürülebilir bir model değildir.

Bitnami Örneği: İmaj Adresi Değişirse Ne Olur?

Container ekosisteminde yalnızca Docker Hub limitleri değil, imaj sağlayıcılarının politika değişiklikleri de ciddi etki yaratabilir. Bitnami olayı bunun en güncel ve sarsıcı örneğidir.

Bitnami Geçişinin Kronolojisi

Broadcom çatısı altındaki Bitnami ekibi 2025 yılında public katalogda kapsamlı bir değişiklik yaptı:

  • 28 Ağustos 2025: Bitnami non-hardened Debian tabanlı imajların deprecation'ı başladı. Brownout (geçici erişim kesintisi) dönemleri uygulandı: 28–29 Ağustos, 2–3 Eylül, 17–18 Eylül.
  • 29 Eylül 2025: docker.io/bitnami deposunun büyük kısmı kalıcı olarak silindi.
  • Legacy repo: Eski versiyonlu tag'ler (örn. postgresql:13.7.0) docker.io/bitnamilegacy adresine taşındı. Bu repo güncelleme ve güvenlik yaması almıyor, sadece geçici migration için.
  • Ücretsiz tier: Sadece sınırlı sayıda hardened uygulamanın latest tag'lerine erişim kaldı. Versiyon pinleme imkânı kaldırıldı.
  • Ticari alternatif: Production kullanımı için Bitnami Secure Images aboneliği (Broadcom).

Kaynaklar:

Bu Değişiklik Production'da Ne Anlama Geliyordu

Helm chart veya Kubernetes manifest dosyalarında doğrudan eski adresleri kullanan kurumlar deployment hatalarıyla karşılaştı.

Örneğin bir workload bu şekilde tanımlıysa:

image: docker.io/bitnami/redis:7.2.5-debian-12-r0

Image artık docker.io/bitnami üzerinde bulunmadığından şu hatalar oluşur:

Failed to pull image "docker.io/bitnami/redis:7.2.5-debian-12-r0":
failed to resolve reference: not found

Olası sonuçlar:

  • Pod'lar ImagePullBackOff veya ErrImagePull durumuna düşer.
  • Yeni node'lar imajı çekemez, autoscaling yapılamaz.
  • CI/CD pipeline'ları kırılır.
  • Production'da beklenmeyen kesintiler yaşanır.
  • Güvenlik güncellemeleri alınamaz.

Geçici Workaround

Acil durumda imaj adresleri bitnamilegacy olarak güncellenebilir, ancak bu kalıcı bir çözüm değildir:

# Geçici çözüm — uzun vadede güvenli değil
image: docker.io/bitnamilegacy/redis:7.2.5-debian-12-r0

Kalıcı çözüm: Kritik imajların kendi kontrol ettiğiniz Harbor gibi bir registry'de mirror edilmesi.

Docker Hub Üzerindeki Zararlı İmaj Riski

Container image güvenliği de en az erişilebilirlik kadar önemlidir. Public registry'lerde yayınlanan imajlar her zaman güvenli kabul edilmemelidir. Son yıllarda container supply chain saldırıları, cryptomining amaçlı imajlar ve backdoor içeren paketler ciddi bir tehdit haline geldi.

Güncel Örnek: XZ-Utils Backdoor (CVE-2024-3094)

Mart 2024'te keşfedilen ve CVSS 10.0 skoruyla en kritik open-source supply chain saldırılarından biri kabul edilen xz-utils backdoor (CVE-2024-3094), Ağustos 2025'te yapılan Binarly araştırmasına göre hâlâ Docker Hub üzerinde en az 35 Linux imajında mevcut. Backdoor, liblzma.so kütüphanesi üzerinden OpenSSH'ın RSA_public_decrypt fonksiyonuna hook atarak, özel bir private key'e sahip saldırgana SSH üzerinden authentication bypass ve root yetkisinde komut çalıştırma imkânı veriyordu.

Daha da kritik olan, bu backdoor'lu base image'lar üzerine kurulan transitive olarak enfekte ikinci el imajların buildpack-deps, neurodebian, github-runner gibi yaygın repository'lere yayılması.

Kaynaklar:

Kurumların Kendisine Sorması Gereken Sorular

  • Bu imaj hangi kaynaktan geliyor?
  • Hangi base image üzerine kurulu?
  • İçinde bilinen CVE var mı?
  • İmaj düzenli olarak taranıyor mu?
  • Production'a alınmadan önce onay sürecinden geçiyor mu?
  • İmaj digest ile sabitlenmiş mi?
  • Aynı imajın kurum içi güvenli kopyası var mı?

Çözüm: Kubernetes Ortamlarında Local Harbor Registry

Harbor, kurumların container image'larını kendi ortamlarında güvenli şekilde yönetmesini sağlayan açık kaynaklı bir registry çözümüdür.

Harbor'un Öne Çıkan Özellikleri

  • Private container registry
  • Role Based Access Control (RBAC)
  • Proje bazlı yetkilendirme ve multi-tenancy
  • Vulnerability scanning (varsayılan: Trivy — v2.2'den itibaren default; eski default Clair'in yerini aldı)
  • Image signing desteği (Cosign / Notation)
  • Registry replication (cross-region, cross-cluster)
  • Proxy cache (pull-through cache)
  • Audit log
  • Robot account desteği
  • Helm chart ve OCI artifact desteği
  • Kubernetes ile doğal uyum

Kaynaklar:

Local Harbor Kullanmanın Avantajları

1. Docker Hub Pull Limitlerinden Etkilenmezsiniz

Cluster node'ları veya CI/CD runner'ları her seferinde Docker Hub'dan imaj çekmek yerine Harbor üzerinden imajları alabilir. Özellikle NAT arkasındaki kurumsal networklerde tek bir IP'den çıkan tüm trafiğin rate limit'e takılması engellenir.

2. Network Trafiği Azalır

Aynı imajın yüzlerce kez dış registry'den çekilmesi yerine imaj bir kez Harbor'a alınır ve tüm cluster içinden local olarak kullanılır.

Örnek mirror işlemi:

docker pull nginx:1.27
docker tag nginx:1.27 harbor.kubits.local/library/nginx:1.27
docker push harbor.kubits.local/library/nginx:1.27

Kubernetes manifest içinde Harbor adresi kullanılır:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: harbor.kubits.local/library/nginx:1.27
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

3. Güvenlik Taraması Yapabilirsiniz

Harbor, vulnerability scanning entegrasyonlarıyla imajların güvenlik açıklarına karşı kontrol edilmesini sağlar. Harbor v2.2'den itibaren default scanner Trivy'dir.

Trivy; container image, filesystem, Git repository, Kubernetes cluster ve IaC konfigürasyonları üzerinde CVE, misconfiguration ve secret taraması yapabilen açık kaynaklı bir güvenlik aracıdır.

Kaynaklar:

Örnek Trivy image taraması:

trivy image harbor.kubits.local/library/nginx:1.27

CI/CD pipeline içinde örnek kullanım:

stages:
  - scan
  - deploy

scan-image:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image \
        --exit-code 1 \
        --severity HIGH,CRITICAL \
        --ignore-unfixed \
        harbor.kubits.local/library/nginx:1.27

--exit-code 1 parametresi sayesinde CRITICAL veya HIGH seviye CVE bulunan imajların production pipeline'ında ilerlemesi otomatik olarak engellenir.

4. Bitnami ve Benzeri Değişikliklere Karşı Dayanıklılık

Bitnami örneğinde gördüğümüz gibi popüler imaj sağlayıcılarının repository, lisans veya erişim politikalarında yaptığı değişiklikler, doğrudan public imaj kullanan sistemlerde kesintiye yol açabilir.

Harbor kullanıldığında kritik imajlar önceden kurum içine alınabilir:

docker pull docker.io/bitnamilegacy/postgresql:16
docker tag docker.io/bitnamilegacy/postgresql:16 \
           harbor.kubits.local/bitnami/postgresql:16
docker push harbor.kubits.local/bitnami/postgresql:16

Ardından Helm chart değerleri kurum içi registry'ye yönlendirilir:

image:
  registry: harbor.kubits.local
  repository: bitnami/postgresql
  tag: "16"

Bu sayede dış provider kaynaklı adres değişiklikleri veya erişim problemleri production ortamını doğrudan etkilemez.

5. Air-Gapped ve Regüle Ortamlar İçin Uygundur

Finans, kamu, savunma, sağlık ve üretim gibi sektörlerde bazı Kubernetes ortamlarının internet erişimi sınırlıdır veya tamamen kapalıdır. Harbor bu yapılarda şu ihtiyaçlara cevap verir:

  • Offline image yönetimi
  • Kurum içi güvenlik politikalarına uyum
  • Denetlenebilir artifact yönetimi
  • Kontrollü imaj güncelleme süreci
  • Audit log ve erişim takibi
  • Onaylı imaj kataloğu oluşturma

Kubernetes İçin Önerilen Registry Mimarisi

Developer / CI Pipeline
        |
        v
    Image Build
        |
        v
Security Scan with Trivy
        |
        v
    Push to Harbor
        |
        v
Approval / Policy Control
        |
        v
Kubernetes Pulls from Harbor

Bu modelde Kubernetes cluster'ı mümkün olduğunca doğrudan public registry'lerden imaj çekmez. Tüm imajlar Harbor üzerinden yönetilir.

Harbor Proxy Cache Kullanımı

Harbor yalnızca private registry olarak değil, aynı zamanda proxy cache olarak da kullanılabilir.

Örneğin Docker Hub için bir proxy cache project oluşturulduğunda, Kubernetes node'ları Docker Hub'dan doğrudan çekmek yerine Harbor üzerinden imaj talep eder. Harbor imajı ilk seferde dış registry'den alır, daha sonra cache üzerinden servis eder.

Bu yaklaşımın avantajları:

  • Docker Hub rate limit etkisini azaltır
  • Aynı imaj tekrar tekrar dışarıdan indirilmez
  • Deployment süreleri kısalır
  • İnternet trafiği azalır
  • Merkezi kontrol sağlanır

Örnek kullanım mantığı:

image: harbor.kubits.local/dockerhub-proxy/library/redis:7

Kubernetes ImagePullSecret Örneği

Private Harbor registry kullanırken Kubernetes tarafında imagePullSecret tanımlanır:

kubectl create secret docker-registry harbor-regcred \
  --docker-server=harbor.kubits.local \
  --docker-username='robot$k8s-puller' \
  --docker-password='ROBOT_ACCOUNT_TOKEN' \
  --docker-email='devops@kubits.com.tr' \
  -n production

Deployment içinde kullanım:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      imagePullSecrets:
        - name: harbor-regcred
      containers:
        - name: app
          image: harbor.kubits.local/apps/app:v1.0.0

Çok sayıda namespace için merkezi yönetim isteniyorsa External Secrets Operator veya Reflector ile pull secret replikasyonu yapılabilir.

En İyi Uygulamalar

Public Registry'ye Doğrudan Bağımlılığı Azaltın

Production manifest dosyalarında mümkün olduğunca doğrudan docker.io, quay.io veya ghcr.io adresleri kullanılmamalıdır. Kritik imajlar Harbor üzerinde mirror veya cache edilmelidir.

latest Tag Kullanmayın

latest tag'i yerine versiyonlu tag veya digest kullanılmalıdır.

Yanlış kullanım:

image: nginx:latest

Daha doğru kullanım:

image: harbor.kubits.local/library/nginx:1.27.3

En kontrollü kullanım (digest pinning — değişmez, garanti):

image: harbor.kubits.local/library/nginx@sha256:xxxxxxxxxxxxxxxxxxxxxxxx

Digest kullanımı, aynı tag altında imaj değişse bile sizin pod'unuzun her zaman aynı binary'i çekmesini garanti eder ve supply chain saldırılarına karşı en güçlü savunma katmanıdır.

İmajları CI/CD Aşamasında Tarayın

Trivy gibi araçlarla imajlar production'a çıkmadan önce taranmalıdır:

trivy image \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  --ignore-unfixed \
  harbor.kubits.local/apps/api:v1.2.0

Harbor'da Proje Bazlı Yetkilendirme Yapın

Her ekip veya uygulama için ayrı Harbor project yapısı oluşturulmalıdır:

harbor.kubits.local/platform/*
harbor.kubits.local/payment/*
harbor.kubits.local/frontend/*
harbor.kubits.local/data/*

Robot Account Kullanın

CI/CD sistemlerinde kişisel kullanıcı hesabı yerine robot account kullanılmalıdır. Bu hesaplar dar kapsamlı yetkilendirilebilir ve audit log'da net olarak izlenebilir.

Düzenli Retention Policy Tanımlayın

Eski ve kullanılmayan imajlar registry üzerinde gereksiz disk tüketimine yol açar. Harbor retention policy ile eski tag'ler otomatik temizlenebilir. Örnek politika: "Her repository için son 10 tag ve son 30 gündeki tüm tag'ler tutulsun, geri kalanı silinsin."

Registry Replication Kurgulayın

Birden fazla lokasyon veya cluster kullanan kurumlar Harbor replication özelliğiyle imajları farklı lokasyonlara çoğaltabilir. DR (Disaster Recovery) senaryoları için kritiktir.

kubITS Yaklaşımı: Güvenli, Sürdürülebilir ve Kontrollü Container Altyapısı

kubITS olarak Kubernetes ortamlarında yalnızca uygulamanın çalışmasına değil, container image yaşam döngüsünün güvenli ve sürdürülebilir yönetilmesine de odaklanıyoruz.

Kurumlar için önerdiğimiz temel yaklaşım:

  • Local veya private Harbor registry kurulumu
  • Docker Hub ve diğer registry'ler için proxy cache yapılandırması
  • Trivy ile image vulnerability scanning ve policy enforcement
  • CI/CD pipeline güvenlik kontrolleri (scan-on-push, scan-on-deploy)
  • Kubernetes imagePullSecret ve RBAC düzenlemeleri
  • Bitnami ve benzeri üçüncü taraf imajların kontrollü mirror edilmesi
  • Air-gapped veya regüle ortamlar için offline image stratejisi
  • Production ortamları için image governance politikaları (signed images, digest pinning)
  • Cosign / Sigstore ile image signing entegrasyonu

Sonuç

Docker Hub pull limitleri, public registry bağımlılığı, Bitnami gibi sağlayıcıların imaj politikası değişiklikleri ve xz-utils gibi container supply chain saldırıları; Kubernetes kullanan kurumlar için local registry ihtiyacını artık kritik hale getirmiştir.

Harbor, bu ihtiyaca açık kaynaklı, güvenli ve kurumsal seviyede bir çözüm sunar. Trivy gibi güvenlik araçlarıyla birlikte kullanıldığında, kurumlar yalnızca imajlarını saklamakla kalmaz; aynı zamanda production ortamlarına çıkacak container image'larını güvenlik açısından kontrol altına alır.

Kubernetes ortamlarında sürdürülebilirlik, güvenlik ve performans için önerilen yaklaşım nettir:

Public registry'lere doğrudan bağımlılığı azaltın, kritik imajlarınızı Harbor üzerinde yönetin, deployment öncesi güvenlik taraması yapın ve container image yaşam döngüsünü merkezi politikalarla kontrol edin.

Kaynaklar