Kubernetes Image Signing ve Admission Policy

İmzasız Image, Kubernetes İçin Kör Güvendir

Kubernetes cluster güvenliği çoğu zaman network policy, RBAC ve ingress hardening üzerinden konuşulur. Ancak cluster içine hangi container image'ın girdiği doğrulanmıyorsa, diğer kontroller geç kalmış demektir. Çünkü saldırganın tek yapması gereken, pipeline veya registry yoluna zararlı bir image sokmaktır.

Image signing, container imajının beklenen üretici tarafından üretildiğini ve sonradan değiştirilmediğini kanıtlar. Admission policy ise bu kanıt yoksa pod'un cluster içinde çalışmasını engeller.

Saldırı Senaryosu

Bir geliştiricinin registry token'ı sızdırıldığında saldırgan aynı tag ile yeni image push edebilir. backend-api:latest etiketi değişir ama deployment manifest aynı kalır. Kubernetes için bu sıradan bir rollout gibi görünür. Eğer imza ve digest pinning yoksa cluster zararlı image'ı gönüllü şekilde çalıştırır.

Bu yüzden sadece "private registry kullanıyoruz" demek yeterli değildir. Private registry de kimlik bilgisi sızdığında saldırganın yazabildiği bir kaynağa dönüşür.

Güvenli Dağıtım Kuralları

• Production deployment mutable tag yerine digest kullanmalı.
• Build pipeline image imzası üretmeli.
• SBOM ve provenance bilgisi artifact olarak saklanmalı.
• Admission controller imzasız image'ı reddetmeli.
• Base image değişimi güvenlik onayından geçmeli.
• Registry push yetkisi ortam ve takım bazında ayrılmalı.

DevSecOps Olgunluk Sinyali

Olgun bir Kubernetes ortamında soru "bu image çalışıyor mu?" değildir. Doğru soru şudur: "Bu image kimin pipeline'ında üretildi, hangi commit'ten geldi, hangi bağımlılıkları içeriyor ve cluster neden buna güveniyor?"

Eresus Yaklaşımı

Eresus Security, Kubernetes ve DevSecOps değerlendirmelerinde image signing zincirini build aşamasından admission kararına kadar test eder. K8s ortamınızda imzasız image çalışabiliyorsa, saldırgan için supply chain yolu hâlâ açıktır.

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.

Temel Değerlendirme

Kubernetes Image Signing ve Admission Policy konusu yalnızca teknik bir ayrıntı değildir; yanlış ele alındığında veri sızıntısı, yetki aşımı, operasyon kesintisi veya regülasyon riski doğurur. En doğru yaklaşım, varlıkları ve kullanıcı rollerini netleştirip gerçek saldırı yolunu kanıtla test etmek, ardından düzeltmeyi ölçülebilir retest kriterine bağlamaktır.

Neden Kritik?

• Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler.
• Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez.
• Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Pratik Senaryo

Bir ekip sistemi güvenli kabul eder çünkü login çalışır, pipeline yeşildir veya model beklenen cevabı üretir. Ancak saldırgan aynı akışta farklı kullanıcı, farklı tenant, farklı dosya veya farklı token ile deneme yaptığında tasarımın sakladığı gerçek risk ortaya çıkar. Bu yüzden testler mutlu yol yerine kötüye kullanım senaryolarıyla yazılmalıdır.

Yanlış Bilinenler

• “Araç taradı, kritik yok” güvenlik onayı değildir.
• “İç sistem, saldırgan erişemez” varsayımı modern saldırı zincirlerinde zayıftır.
• “Bu sadece teknik borç” denilen konu çoğu zaman müşteri verisi veya production erişimiyle birleşir.

Karar Tablosu

| Durum | Risk seviyesi | Önerilen aksiyon | | --- | --- | --- | | Demo veya izole test ortamı | Düşük-Orta | Mimari kararları ve veri akışını belgeleyin | | Staging production verisine yakın | Orta-Yüksek | Yetki, log ve abuse testlerini ekleyin | | Production veya müşteri verisi | Yüksek | Profesyonel assessment, remediation ve retest planlayın |

Kontrol Listesi

• CI/CD tokenları kısa ömürlü mü?
• Secret bulunduğunda revoke ve rotation otomatik mi?
• Image imzası admission aşamasında doğrulanıyor mu?
• Branch protection bypass edilebiliyor mu?
• Pipeline logları hassas veri sızdırıyor mu?

Ne Zaman Profesyonel Destek Gerekir?

Pipeline production deploy yapıyorsa, uzun ömürlü secret taşıyorsa, Kubernetes/cloud erişimi varsa veya çok repo yönetiliyorsa profesyonel DevSecOps review gerekir.

Eresus Yaklaşımı

Eresus Security bulguları yalnızca başlık olarak raporlamaz. Her bulgu için tekrar üretilebilir kanıt, iş etkisi, önerilen düzeltme, sorumlu ekip ve retest koşulu yazılır.

Eresus Security, CI/CD token, secret rotation, image signing, Git policy ve supply-chain kontrollerini pipeline hızını bozmadan sertleştirir. Tarık Çelik liderliğinde mevcut akışınızı kanıt odaklı inceleyebiliriz.

Uygulama Planı

1. Kapsamı Netleştir

• Etkilenen varlıkları, kullanıcı rollerini ve veri sınıflarını çıkarın.
• Normal kullanıcı akışıyla saldırgan akışını ayrı ayrı yazın.
• Hariç tutulan sistemleri ve test sınırlarını açıkça belirtin.

2. Kanıt Üret

• Bulguyu tek ekran görüntüsüne değil, tekrar üretilebilir adımlara bağlayın.
• Etkiyi teknik hata ve iş sonucu olarak ayrı açıklayın.
• Log, request ID, test hesabı ve zaman bilgisini not edin.

3. Retest Kriterini Belirle

• Düzeltmenin ne zaman tamam sayılacağını önceden yazın.
• Aynı sınıf hatanın başka endpoint veya akışlarda olup olmadığını kontrol edin.
• Bulguyu kapatmadan önce negatif test senaryosunu yeniden çalıştırın.

Sık Sorulan Sorular

Kubernetes Image Signing ve Admission Policy için ilk adım nedir?

İlk adım sistemin hangi veriye, hangi kimlikle ve hangi iş akışı üzerinden eriştiğini çıkarmaktır. Araç seçimi bundan sonra anlamlı hale gelir.

Otomatik araçlar bu riski tamamen yakalar mı?

Hayır. Otomatik araçlar başlangıç için faydalıdır, fakat yetki sınırı, iş mantığı, zincirleme etki ve gerçek istismar kanıtı manuel analiz gerektirir.

Bu çalışma çıktısı nasıl aksiyona dönüşür?

Her bulgu bir remediation sahibi, öncelik, iş etkisi ve retest kriteriyle yazıldığında doğrudan güvenlik backlog’una veya sprint planına girebilir.

Eresus bu konuda nasıl destek olur?

Eresus Security kapsam çıkarma, teknik test, kanıt üretimi, remediation danışmanlığı ve retest aşamalarını tek çalışma akışında destekler.

Raporlama ve İç Link Stratejisi

• Yazı ilgili hub sayfasına bağlanmalı ve okuyucuya bir sonraki teknik adımı göstermelidir.
• Aynı pillar içindeki en az iki destekleyici bloga bağlantı verilmelidir.
• Hizmet CTA’sı genel iletişim çağrısı gibi değil, okuyucunun karar anına uygun şekilde yazılmalıdır.
• Raporlama dili teknik kanıt, iş etkisi ve düzeltme önceliğini aynı yerde göstermelidir.

Retest Kapanış Kriteri

Bir bulgu yalnızca düzeltme yapıldı diye kapanmış sayılmaz. Aynı saldırı adımı tekrar denendiğinde başarısız olmalı, loglarda beklenen kayıt oluşmalı ve benzer akışlarda aynı sınıf hata bulunmamalıdır. Bu yaklaşım içeriği sadece bilgilendirici olmaktan çıkarıp uygulamaya dönük hale getirir.