Konteyner Güvenliği: İmaj Taraması ve Yetki Sınırlandırma

Konteyner kullanmak uygulamaları hızlı paketlemeyi, taşımayı ve ölçeklemeyi kolaylaştırır. Fakat bir uygulamanın konteyner içinde çalışması, onun otomatik olarak güvenli olduğu anlamına gelmez. Güvenilmeyen bir base image, yıllardır güncellenmeyen bir bağımlılık, root yetkisiyle çalışan bir süreç veya gereğinden geniş Kubernetes izinleri saldırganın işini ciddi biçimde kolaylaştırabilir. Bu nedenle Konteyner Güvenliği: İmaj Taraması ve Yetki Sınırlandırma konusu yalnızca güvenlik ekibinin ilgilenmesi gereken bir alan değildir. Developer, DevOps, platform ve operasyon ekiplerinin aynı güvenlik zincirinin parçaları olarak hareket etmesi gerekir.

Bu rehberde konteyner güvenliğinde imaj taraması nasıl yapılır sorusundan başlayarak Docker ve Kubernetes container yetkileri nasıl sınırlandırılır konusuna kadar uzanan pratik bir yaklaşım kuracağız. Container image vulnerability scanning araçları ve güvenlik politikaları, Kubernetes RBAC least privilege rootless container ve runtime security nasıl uygulanır gibi daha ileri düzey başlıkları da gerçek kullanım senaryoları üzerinden ele alacağız. Amaç yalnızca bir tarama aracı çalıştırmak değil, build aşamasından production çalışma zamanına kadar güvenilir bir süreç oluşturmaktır. Böylece güvenlik açığı bulunduğunda hangi imajın, hangi servisin ve hangi deployment'ın etkilendiğini daha hızlı anlayabilirsiniz. Ayrıca geliştirme hızını tamamen durdurmadan güvenlik kontrollerinin nasıl otomatikleştirilebileceğini görebilirsiniz.

Konteyner Güvenliği Nedir?

Konteyner güvenliği, bir container image'ın oluşturulduğu andan production ortamında çalıştığı ana kadar geçen bütün yaşam döngüsündeki risklerin kontrol edilmesidir. Sadece çalışan container'a bakmak yeterli değildir. Dockerfile, base image, bağımlılıklar, registry izinleri, Kubernetes manifestleri, ServiceAccount yetkileri ve runtime davranışı aynı zincirin parçalarıdır. Zincirin herhangi bir noktası zayıfsa saldırgan buradan ilerleyebilir. Bu nedenle iyi bir container security yaklaşımı build, registry, deployment ve runtime aşamalarını birlikte ele alır.

Container Security Kavramı

Container security kavramının temelinde saldırı yüzeyini azaltmak vardır. Bir container'ın ihtiyaç duymadığı paketleri, binary dosyalarını, Linux capability'lerini ve erişim izinlerini kaldırdığınızda olası saldırı yollarını da azaltırsınız. Buradaki yaklaşım basittir: Bir uygulamanın çalışması için gerekli olmayan hiçbir şeyi production image içinde tutmayın. Aynı mantık Kubernetes izinlarında da geçerlidir. Bir pod yalnızca belirli bir ConfigMap okuyacaksa ona bütün namespace kaynaklarını değiştirme yetkisi vermek doğru değildir.

Docker Konteynerleri Güvenlik İzolasyonu Sağlar mı?

Docker konteynerleri process, network ve filesystem seviyesinde önemli bir izolasyon sağlar, ancak bu izolasyonu sanal makine sınırı gibi değerlendirmek doğru değildir. Konteynerler genellikle host işletim sisteminin kernel'ini paylaşır. Bu yüzden kernel seviyesinde ortaya çıkan bir açık veya gereğinden fazla yetkilendirilmiş bir container daha ciddi sonuçlar doğurabilir. Privileged mod, host namespace kullanımı veya Docker socket mount edilmesi bu riski daha da büyütür. Güvenli tasarımda container izolasyonuna ek olarak seccomp, capability drop, non-root çalışma ve erişim politikaları uygulanmalıdır.

Konteyner ile Sanal Makine Güvenliği Arasındaki Fark

Sanal makinelerde her VM kendi işletim sistemi kernel'ine sahip olabilirken konteyner mimarisinde süreçler çoğunlukla ortak host kernel üzerinde çalışır. Bu durum konteynerleri çok daha hafif ve hızlı yapar. Aynı özellik güvenlik mimarisinin farklı ele alınmasını gerektirir. Bir container'ın root kullanıcısıyla çalışması, bazı yanlış yapılandırmalarda host açısından beklenenden daha büyük bir risk oluşturabilir. Bu nedenle konteyner ortamlarında namespace, capability, seccomp, AppArmor veya SELinux gibi ek izolasyon katmanları önem kazanır.

Shared Kernel Neden Önemlidir?

Shared kernel yaklaşımı konteyner teknolojisinin performans avantajlarından biridir. Fakat güvenlik açısından host kernel'i bütün container'ların ortak güven sınırlarından biri haline getirir. Container escape olarak adlandırılan saldırılarda saldırgan izole ortamın dışına çıkmaya çalışır. Bu tür saldırıların etkisini azaltmak için container'ları root çalıştırmamak, privileged moda izin vermemek ve host kaynaklarına erişimi sınırlandırmak gerekir. Kernel ve container runtime güncellemelerinin düzenli yapılması da bu nedenle doğrudan güvenlik kontrolüdür.

Container Security Yaşam Döngüsü

Güvenli bir konteyner süreci dört temel noktada kontrol edilmelidir: build, registry, deployment ve runtime. Build aşamasında kullanılan Dockerfile ve bağımlılıklar değerlendirilir. Registry aşamasında imajın kim tarafından yüklenebileceği, imzanın doğrulanıp doğrulanmadığı ve sonradan değiştirilip değiştirilmediği kontrol edilir. Deployment sırasında Kubernetes güvenlik politikaları ve yetkiler devreye girer. Runtime aşamasında ise çalışan süreçlerin beklenen davranıştan sapıp sapmadığı izlenir.

Build

Build aşaması güvenlik zincirinin başlangıç noktasıdır. Burada base image seçimi, dependency sürümleri, Dockerfile talimatları, secret kullanımı ve multi-stage build yapısı değerlendirilmelidir. CI pipeline yalnızca image üretmemeli, aynı zamanda vulnerability scan ve secret scan çalıştırmalıdır. Build çıktısına SBOM eklemek daha sonra ortaya çıkan CVE'lerde hangi paketlerin etkilendiğini anlamayı kolaylaştırır. Üretim imajının yeniden üretilebilir olması için base image sürümü veya digest değeri de sabitlenmelidir.

Registry

Registry yalnızca imajların saklandığı bir depo değildir. Aynı zamanda yazılım tedarik zincirinin kritik kontrol noktalarından biridir. Push yetkisi herkese verilmemeli ve üretimde kullanılacak repository'lerde erişim RBAC ile sınırlandırılmalıdır. İmajların düzenli olarak yeniden taranması önemlidir çünkü bugün güvenli görünen bir paket için yarın yeni bir CVE yayımlanabilir. Immutable tag, image signing ve audit log kullanımı registry güvenliğini önemli ölçüde güçlendirir.

Deployment

Deployment aşamasında güvenli bir image'ın yanlış Kubernetes ayarlarıyla riskli hale gelmesi mümkündür. Örneğin taramadan geçen bir image privileged olarak çalıştırılırsa sahip olduğunuz vulnerability raporu tek başına yeterli olmaz. SecurityContext, runAsNonRoot, allowPrivilegeEscalation, capability drop ve seccomp seçenekleri burada devreye girer. Admission policy kullanarak belirli güvenlik kurallarını manuel tercihten çıkarıp zorunlu hale getirebilirsiniz. Böylece hatalı bir manifest cluster'a ulaşmadan reddedilir.

Runtime

Runtime güvenliği, statik kontrollerin göremediği davranışları yakalamaya çalışır. Bir web servisinin normalde shell çalıştırmaması bekleniyorsa production pod içinde aniden shell açılması anlamlı bir güvenlik sinyalidir. Aynı şekilde hassas sistem dosyalarının okunması, beklenmeyen dış bağlantılar veya kripto madenciliği süreçleri runtime izleme araçlarıyla tespit edilebilir. Falco ve eBPF tabanlı yaklaşımlar bu noktada güçlü görünürlük sağlar. Buradaki amaç her olayı saldırı olarak işaretlemek değil, normal davranıştan anlamlı sapmaları hızlıca fark etmektir.

Konteynerlerde Tehdit Modeli

Konteyner güvenliği tasarlarken önce hangi saldırı yollarına karşı koruma sağladığınızı bilmeniz gerekir. Tehdit modeli image seviyesinden başlayıp build pipeline, registry, runtime ve Kubernetes kontrol düzlemine kadar genişler. Bir saldırgan her zaman doğrudan production pod'a saldırmak zorunda değildir. CI erişimini ele geçirerek zararlı bir paket ekleyebilir veya registry üzerinde değiştirilmiş bir image yayınlayabilir. Bu nedenle güvenlik kontrollerinin yalnızca cluster çevresinde kurulması yeterli değildir.

Image-Level Threats

Image seviyesindeki tehditlerin önemli bölümü kullanılan base image ve paketlerden kaynaklanır. Vulnerable base image, eski bağımlılıklar, image içine gömülmüş credential bilgileri ve zararlı paketler en sık karşılaşılan örneklerdir. Özellikle ortak base image kullanan mikroservis mimarilerinde tek bir zafiyet onlarca servise yayılabilir. Bu nedenle kurum içinde onaylı base image listesi oluşturmak güçlü bir başlangıçtır. Base image güncellendiğinde ona bağlı uygulamaların otomatik rebuild edilmesi güvenlik borcunun büyümesini önler.

Vulnerable Base Image

Bir uygulamanın kendi kodu güvenli olsa bile kullandığı base image içinde kritik bir zafiyet bulunabilir. Örneğin eski bir işletim sistemi paketi network üzerinden sömürülebilen bir açık içeriyorsa bu paket doğrudan uygulamanın saldırı yüzeyine dahil olabilir. Base image seçerken sadece image boyutuna bakmak yeterli değildir. Güncelleme sıklığı, paket kaynağı ve güvenlik desteği de değerlendirilmelidir. Düzenli re-scan yapılmadığında sonradan açıklanan CVE'ler kolayca gözden kaçabilir.

Eski Bağımlılıklar

Uygulamaların kullandığı language dependency'leri de image güvenliğinin parçasıdır. npm, Maven, pip, Go module veya benzeri paket kaynaklarından gelen bağımlılıklar zaman içinde güvenlik açığı barındırabilir. Image scanner bu paketlerin önemli bölümünü inventory üzerinden tespit eder. Ancak raporda görülen her CVE'nin aynı riske sahip olduğunu varsaymak doğru değildir. Paket gerçekten çalışıyor mu, vulnerable kod yoluna erişiliyor mu ve exploit mevcut mu gibi sorularla triage yapılmalıdır.

Gömülü Secret

API anahtarı, registry token, veritabanı parolası veya private key gibi bilgilerin image içine eklenmesi ciddi bir güvenlik problemidir. Daha sonraki Docker layer'ında dosyayı silmek de sorunu her zaman çözmez çünkü veri önceki layer geçmişinde kalabilir. Build secret'ları image filesystem'ine yazılmamalıdır. BuildKit secret mount ve CI secret store gibi yöntemler tercih edilmelidir. Bir secret image geçmişine girdiyse yalnızca image'ı silmek değil, ilgili credential bilgisini değiştirmek gerekir.

Zararlı Paket

Supply chain saldırılarında güvenilir görünen bir dependency içine zararlı kod eklenebilir. Paket adı benzerliği, dependency confusion ve ele geçirilmiş yayıncı hesabı gibi yöntemler bu riskin örnekleridir. Güvenlik taraması bilinen zafiyetleri tespit edebilir fakat zararlı davranış her zaman CVE kaydına sahip olmayabilir. Bu yüzden dependency kaynağı, checksum doğrulaması, provenance ve kontrollü paket repository kullanımı önemlidir. SBOM da image içinde hangi paketlerin bulunduğunu hızlıca görmek için güçlü bir envanter sağlar.

Konteyner İmaj Güvenliği Neden Kritik?

Container image production ortamında çalışacak kodun, işletim sistemi paketlerinin ve bağımlılıkların taşınabilir paketidir. Bir image yüzlerce pod tarafından çalıştırılabilir. Bu yüzden image seviyesindeki tek bir hata yatay olarak çok geniş bir etki oluşturabilir. Mikroservis ortamlarında aynı base image'ın onlarca servis tarafından kullanılması bu etkiyi daha da büyütür. Güvenli image üretimi bu nedenle tek bir uygulamanın değil bütün platformun güvenliğini etkiler.

Container Image Nedir?

Container image, uygulamanın çalışması için gereken filesystem içeriğini ve metadata bilgilerini katmanlar halinde paketler. Dockerfile içindeki talimatlar çoğu zaman bu katmanların oluşmasına katkı sağlar. Image çalıştırıldığında container runtime bu katmanları kullanarak uygulama için izole bir çalışma ortamı oluşturur. Image değişmez kabul edilse de tag değerleri her zaman değişmez değildir. Bu nedenle production deployment'larında mümkün olduğunda digest tabanlı referans kullanmak daha güvenilir bir yöntemdir.

Image Layer'ları Nasıl Çalışır?

Image layer yapısı depolama verimliliği ve yeniden kullanım sağlar. Fakat güvenlik açısından önemli bir sonucu vardır: Bir dosyayı sonraki layer'da silmek, onun daha önceki layer içinde hiç var olmadığı anlamına gelmez. Bu durum özellikle secret bilgilerinde tehlikelidir. Dockerfile tasarlarken build aşamasında hassas veriyi layer içine yazmamak gerekir. Multi-stage build yaklaşımı da build araçlarını ve geçici dosyaları production image'dan uzak tutmak için faydalıdır.

Base Image Riski

Base image uygulamanın güvenlik mirasını belirleyen temel unsurlardan biridir. Yüzlerce paket içeren genel amaçlı bir image, uygulamanın hiç kullanmadığı araçları da yanında taşıyabilir. Her ek paket teorik olarak yeni bir saldırı yüzeyi oluşturur. Bu nedenle production için mümkün olan en küçük ve ihtiyaç odaklı image tercih edilmelidir. Ancak minimal image seçimi yapılırken debug ve operasyon gereksinimleri de planlanmalıdır.

Image İçindeki Bağımlılıkların Saldırı Yüzeyi

Bir image içindeki her dependency güvenlik değerlendirmesinin parçasıdır. İşletim sistemi paketleri, uygulama framework'leri, TLS kütüphaneleri ve yardımcı binary dosyaları ayrı ayrı zafiyet taşıyabilir. Container scanner araçları bu bileşenleri paket envanteri üzerinden analiz eder. Güvenlik ekibi raporu yalnızca CVE sayısına göre değerlendirmemelidir. Exploitability, erişilebilirlik ve çözüm sürümünün bulunup bulunmadığı gibi ek bağlamlar önceliklendirmeyi çok daha anlamlı hale getirir.

Bir Güvensiz Base Image'in Mikroservislere Yayılması

Ortak base image kullanımı operasyon açısından avantajlıdır fakat güvenlik etkisini merkezi hale getirir. Aynı image yirmi mikroserviste kullanılıyorsa kritik bir OpenSSL veya sistem kütüphanesi açığı yirmi servisi birden etkileyebilir. Buna karşılık iyi yönetilen bir golden image yaklaşımı güncelleme sürecini de merkezileştirir. Base image patch edildiğinde bağlı repository'lere otomatik pull request açılması ve yeniden build yapılması güçlü bir modeldir. Böylece merkezi standardizasyon güvenlik avantajına dönüştürülebilir.

Güvenli Base Image Nasıl Seçilir?

Güvenli base image seçimi yalnızca en küçük image'ı bulmak anlamına gelmez. Image'ın kaynağı, bakım durumu, güncelleme sıklığı, içerdiği paketler ve uygulama gereksinimleri birlikte değerlendirilmelidir. Resmî veya doğrulanmış kaynaklardan gelen image'lar tercih edilmeli, kurum içinde kullanılabilecek image'lar için bir allowlist oluşturulmalıdır. Ekiplerin rastgele internet kaynaklarından base image seçmesine izin vermek supply chain riskini büyütür. Kurumsal ortamlarda güvenlik ekibinin düzenli patch ettiği standart base image'lar daha sürdürülebilir bir yaklaşım sağlar.

Minimal Image

Minimal image yaklaşımında uygulamanın çalışması için gerekli olmayan paketler image dışında bırakılır. Shell, compiler, package manager veya network debug araçlarının production container içinde bulunmaması saldırganın kullanabileceği araçları azaltabilir. Bu durum tek başına bir güvenlik garantisi değildir fakat saldırı yüzeyini önemli ölçüde daraltır. Uygulama troubleshooting süreci için ayrı debug container veya ephemeral container kullanılabilir. Böylece production image temiz kalırken operasyon ekibi gerekli gözlem araçlarına kontrollü biçimde erişebilir.

Distroless Image

Distroless image'lar geleneksel Linux dağıtımlarında bulunan birçok kullanıcı alanı aracını içermez. Amaç uygulama runtime'ı dışında gereksiz bileşenleri azaltmaktır. Shell veya package manager bulunmaması bazı saldırı tekniklerini zorlaştırabilir. Bunun karşılığında production ortamında doğrudan container içine girip komut çalıştırmak daha zor hale gelir. Bu nedenle log, metric ve tracing görünürlüğünün image tasarımından önce düşünülmesi gerekir.

Scratch Image

Scratch, mümkün olan en küçük image başlangıç noktalarından biridir ve özellikle statik derlenen uygulamalarda kullanılabilir. Ancak uygulamanın ihtiyaç duyduğu CA certificate, timezone verisi veya runtime dosyalarının ayrıca eklenmesi gerekebilir. Bu nedenle scratch her uygulama için otomatik olarak en doğru seçenek değildir. Güvenlik kararı yalnızca image boyutuna göre verilmemelidir. Çalışma gereksinimleri, bakım kolaylığı ve gözlemlenebilirlik birlikte düşünülmelidir.

Base Image Allowlist

Base image allowlist, ekiplerin yalnızca önceden değerlendirilmiş image kaynaklarını kullanmasını sağlar. Bu liste merkezi CI kontrolleri veya admission policy ile uygulanabilir. Örneğin kurum yalnızca kendi registry alanındaki imajların deployment edilmesine izin verebilir. Bu yaklaşım geliştiricinin yanlışlıkla güvensiz veya sahte bir image kaynağı kullanmasını önler. Allowlist düzenli güncellenmeli ve kullanım dışı image sürümleri listeden çıkarılmalıdır.

Minimal İmaj Kullanımı Saldırı Yüzeyini Nasıl Azaltır?

Image içinde ne kadar az gereksiz bileşen varsa saldırganın yararlanabileceği olası araç ve paket sayısı da o kadar azalır. Production web servisi gcc, curl, wget, package manager ve interaktif shell kullanmıyorsa bu araçların image içinde bulunmasının çoğu zaman bir faydası yoktur. Her paket aynı zamanda patch edilmesi gereken yeni bir bileşen anlamına gelir. Minimal image yaklaşımı vulnerability raporlarındaki gereksiz gürültüyü de azaltabilir. Daha küçük envanter, güvenlik ekibinin gerçekten önemli paketlere odaklanmasını kolaylaştırır.

Gereksiz Paketleri Kaldırmak

Production image içinde paket sayısını azaltmak hem operasyon hem güvenlik bakımından faydalıdır. Dependency eklerken gerçekten runtime gereksinimi olup olmadığı sorgulanmalıdır. Build sırasında kullanılan compiler veya test araçları final image'a taşınmamalıdır. Multi-stage build bunun için pratik bir yöntem sunar. Yine de image küçüldü diye tarama ve runtime kontrolleri bırakılmamalıdır.

Shell'i Production Image'dan Çıkarmak

Bir saldırgan uygulama üzerinden komut çalıştırma yetkisi elde ettiğinde shell onun işini kolaylaştırabilir. Shell bulunmayan bir image saldırıyı tamamen engellemez ancak bazı post-exploitation tekniklerini zorlaştırabilir. Uygulama gerçekten shell'e ihtiyaç duymuyorsa production image'dan çıkarılması düşünülebilir. Debug ihtiyacı için ayrı ve kontrollü araçlar kullanılmalıdır. Kubernetes ephemeral container yaklaşımı bu operasyon modeline yardımcı olabilir.

Image Boyutu ile Güvenlik Arasındaki İlişki

Küçük image her zaman güvenli image değildir. Çok küçük bir image içinde kritik bir zafiyet taşıyan tek bir kütüphane bulunabilir. Büyük image ise gereksiz paketler nedeniyle daha geniş saldırı yüzeyine sahip olabilir. Bu nedenle image boyutu güvenlik göstergelerinden yalnızca biridir. Asıl önemli olan hangi bileşenlerin bulunduğu, nasıl güncellendiği ve çalışma sırasında hangi yetkilerle kullanıldığıdır.

Multi-Stage Docker Build ile Güvenli İmaj Oluşturmak

Multi-stage build, build araçları ile production runtime'ını ayırmanın en etkili Dockerfile tekniklerinden biridir. İlk aşamada compiler, package manager ve development dependency'leri kullanılabilir. İkinci aşamada yalnızca çalışması gereken artifact final image'a kopyalanır. Böylece build sırasında gerekli olan fakat runtime'da hiçbir işlevi olmayan araçlar production ortamına taşınmaz. Bu yaklaşım hem image boyutunu hem de olası saldırı yüzeyini azaltır.

Build Stage

Build stage uygulamanın derlendiği veya paketlendiği bölümdür. Burada compiler, test bağımlılıkları ve build yardımcıları bulunabilir. Bu ortamın production image kadar küçük olması zorunlu değildir. Ancak build secret'larının layer içine yazılmamasına dikkat edilmelidir. Build tamamlandığında final artifact kontrollü biçimde runtime stage'e geçirilmelidir.

Runtime Stage

Runtime stage yalnızca uygulamayı çalıştırmak için gerekli dosyaları taşımalıdır. Build toolchain, source code veya test framework'leri çoğu uygulamada burada gerekli değildir. Non-root kullanıcı tanımı da final stage içinde yapılabilir. Dosya sahipliği COPY --chown gibi yöntemlerle doğru kullanıcıya verilmelidir. Son aşamada image scanner çalıştırılarak final image gerçekten hangi bileşenleri içeriyor kontrol edilmelidir.

Dockerfile Güvenliği

Dockerfile güvenliği container security sürecinin en erken kontrol noktalarından biridir. Hatalı Dockerfile tasarımı daha container çalışmadan risk üretmeye başlar. latest tag kullanımı, root kullanıcı, gereksiz paket kurulumu ve image içine secret kopyalanması sık görülen problemlerdir. Dockerfile lint araçları bu hataların bir bölümünü CI sırasında yakalayabilir. En güçlü yaklaşım ise güvenli bir golden Dockerfile şablonunu ekiplerin varsayılan başlangıç noktası haline getirmektir.

latest Tag Kullanmanın Riski

latest etiketi hangi gerçek image sürümünün kullanılacağını açık biçimde ifade etmez. Aynı tag daha sonra başka bir image'ı gösterebilir ve bu durum reproducibility sorununa yol açar. Bugün test ettiğiniz image ile yarın production'da çekilen image aynı olmayabilir. Güvenlik olayında hangi binary'nin çalıştığını anlamak da zorlaşır. Production deployment'larında immutable sürüm ve tercihen digest kullanmak bu belirsizliği azaltır.

Digest Pinning

Digest pinning, image'ı değiştirilebilir bir isim yerine belirli içerik hash'iyle referans etmektir. SHA-256 digest aynı image içeriğini işaret ettiği için deployment'ın beklenmeyen şekilde başka bir sürüme kaymasını önler. Image signing ile birlikte kullanıldığında hem bütünlük hem kaynak doğrulaması açısından güçlü bir zincir kurulabilir. CI otomasyonu yeni güvenli digest çıktığında manifest güncellemesi yapabilir. Böylece sabitlik ile güncelleme yönetimi birlikte sürdürülebilir.

USER Direktifi

Dockerfile içinde USER direktifi kullanmak container'ın varsayılan olarak root dışı bir kullanıcıyla başlamasını sağlar. Uygulama 80 gibi ayrıcalıklı portlara veya özel kernel yetkilerine ihtiyaç duymuyorsa root kullanımı çoğu zaman gereksizdir. Uygulamanın yazacağı dizinlerin sahipliği bu kullanıcıya göre ayarlanmalıdır. Aksi durumda ekipler dosya izni problemi yaşayıp tekrar root kullanıcısına dönme eğilimi gösterebilir. Bu nedenle non-root tasarım image oluşturulurken planlanmalıdır.

Dockerfile İçinde Secret Tutmamak

Dockerfile içine doğrudan token veya parola yazmak önemli bir güvenlik hatasıdır. ARG ve ENV üzerinden geçirilen değerler de kullanım biçimine göre metadata veya layer geçmişinde iz bırakabilir. Secret gerektiren private dependency indirme işlemlerinde BuildKit secret mount tercih edilebilir. CI/CD sistemi credential bilgisini geçici olarak sağlamalı ve final image içinde bırakmamalıdır. Secret sızıntısı tespit edilirse ilgili anahtarın değiştirilmesi de unutulmamalıdır.

Container Image Scanning Nedir?

Container image scanning, image içinde bulunan işletim sistemi paketlerini, uygulama bağımlılıklarını, configuration hatalarını ve bazen secret bilgilerini otomatik olarak analiz etme sürecidir. Tarayıcı image içeriğinden bir paket envanteri çıkarır ve bunu vulnerability database kayıtlarıyla eşleştirir. Sonuç olarak CVE, severity, etkilenen paket ve mümkünse güvenli sürüm bilgisi raporlanır. Ancak tarama sonucu yalnızca bir risk sinyalidir. Gerçek riskin belirlenmesi için uygulamanın çalışma bağlamı da değerlendirilmelidir.

İmaj Tarayıcı Nasıl Çalışır?

Tarayıcı öncelikle image layer'larını analiz ederek hangi paketlerin bulunduğunu belirler. İşletim sistemi package manager verileri, language dependency dosyaları ve binary metadata bu analizde kullanılabilir. Ardından sürüm bilgileri bilinen CVE kayıtlarıyla eşleştirilir. Bazı araçlar Dockerfile ve Kubernetes manifesti gibi configuration dosyalarını da değerlendirir. Gelişmiş kullanımda secret scanning, license kontrolü ve SBOM üretimi aynı pipeline içinde çalıştırılabilir.

Package Inventory

Doğru package inventory tarama kalitesinin temelidir. Bir image içinde hangi OpenSSL, libc, Java, npm veya Python paketlerinin bulunduğunu bilmeden güvenlik açığı eşleştirmesi yapılamaz. SBOM yaklaşımı da bu envanteri standart bir formatta taşımayı amaçlar. Inventory yalnızca vulnerability scan sırasında değil incident response sırasında da değerlidir. Yeni bir kritik CVE çıktığında hangi image'ların etkilendiği saniyeler içinde sorgulanabilir.

Secret Scanning

Secret scanning image layer'ları veya kaynak dosyaları içinde yanlışlıkla bırakılmış credential bilgilerini bulmayı amaçlar. API key, token, private key ve bazı parola formatları bu kontrole dahil olabilir. Ancak otomatik tarama her secret'ı yakalayamaz. Bu nedenle güvenli secret yönetimi tasarımı tarayıcıdan daha önemlidir. Kural, hassas bilginin image içine hiç girmemesi olmalıdır.

CVE, CVSS ve Güvenlik Açığı Önceliklendirme

Container scanner raporu onlarca hatta yüzlerce CVE üretebilir. Bu noktada ekiplerin yaptığı en yaygın hata bütün açıkları aynı öncelikte ele almaktır. CVSS faydalı bir başlangıç göstergesidir ancak tek başına production riskini ifade etmez. İnternete açık bir serviste çalışan ve public exploit bulunan High seviye açık, kullanılmayan bir paketteki Critical kayıttan daha acil olabilir. Bu yüzden exploitability, reachability, fix durumu, EPSS ve aktif sömürü bilgileri birlikte değerlendirilmelidir.

CVE Nedir?

CVE, kamuya açık biçimde tanımlanmış güvenlik açıkları için kullanılan ortak kimlik sistemidir. Scanner raporlarında CVE kimliği sayesinde farklı araçların aynı zafiyet hakkında konuşması kolaylaşır. Ancak bir CVE'nin image içinde görünmesi uygulamanın kesin olarak sömürülebilir olduğu anlamına gelmez. Paket mevcut olabilir fakat etkilenen fonksiyon hiç kullanılmıyor olabilir. Triage süreci bu nedenle gereklidir.

CVSS Nedir?

CVSS bir güvenlik açığının teknik ciddiyetini puanlamaya yardımcı olur. Attack vector, gerekli ayrıcalık ve kullanıcı etkileşimi gibi faktörler puanı etkiler. Yüksek CVSS değeri güçlü bir risk işareti olsa da işletmenin gerçek bağlamını tamamen anlatmaz. Örneğin yalnızca local erişimle sömürülebilen bir açık, internete açık olmayan özel bir worker içinde daha düşük operasyon önceliğine sahip olabilir. Bu yüzden CVSS kararın başlangıcı olmalı, sonu değil.

EPSS

EPSS bir zafiyetin yakın dönemde sömürülme olasılığı hakkında ek sinyal sağlayabilir. Vulnerability management ekipleri CVSS ile EPSS verisini birlikte kullanarak daha gerçekçi bir önceliklendirme oluşturabilir. Özellikle binlerce CVE içeren kurumsal ortamlarda bu ayrım önemlidir. Düşük ihtimalli kayıtlarla aktif saldırılarda kullanılan açıkları aynı kuyruğa koymak müdahale hızını düşürür. Risk tabanlı yaklaşım güvenlik ekibinin sınırlı zamanını daha iyi kullanmasını sağlar.

CISA KEV

Aktif olarak sömürüldüğü bilinen açıklar vulnerability triage sırasında yüksek öncelik almalıdır. Böyle bir kayıt production'da internet-facing workload üzerinde bulunuyorsa normal patch takvimini beklemek yerine hızlı remediation gerekebilir. SBOM ve deployed image inventory burada çok değerlidir. Hangi image digest'lerinin etkilendiği hızlıca bulunabilir. Sonrasında rebuild, re-scan, re-sign ve redeploy zinciri çalıştırılabilir.

İmaj Tarayıcıların Bulamadığı Riskler

Image scanner güçlü bir kontroldür fakat container security'nin tamamı değildir. Zero-day açıkları vulnerability database'e henüz eklenmemiş olabilir. Uygulama mantığı hataları, runtime sırasında oluşan beklenmeyen process davranışları, yanlış Kubernetes RBAC izinleri veya hatalı NetworkPolicy tasarımı image scan tarafından tespit edilmeyebilir. Bu nedenle taramadan temiz çıkan image için güvenlidir demek doğru değildir. Güvenlik katmanları statik analiz, policy enforcement ve runtime detection ile tamamlanmalıdır.

Tarama Sonucu Neden Tek Başına Güvenlik Kanıtı Değildir?

Bir scanner yalnızca bildiği ve gözlemleyebildiği riskleri raporlayabilir. CVE veritabanında olmayan bir açık sonuçlarda görünmez. Aynı şekilde container root çalışıyorsa veya ServiceAccount gereğinden fazla yetkiliyse image raporunun temiz olması bu problemi çözmez. Üretim güvenliği birkaç kontrolün birlikte çalışmasını gerektirir. Konteyner Güvenliği: İmaj Taraması ve Yetki Sınırlandırma yaklaşımının temel fikri tam olarak budur.

Trivy ile Container Image Taraması

Trivy, container image, filesystem ve configuration gibi farklı hedeflerde güvenlik kontrolü yapabilen yaygın bir açık kaynak güvenlik aracıdır. CI/CD pipeline içine kolayca eklenebilmesi onu özellikle DevSecOps ekipleri için kullanışlı hale getirir. Image vulnerability scan, secret scan, misconfiguration kontrolü ve SBOM üretimi aynı güvenlik akışında birleştirilebilir. Tarama sonucunda belirli severity seviyelerinde pipeline başarısız hale getirilebilir. Ancak güvenlik gate tasarımında exception ve remediation süreçlerinin de tanımlı olması gerekir.

Image Vulnerability Scan

Image taraması sırasında Trivy image içindeki paketleri analiz eder ve bilinen güvenlik açıklarıyla eşleştirir. CI aşamasında Critical veya High zafiyetler için farklı politikalar uygulanabilir. Her High bulguda build'i tamamen durdurmak bazı ekiplerde operasyon yükü oluşturabilir. Bunun yerine fix bulunan, reachable veya aktif sömürü sinyali taşıyan açıklar daha yüksek önceliğe alınabilir. Güvenlik gate'i ekibin risk toleransına göre tasarlanmalıdır.

CI'ı Başarısız Etme

Scanner sonucuna göre pipeline'ı başarısız etmek güvenliği otomatik hale getirir. Ancak kural tasarımı çok katı olursa geliştiriciler güvenlik kontrolünü engel olarak görmeye başlayabilir. Bu nedenle grace period, exception expiration ve false positive yönetimi gibi süreçler baştan tanımlanmalıdır. Güvenlik istisnası sonsuza kadar açık kalmamalıdır. Her exception için sahibi, gerekçesi ve son kullanım tarihi kayıt altına alınmalıdır.

SBOM Oluşturma

Trivy gibi araçlarla build sırasında SBOM üretilmesi image içeriğinin daha görünür hale gelmesini sağlar. SBOM, package adı, sürüm, dependency ve bazı formatlarda license bilgilerini içerebilir. SPDX ve CycloneDX yaygın standartlardandır. Registry'de image ile SBOM bilgisinin ilişkilendirilmesi incident response süresini azaltır. Yeni CVE çıktığında bütün image'ları baştan manuel incelemek yerine etkilenen paketleri merkezi envanterde arayabilirsiniz.

Docker Scout ile İmaj Güvenliği

Docker Scout image içeriğini ve dependency yapısını güvenlik perspektifiyle değerlendirmek için kullanılabilen bir araç setidir. Base image önerileri, CVE görünürlüğü, SBOM tabanlı analiz ve policy değerlendirmesi gibi özellikler container güvenlik sürecine ek bağlam kazandırabilir. Özellikle Docker tabanlı geliştirme akışlarında geliştirici geri bildiriminin erken verilmesi değerlidir. Araç seçerken tek başına özellik listesine bakmak yerine mevcut CI/CD, registry ve raporlama sistemleriyle uyum değerlendirilmelidir. Container image vulnerability scanning araçları ve güvenlik politikaları birlikte tasarlandığında daha anlamlı sonuç verir.

Trivy, Grype, Docker Scout ve Snyk Karşılaştırması

Container scanner seçerken herkes için tek doğru araç yoktur. Trivy geniş kapsamlı açık kaynak özellikleri ve CI kullanım kolaylığıyla öne çıkabilir. Grype özellikle SBOM ekosistemiyle birlikte çalışan ekipler için güçlü bir seçenek olabilir. Docker Scout Docker merkezli geliştirme deneyimiyle uyumlu senaryolarda tercih edilebilir. Snyk Container ise daha geniş uygulama güvenliği ve kurumsal yönetim süreçleriyle birlikte değerlendirilmek istenebilir.

Hangi Araç Hangi Ekip İçin Uygun?

Küçük ekipler kurulumu kolay ve otomasyona hızlı bağlanan araçlara öncelik verebilir. Kubernetes ekipleri yalnızca image scan değil manifest ve cluster configuration kontrollerini de birlikte düşünmelidir. Kurumsal DevSecOps ortamlarında merkezi policy, audit, exception yönetimi ve raporlama ihtiyacı daha yüksektir. Regülasyon gerektiren yapılarda sonuçların saklanması, SBOM üretimi, imza doğrulaması ve değişiklik geçmişi önem kazanır. Araç seçimi organizasyonun güvenlik işletim modeline göre yapılmalıdır.

İmajlar Ne Zaman Taranmalıdır?

En doğru cevap bir kez değil, birden fazla noktada şeklindedir. Developer bilgisayarında erken geri bildirim alınabilir. Pull request sırasında kaynak ve dependency kontrolleri çalıştırılabilir. Image build tamamlandıktan sonra final artifact taranmalı, registry içinde de düzenli re-scan yapılmalıdır. Production'da yeni bir CVE açıklandığında çalışan digest envanteri üzerinden etkilenen workload'lar tekrar değerlendirilmelidir.

Build-Time Scan Neden Yeterli Değildir?

Bir image bugün build edildiğinde vulnerability database içinde eşleşen kritik kayıt bulunmayabilir. Aynı image iki hafta sonra açıklanan yeni bir CVE nedeniyle riskli hale gelebilir. Image değişmediği halde güvenlik durumu değişmiştir. Bu nedenle registry re-scanning ve deployed image inventory gereklidir. Sürekli vulnerability monitoring yaklaşımı eski image'ların görünmez güvenlik borcuna dönüşmesini engeller.

CI/CD Pipeline'a İmaj Taraması Nasıl Eklenir?

Güvenli pipeline sıralaması kaynak kodun alınmasıyla başlar ve deployment sonrasında da devam eder. Docker build sonrasında vulnerability scan, secret scan ve misconfiguration scan çalıştırılabilir. Ardından SBOM üretilir, policy evaluation yapılır ve yalnızca politikayı geçen image imzalanır. Signed image registry'ye gönderildikten sonra admission kontrolü imzayı doğrulayabilir. Böylece build ile deployment arasında doğrulanabilir bir güven zinciri oluşur.

Security Policy Gate

Security gate yalnızca Critical CVE sayısına göre karar veren basit bir kural olmak zorunda değildir. Fix mevcut mu, exploit var mı, workload internete açık mı ve zafiyet reachable mı gibi faktörler hesaba katılabilir. Bazı güvenlik açıkları için kısa grace period tanımlanabilir. Ancak exception kaydı otomatik olarak sona ermelidir. Audit trail sayesinde hangi image'ın hangi gerekçeyle deployment'a izin aldığı daha sonra görülebilir.

Vulnerability Triage Nasıl Yapılır?

Triage sürecinde ilk soru CVE'nin gerçekten final image içinde bulunup bulunmadığıdır. Ardından etkilenen paketin çalışan uygulama tarafından kullanılıp kullanılmadığı değerlendirilir. Vulnerable kod yoluna dışarıdan erişim mümkün mü, public exploit var mı ve güvenli sürüm mevcut mu gibi sorular önceliği belirler. İnternete açık bir workload için risk değerlendirmesi internal batch job'dan farklı olabilir. Compensating control varsa geçici risk azaltımı yapılabilir ancak kalıcı remediation hedefi korunmalıdır.

VEX Nedir?

VEX, bir ürün veya artifact içindeki bilinen zafiyetin gerçekten etkili olup olmadığına ilişkin bağlam sağlamaya yardımcı olur. Bir SBOM paketin mevcut olduğunu söyleyebilir, fakat VEX kaydı bu paketteki belirli zafiyet için affected veya not affected değerlendirmesi taşıyabilir. Bu yaklaşım büyük vulnerability raporlarında false positive gürültüsünü azaltır. Ancak VEX güvenlik açığını gizlemek için kullanılmamalıdır. Kararın teknik gerekçesi izlenebilir ve denetlenebilir olmalıdır.

SBOM Nedir?

Software Bill of Materials, bir yazılım artifact'ının hangi bileşenlerden oluştuğunu gösteren yapılandırılmış envanterdir. Package adı, version, dependency ilişkileri ve license bilgileri bu envanterde bulunabilir. SPDX ve CycloneDX gibi standartlar farklı araçların aynı veri üzerinde çalışmasını kolaylaştırır. Build sırasında SBOM üretmek ve image digest ile ilişkilendirmek güçlü bir pratik oluşturur. Özellikle yaygın bir kütüphanede kritik açık çıktığında etkilenen image'ları hızlıca bulmak mümkün hale gelir.

Image Provenance Nedir?

Provenance bir container image'ın nereden geldiğini açıklayan kanıt zinciridir. Hangi source commit'ten üretildiği, hangi pipeline'ın build yaptığı ve hangi base image'ın kullanıldığı gibi bilgiler bu bağlamda değerlidir. SBOM bize image'ın içinde ne olduğunu söylerken provenance image'ın nasıl üretildiğine odaklanır. İkisi birlikte supply chain güvenliğini güçlendirir. SLSA benzeri yaklaşımlar build sürecinin güvenilirliğini sistematik biçimde ele almak için kullanılabilir.

Container Image Signing Nedir?

Image signing bir image'ın belirli bir kaynak tarafından imzalandığını ve imzadan sonra içeriğinin değiştirilmediğini doğrulamaya yardımcı olur. İmza, image'ın zafiyetsiz olduğunu kanıtlamaz. Vulnerability scan ve signature farklı güvenlik sorularına cevap verir. Scanner image içindeki bilinen riskleri incelerken signature authenticity ve integrity kontrolüne katkı sağlar. Güçlü bir deployment politikası bu iki kontrolü birlikte kullanabilir.

Cosign ile Container Image İmzalama

Cosign container artifact imzalama ve doğrulama süreçlerinde kullanılabilen bir araçtır. Key-based veya keyless signing modelleri farklı operasyon ihtiyaçlarına göre uygulanabilir. Pipeline build ve tarama aşamalarını tamamladıktan sonra image digest imzalanabilir. Kubernetes admission aşamasında bu imza doğrulanarak yalnızca güvenilir kaynaklardan gelen image'ların çalışmasına izin verilebilir. Bu yaklaşım supply chain saldırılarında değiştirilmiş veya kaynağı belirsiz image kullanımını azaltır.

Tag Yerine Digest Kullanmak Neden Daha Güvenlidir?

Tag insan tarafından okunması kolay bir etikettir ancak çoğu registry'de değiştirilebilir. Aynı production etiketi bugün bir image'ı, yarın başka bir image'ı gösterebilir. Digest ise belirli image içeriğinin hash değeridir. Deployment digest ile sabitlendiğinde hangi artifact'ın çalışacağı netleşir. İmza doğrulamasıyla birlikte kullanıldığında güven zinciri daha güçlü hale gelir.

Container Registry Güvenliği

Registry güvenliği authentication, authorization, tarama, imza ve loglama kontrollerinin birlikte uygulanmasını gerektirir. Push yetkisi yalnızca build pipeline veya sınırlı servis hesaplarına verilmelidir. İnsan kullanıcıların production repository'lerine doğrudan push yapması mümkün olduğunca engellenmelidir. Immutable tag veya digest tabanlı deployment kullanılabilir. Audit logging sayesinde hangi kullanıcının hangi image üzerinde işlem yaptığı daha sonra incelenebilir.

Least Privilege İlkesi Nedir?

Least privilege, bir kullanıcıya veya workload'a yalnızca görevini yerine getirmesi için gereken minimum yetkinin verilmesidir. Container security içinde bu prensip Linux capability'lerinden Kubernetes RBAC izinlerine kadar uygulanabilir. Bir uygulama yalnızca belirli bir API'ye bağlanıyorsa geniş network erişimine ihtiyaç duymayabilir. Bir ServiceAccount sadece ConfigMap okuyorsa secret silme yetkisi almamalıdır. Minimum yetki yaklaşımı başarılı saldırı durumunda blast radius değerini azaltır.

Container'ları Neden Root Olarak Çalıştırmamalıyız?

Root kullanıcı container içinde çok geniş yetkilere sahiptir. İzolasyon katmanında başka bir güvenlik açığı bulunduğunda root ayrıcalıkları saldırının etkisini büyütebilir. Bu nedenle uygulama ihtiyaç duymuyorsa root olmayan özel bir UID ile çalışmalıdır. Dockerfile USER direktifi ve Kubernetes SecurityContext birlikte kullanılabilir. Dosya izinleri uygulamanın gerçek çalışma kullanıcısına göre tasarlanmalıdır.

Kubernetes'te Non-Root Çalıştırma

Kubernetes'te runAsNonRoot ayarı container'ın UID 0 ile başlamasını engellemek için kullanılabilir. runAsUser ve runAsGroup değerleri workload için belirli kullanıcı ve grup kimlikleri tanımlar. fsGroup bazı volume izinlerinin uygulama tarafından kullanılmasını kolaylaştırabilir. Pod-level ve container-level SecurityContext ayarlarının öncelikleri doğru anlaşılmalıdır. Kubernetes RBAC least privilege rootless container ve runtime security nasıl uygulanır sorusunun önemli cevaplarından biri bu SecurityContext modelidir.

Privileged Container Nedir?

Privileged container normal container sınırlarının önemli bir bölümünü gevşetebilir ve host üzerinde çok geniş erişim sağlayabilir. Bu nedenle genel uygulama workload'larında privileged: true kullanılmamalıdır. Bazı düşük seviyeli sistem araçları özel durumlarda ek yetki isteyebilir, fakat önce tek tek Linux capability vermek değerlendirilmelidir. Gerekli yetki mümkün olan en dar kapsamda verilmelidir. Admission policy ile privileged pod'ların varsayılan olarak reddedilmesi güçlü bir güvenlik kontrolüdür.

Linux Capabilities Nedir?

Linux capabilities root yetkilerini daha küçük parçalara ayırmaya yardımcı olur. Bir uygulamanın yalnızca belirli bir kernel yeteneğine ihtiyacı varsa bütün root ayrıcalıklarını vermek yerine ilgili capability eklenebilir. CAP_NET_BIND_SERVICE nispeten dar bir ihtiyaca cevap verebilirken CAP_SYS_ADMIN çok geniş yetkiler taşıdığı için yüksek risklidir. Production workload'larında önce bütün gereksiz capability'leri düşürmek iyi bir varsayılandır. Daha sonra gerçekten gereken capability test edilerek eklenebilir.

Capability Drop ile Yetki Sınırlandırma

Docker ortamında cap-drop=ALL, Kubernetes tarafında ise capabilities.drop altında ALL kullanımı güçlü bir başlangıç noktasıdır. Bu yöntem container'ın varsayılan capability setini azaltır. Uygulama çalışmıyorsa gerçekten ihtiyaç duyduğu capability belirlenip yalnızca o eklenebilir. Bu gereksinim dokümante edilmelidir. Böylece gelecekte neden özel bir capability verildiği ekip tarafından anlaşılabilir.

Privilege Escalation Nasıl Engellenir?

Privilege escalation, çalışan sürecin başlangıçta sahip olmadığı ek ayrıcalıklara ulaşması anlamına gelir. Setuid ve setgid binary dosyaları bazı senaryolarda bu riski artırabilir. Kubernetes'te allowPrivilegeEscalation: false önemli bir kontroldür. Docker tarafında no-new-privileges seçeneği benzer hedefe katkı sağlar. Bu ayarlar capability drop ve non-root kullanımla birlikte uygulandığında daha güçlü sonuç verir.

Read-Only Root Filesystem Kullanımı

readOnlyRootFilesystem seçeneği container'ın kök filesystem'ine çalışma sırasında yazmasını engeller. Bu kontrol zararlı dosya bırakma ve configuration tampering gibi davranışları zorlaştırabilir. Uygulamanın gerçekten yazması gereken /tmp veya cache dizinleri ayrı volume ile sağlanabilir. Kubernetes emptyDir veya memory tabanlı geçici volume seçenekleri bu amaçla kullanılabilir. Logların container filesystem'inde tutulması yerine stdout ve stderr üzerinden merkezi log sistemine gönderilmesi daha sağlıklı bir operasyon modeli oluşturur.

Merkezi log yönetiminin container operasyonlarıyla ilişkisini daha ayrıntılı incelemek için https://www.diyarbakiryazilim.com.tr/posts/log-yonetimi-elasticsearch-logstash-ve-kibana-elk-kurulumu adresindeki içeriğe göz atabilirsiniz. Runtime security alarmı üretmek tek başına yeterli değildir. Olay sırasında pod logları, uygulama logları ve güvenlik uyarıları aynı zaman çizelgesinde incelenebilmelidir. Merkezi log mimarisi incident response sırasında ekiplerin olayın nasıl geliştiğini anlamasını kolaylaştırır. Özellikle kısa ömürlü container'larda logların container yaşam süresinden bağımsız saklanması önemlidir.

Seccomp ile Sistem Çağrılarını Sınırlandırmak

Seccomp Linux system call yüzeyini sınırlandırmak için kullanılabilir. Uygulama bütün kernel çağrılarına ihtiyaç duymaz. Kubernetes'te RuntimeDefault profili birçok workload için iyi bir başlangıç noktası sunar. Unconfined kullanım ise koruma katmanını devre dışı bırakır. Daha özel güvenlik gereksinimleri bulunan uygulamalar için custom seccomp profilleri oluşturulabilir.

AppArmor ve SELinux ile Konteyner Güvenliği

AppArmor ve SELinux processlerin dosya ve sistem kaynaklarına erişimini ek güvenlik politikalarıyla sınırlandırabilir. Seccomp sistem çağrılarına odaklanırken bu mekanizmalar kaynak erişiminde farklı kontrol katmanları sunar. Host işletim sistemi ve container runtime desteğine göre uygulanacak yöntem değişebilir. Tek bir kontrolü yeterli görmek yerine defense in depth yaklaşımı kullanılmalıdır. Non-root kullanıcı, capability azaltma, seccomp ve MAC politikaları birlikte daha güçlü izolasyon sağlar.

Rootless Docker Nedir?

Rootless Docker, Docker daemon ve container süreçlerinin root ayrıcalığı olmadan çalıştırılmasını hedefleyen bir modeldir. Geleneksel root daemon yapısında daemon erişiminin ele geçirilmesi host üzerinde ciddi etki oluşturabilir. Rootless mode bu riskin bir bölümünü azaltır. User namespace kullanımı container içindeki kullanıcı kimliklerini host üzerindeki farklı UID değerleriyle eşleyebilir. Bununla birlikte networking, düşük portlar ve bazı storage senaryolarında operasyon sınırlamaları değerlendirilmelidir.

Docker Socket Neden Tehlikelidir?

/var/run/docker.sock mount edilmesi container içinden Docker daemon üzerinde geniş kontrol sağlayabilir. Bir saldırgan bu socket erişimini ele geçirirse yeni privileged container oluşturmak veya host filesystem'ini mount etmek gibi tehlikeli işlemler yapabilir. Bu nedenle uygulama pod'larına Docker socket vermek güçlü bir anti-pattern olarak değerlendirilmelidir. CI runner tasarımında da aynı risk dikkate alınmalıdır. Build ihtiyacı için daha izole ve sınırlı çözümler tercih edilmelidir.

Host Namespace Kullanımının Riskleri

hostNetwork, hostPID ve hostIPC gibi ayarlar container'ı host ortamına daha fazla yaklaştırır. Bazı sistem workload'ları için gerçekten gerekli olabilirler. Fakat standart uygulama deployment'larında bu seçeneklerin varsayılan olarak kapalı olması daha güvenlidir. Host PID namespace paylaşımı diğer process bilgilerine erişim riskini artırabilir. Admission policy ile bu ayarların yalnızca belirli namespace veya ServiceAccount'lara izin verilmesi mümkündür.

HostPath Volume Neden Risklidir?

HostPath volume container'a node filesystem'indeki belirli bir dizini açar. Hassas path'lerin yazılabilir mount edilmesi container escape etkisine yakın sonuçlar üretebilir. Özellikle Docker socket, host configuration dizinleri veya sistem dosyaları yüksek risklidir. Mümkün olduğunda Kubernetes'in daha izole volume türleri tercih edilmelidir. HostPath gerçekten gerekiyorsa path kapsamı ve read-only seçeneği dikkatle sınırlandırılmalıdır.

Container Resource Limitleri Güvenlikle Nasıl İlişkilidir?

CPU, memory ve ephemeral storage limitleri yalnızca performans yönetimi değildir. Kaynak sınırı olmayan bir container yanlış kod veya kötü niyetli işlem nedeniyle node kaynaklarını tüketebilir. Fork bomb, memory exhaustion ve disk doldurma davranışları diğer workload'ları etkileyebilir. Kubernetes ResourceQuota ve LimitRange gibi kontroller namespace seviyesinde ek koruma sağlar. Güvenlik tasarımında availability de korunması gereken temel özelliklerden biridir.

Kubernetes Pod Security Standards Nedir?

Pod Security Standards Kubernetes workload'ları için temel güvenlik seviyelerini tanımlamaya yardımcı olur. Privileged profil çok geniş izinlere olanak verirken Baseline bilinen yüksek riskli bazı ayarları sınırlar. Restricted profil daha güçlü hardening kontrolleri uygular. Production uygulamalarında mümkün olan workload'lar için Restricted hedeflenebilir. Legacy uygulamalarda önce audit ve warn moduyla uyumsuzluklar bulunup daha sonra enforcement'a geçmek daha sağlıklı olabilir.

Restricted Pod Security Standard

Restricted profil non-root çalışma, privilege escalation engelleme, capability sınırlama ve seccomp gibi önemli kontrolleri destekler. Amaç sıradan uygulama workload'larının host üzerinde gereksiz ayrıcalık kazanmasını önlemektir. Bazı eski image'lar bu profile geçerken dosya izni veya root kullanıcı bağımlılığı nedeniyle sorun yaşayabilir. Bu durum policy'yi kapatmak yerine image'ın düzeltilmesi için fırsat olarak görülmelidir. Secure-by-default platform yaklaşımı ekiplerin yeni uygulamalarda bu standardı otomatik kullanmasını sağlayabilir.

Pod Security Admission Nasıl Çalışır?

Pod Security Admission namespace seviyesindeki etiketler üzerinden enforce, audit ve warn davranışlarını uygulayabilir. Yeni bir politika devreye alınırken doğrudan enforce yapmak üretim kesintisi oluşturabilir. Önce audit ile uyumsuz workload'lar belirlenebilir. Daha sonra warn ile geliştiricilere geri bildirim verilir. Hazırlık tamamlandığında Restricted veya seçilen güvenlik profili enforce edilebilir.

Kubernetes RBAC ile Yetki Sınırlandırma

Kubernetes RBAC Role, ClusterRole, RoleBinding ve ClusterRoleBinding kaynakları üzerinden API erişimini kontrol eder. Least privilege tasarımında wildcard izinlerinden mümkün olduğunca kaçınılır. Bir uygulamanın list veya get yetkisine ihtiyacı varsa create, patch ve delete izinleri eklenmemelidir. ClusterRoleBinding kullanımı cluster genelinde etki oluşturduğu için dikkatli yönetilmelidir. RBAC değişiklikleri audit edilmeli ve düzenli olarak kullanılmayan izinlar temizlenmelidir.

Kubernetes ServiceAccount Güvenliği

Her workload için ayrı ServiceAccount kullanmak izin sınırlandırmasını kolaylaştırır. Default ServiceAccount üzerine geniş yetkiler tanımlamak namespace içindeki birçok pod'u gereksiz yere yetkili hale getirebilir. API erişimine ihtiyaç duymayan workload'larda otomatik token mount edilmesi engellenebilir. Cloud ortamlarında statik credential yerine workload identity veya benzer kısa ömürlü kimlik mekanizmaları tercih edilmelidir. ServiceAccount izinları uygulamanın gerçek API ihtiyacına göre düzenlenmelidir.

NetworkPolicy ile Lateral Movement Nasıl Engellenir?

Kubernetes cluster içinde pod iletişimi varsayılan ağ modeline göre oldukça açık olabilir. Bir pod ele geçirildiğinde saldırgan diğer servisleri taramaya veya erişmeye çalışabilir. Default-deny NetworkPolicy ile başlangıçta trafik engellenip yalnızca gerekli ingress ve egress yolları açılabilir. DNS erişimi gibi temel ihtiyaçlar unutulmamalıdır. Servisler arası iletişimi ihtiyaç bazlı tanımlamak lateral movement riskini azaltır.

Secret'lar Container Image İçinde Neden Tutulmamalıdır?

Secret image içine bir kez yazıldığında yalnızca çalışan container içinde değil image history ve registry kopyalarında da bulunabilir. ENV veya ARG kullanımı da güvenli secret store yerine geçmez. COPY ile eklenen secret sonraki layer'da silinse bile eski katmanda kalabilir. Bu nedenle build işlemi hassas veriyi final artifact'a hiç yazmamalıdır. Sızıntı fark edilirse ilgili credential hemen rotate edilmelidir.

Build Sırasında Secret Nasıl Kullanılır?

BuildKit secret mount build sırasında gerekli credential bilgisini geçici olarak sunmak için kullanılabilir. Örneğin private dependency repository token'ı package indirme komutuna sağlanabilir ancak image layer içine yazılmaz. CI platformunun secret store özelliği bu değerlerin kaynak koddan ayrı tutulmasını sağlar. Registry credential bilgileri de pipeline yetkisiyle sınırlanmalıdır. Log çıktılarında secret değerlerinin görünmemesi ayrıca kontrol edilmelidir.

Runtime Secret Management

Runtime sırasında secret yönetimi Kubernetes Secrets, harici secret manager sistemleri veya cloud tabanlı secret hizmetleri üzerinden yapılabilir. Kubernetes Secrets kullanılıyorsa encryption at rest ve RBAC ayarları değerlendirilmelidir. Workload yalnızca ihtiyaç duyduğu secret'a erişebilmelidir. Uzun ömürlü sabit credential yerine rotasyon yapılabilen kısa ömürlü erişimler tercih edilmelidir. Secret rotation süreci uygulama kesintisine yol açmadan test edilmelidir.

Policy as Code ile Container Güvenliği

Policy as Code güvenlik kurallarını yazılı ve otomatik uygulanabilir hale getirir. Root container yasaklamak, approved registry zorunluluğu getirmek veya resource limit istemek manuel code review kararından çıkarılabilir. Kubernetes admission control bu kuralları deployment öncesinde uygulamak için uygun bir noktadır. Kyverno, OPA Gatekeeper ve ValidatingAdmissionPolicy gibi seçenekler farklı ihtiyaçlara göre kullanılabilir. GitOps yaklaşımıyla policy değişiklikleri de pull request ve review sürecine dahil edilebilir.

Admission Policy ile Hangi Kurallar Zorunlu Kılınabilir?

Admission katmanında root container, privileged pod, eksik capability drop veya HostPath kullanımı reddedilebilir. Image'ın yalnızca onaylı registry'den gelmesi şart koşulabilir. Digest pinning ve signature verification politikaları supply chain güvenliğini güçlendirir. Resource limits olmayan workload'ların deployment edilmemesi sağlanabilir. Böylece güvenlik kuralları dokümanda kalan öneriler yerine platform davranışına dönüşür.

İmzasız Container Image Deployment'ı Nasıl Engellenir?

Build pipeline güvenlik kontrollerinden geçen image'ı imzalayabilir. İmza registry'deki artifact ile ilişkilendirilir. Admission controller deployment isteği geldiğinde image imzasını doğrular. Signature verification başarısızsa pod oluşturulmaz. Bu model, kaynağı doğrulanmamış image'ların production cluster'a ulaşmasını engelleyen güçlü bir supply chain kontrolüdür.

Runtime Container Security Nedir?

Static scan image içinde ne bulunduğunu gösterir, runtime security ise çalışırken ne olduğunu gözlemler. Beklenmeyen process başlatılması, shell spawn, hassas dosya erişimi veya şüpheli network bağlantısı önemli sinyaller olabilir. Crypto mining süreçleri ve privilege escalation denemeleri de runtime seviyesinde tespit edilebilir. Bu sinyaller Kubernetes metadata ile zenginleştirildiğinde hangi namespace, pod ve image digest'in olayla ilişkili olduğu daha hızlı anlaşılır. Runtime monitoring incident response için güçlü bir görünürlük katmanı oluşturur.

Falco ile Runtime Threat Detection

Falco system call ve runtime olaylarından güvenlik sinyali üretmek için kullanılan açık kaynak bir projedir. Kurallar beklenmeyen shell açılması, hassas dosya erişimi veya alışılmadık process davranışı gibi olayları tespit etmek için yazılabilir. Her alarmın aynı öncelikte değerlendirilmesi gereksiz gürültü oluşturabilir. Kurallar workload davranışına göre uyarlanmalıdır. Alarm çıktılarının merkezi log ve incident management süreçlerine bağlanması operasyonel değeri artırır.

eBPF Tabanlı Runtime Güvenlik

eBPF kernel seviyesinde yüksek görünürlük sağlayabilen güçlü bir Linux teknolojisidir. Process execution, network bağlantıları ve çeşitli kernel olayları hakkında detaylı telemetry üretilebilir. Tetragon gibi projeler eBPF tabanlı runtime gözlem ve enforcement senaryolarında kullanılabilir. Falco ile eBPF tabanlı çözümler bazı alanlarda kesişse de yaklaşım ve veri modeli farklı olabilir. Araç seçerken cluster ölçeği, gözlem ihtiyacı ve operasyon ekibinin yönetim kapasitesi değerlendirilmelidir.

Container Security için DevSecOps Yaklaşımı

DevSecOps güvenlik kontrolünü deployment öncesindeki son kapıdan çıkarıp bütün geliştirme akışına dağıtır. Developer hızlı geri bildirim alır, CI security gate uygular, registry image'ları yeniden tarar ve Kubernetes admission policy güvenli olmayan deployment'ı engeller. Runtime detection ise üretimde kalan bilinmeyen riskleri gözlemler. Bu zincirin sonucu tekrar developer'a dönmelidir. Böylece güvenlik tek seferlik proje değil sürekli iyileşen bir mühendislik süreci haline gelir.

Güvenlik Kontrolleri Developer Deneyimini Bozmadan Nasıl Uygulanır?

Güvenlik kontrolleri geliştiriciye yalnızca hata mesajı gösterirse ekip tarafından engel olarak algılanabilir. Secure-by-default template, golden Dockerfile ve approved base image gibi yaklaşımlar doğru seçeneği kolay seçenek haline getirir. Merkezi CI template sayesinde her repository'nin güvenlik pipeline'ını sıfırdan yazması gerekmez. Tarayıcı çıktısında mümkünse fix sürümü ve net remediation önerisi gösterilmelidir. Platform engineering yaklaşımı güvenliği self-service geliştirme deneyiminin parçası haline getirebilir.

Golden Image Yaklaşımı

Kurum içinde standart base image kullanılması güvenlik patch sürecini merkezileştirir. Golden image non-root varsayılan kullanıcı, gerekli certificate dosyaları ve ortak güvenlik ayarlarıyla hazırlanabilir. Yeni güvenlik güncellemesi geldiğinde merkezi image yeniden oluşturulur. Bağlı uygulamalara otomatik update pull request'i açılabilir. Böylece her takım aynı güvenlik sorununu ayrı ayrı çözmek zorunda kalmaz.

Yeni Kritik CVE Çıktığında Ne Yapılmalıdır?

İlk adım vulnerability feed üzerinden açığın kapsamını anlamaktır. SBOM envanteri kullanılarak etkilenen package sürümünü içeren image'lar bulunur. Daha sonra production workload inventory üzerinden hangi digest'lerin gerçekten çalıştığı belirlenir. Exploitability ve internet erişimi gibi faktörlerle aciliyet değerlendirilir. Fix varsa base image güncellenir, image rebuild edilir, tekrar taranır, imzalanır ve kontrollü biçimde redeploy edilir.

Konteyner Güvenliği Incident Response

Şüpheli container davranışı tespit edildiğinde ilk hedef olayın yayılmasını durdurmaktır. Network erişimi kesilebilir veya workload izole edilebilir. Ancak container hemen silinmeden önce gerekli audit ve runtime loglarının korunması önemlidir. Olayda kullanılan image digest ve ServiceAccount bilgisi tespit edilmelidir. Credential sızıntısı ihtimali varsa ilgili secret'lar rotate edilmeli ve temiz, doğrulanmış image ile redeploy yapılmalıdır.

Container Güvenliği Nasıl Ölçülür?

Güvenliği ölçmeden geliştirmek zordur. Critical ve fixable CVE sayısı, mean time to remediate, root çalışan container oranı ve privileged workload sayısı faydalı metriklerdir. Signed image oranı, SBOM coverage ve policy compliance rate supply chain olgunluğunu gösterir. Ortalama base image yaşı da patch disiplininin önemli bir sinyalidir. Metriklerin amacı ekipleri cezalandırmak değil risk eğilimlerini görünür kılmaktır.

Uçtan Uca Güvenli Docker Image Örneği

Pratik bir güvenli image akışı minimal ve güvenilir base image seçimiyle başlar. Multi-stage build kullanılır ve final image içine yalnızca runtime artifact kopyalanır. Uygulama özel bir non-root kullanıcıyla çalışır ve embedded secret içermez. Build tamamlandığında Trivy veya benzeri scanner ile vulnerability kontrolü yapılır ve SBOM oluşturulur. Policy gate geçen image imzalanır ve yalnızca yetkili registry repository'sine push edilir.

Uçtan Uca Güvenli Kubernetes Deployment Örneği

Kubernetes deployment digest-pinned image kullanarak başlamalıdır. SecurityContext içinde runAsNonRoot etkinleştirilebilir, allowPrivilegeEscalation false yapılabilir ve ALL capabilities düşürülebilir. readOnlyRootFilesystem ve RuntimeDefault seccomp profili ek koruma sağlar. Workload'a dedicated ServiceAccount ve minimum RBAC yetkisi verilir. NetworkPolicy, resource limits ve Restricted Pod Security yaklaşımıyla deployment güvenliği tamamlanır.

Production Container Security Pipeline Örneği

Developer commit sonrasında Dockerfile lint çalıştırılır ve image build edilir. Secret scan, vulnerability scan ve IaC scan sonuçları security policy gate tarafından değerlendirilir. SBOM üretilir ve başarılı artifact imzalanır. Registry'ye gönderilen image deployment sırasında admission control ile yeniden doğrulanır. Production ortamında runtime monitoring ve continuous re-scanning güvenlik zincirini sürdürür.

Container Security Araç Seti

Container güvenlik ekosisteminde farklı problemlere odaklanan birçok araç bulunur. Trivy ve Grype vulnerability scanning için, Syft SBOM üretimi için, Cosign image signing için kullanılabilir. Kyverno ve OPA Gatekeeper Kubernetes policy enforcement tarafında öne çıkan yaklaşımlardır. Falco ve Tetragon runtime görünürlüğü sağlar. Hadolint, Checkov ve Kubescape gibi araçlar Dockerfile, IaC veya Kubernetes configuration güvenliğine katkıda bulunabilir.

Open Source Container Security Ekosistemi

Açık kaynak projeler container security ekosisteminin önemli bölümünü oluşturur. Scanner veritabanları, SBOM araçları, policy örnekleri ve runtime rule'ları topluluk katkısıyla gelişir. Sigstore ekosistemi yazılım artifact imzalama ve doğrulama süreçlerinde önemli bir yapı sunar. CNCF çatısı altında güvenlik odaklı birçok proje bulunur. Ekiplerin yalnızca araç kullanması değil issue, dokümantasyon ve rule katkısı yapması da bilgi seviyesini güçlendirir.

Open Source ve İşbirliği Konteyner Güvenliğini Nasıl Geliştirir?

CVE bildirimleri, scanner rule geliştirme ve policy paylaşımı topluluk sayesinde daha hızlı ilerleyebilir. Falco rule veya Kyverno policy örnekleri gerçek kullanım problemlerinin tekrar tekrar çözülmesini önler. GitHub issue ve pull request süreçlerine katılmak geliştiricilere security engineering konusunda pratik deneyim kazandırır. Güvenlik açığı bulan kişilerin responsible disclosure yaklaşımını takip etmesi önemlidir. Açık kaynak güvenlik araçlarına katkı kariyer gelişimi açısından da güçlü bir uygulama alanıdır.

Konteyner Güvenliği İçin En İyi Programlama Dili Hangisidir?

Container security için tek bir en iyi programlama dili yoktur. Bash otomasyon ve hızlı script ihtiyaçlarında, Python API entegrasyonu ve analiz işlerinde, Go ise cloud-native araç geliştirmede sık kullanılabilir. Kubernetes manifestleri için YAML, policy senaryolarında ise Rego gibi dillerle karşılaşabilirsiniz. Fakat dilden daha önemli olan Linux, networking, container runtime ve Kubernetes güvenlik modelini anlamaktır. Araç yazabilmek değerlidir, fakat yanlış SecurityContext'i okuyamayan bir uzman için yalnızca programlama dili bilgisi yeterli olmaz.

Yazılımcı Olmak İçin Ne Yapmalı? DevSecOps Yol Haritası

DevSecOps alanına ilerlemek isteyen biri önce Linux permissions, process modeli ve networking temellerini öğrenmelidir. Ardından Git, Docker, Dockerfile ve Kubernetes bilgisi oluşturulabilir. CI/CD pipeline tasarımı ve vulnerability management sonraki doğal adımdır. Linux capabilities, cloud IAM ve supply chain security konuları eklendiğinde daha bütüncül bir bakış gelişir. Öğrenilen bilgileri küçük bir container security lab projesinde uygulamak teoriden çok daha kalıcı sonuç verir.

Diyarbakır Yazılım Topluluğu ile Konteyner Güvenliği

Konteyner güvenliğini öğrenmenin en hızlı yollarından biri yalnız çalışmak yerine gerçek senaryoları başka geliştiricilerle tartışmaktır. Docker ve Kubernetes security workshopları, Trivy ile image tarama çalışmaları ve açık kaynak araçlara katkı etkinlikleri bu konuları uygulamalı hale getirir. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Topluluk içindeki proje çalışmalarına bakmak için https://www.diyarbakiryazilim.com.tr/projects adresi de kullanılabilir. Özellikle güvenlik laboratuvarı, code review ve DevSecOps odaklı ortak çalışmalar teorik bilgiyi gerçek geliştirme pratiğine dönüştürmek açısından değerlidir.

Container Security Lab Projesi

Öğrenme için iyi bir laboratuvar önce kontrollü biçimde güvensiz Dockerfile oluşturarak başlayabilir. Container root çalıştırılır, gereksiz paketler eklenir ve scanner ile hangi problemlerin tespit edildiği gözlemlenir. Daha sonra minimal base image'a geçilir, non-root kullanıcı eklenir, capabilities azaltılır ve filesystem read-only hale getirilir. SBOM üretildikten sonra image Cosign ile imzalanabilir. Son aşamada Kubernetes Restricted policy ve Falco runtime alarmı eklenerek build'den runtime'a kadar bütün güvenlik zinciri deneyimlenebilir.

Konteyner Güvenliğinde Sık Yapılan Hatalar

En sık yapılan hatalardan biri latest tag kullanarak hangi image'ın production'da çalıştığını belirsiz bırakmaktır. Root kullanıcı, privileged: true, gereksiz capability ve Docker socket mount edilmesi ciddi riskler oluşturabilir. Secret'ın image içine yazılması ve yalnızca build sırasında tek sefer tarama yapılması da yaygın problemlerdir. Her CVE'yi aynı öncelikte görmek güvenlik ekiplerini gereksiz iş yüküne sokabilir. SBOM, image signing, NetworkPolicy, minimum RBAC ve runtime monitoring kullanılmaması güvenlik zincirinde görünür boşluklar bırakır.

Production Öncesi Konteyner Güvenliği Kontrol Listesi

Production öncesinde base image'ın güvenilir ve mümkün olduğunca minimal olup olmadığı kontrol edilmelidir. Image digest ile sabitlenmeli, Critical ve High CVE taraması, secret scan ve SBOM üretimi tamamlanmalıdır. Provenance ve image signature doğrulanabilir olmalıdır. Container non-root çalışmalı, privilege escalation kapatılmalı, gereksiz capabilities düşürülmeli ve seccomp aktif edilmelidir. Resource limits, minimum ServiceAccount yetkisi, NetworkPolicy, admission policy, runtime monitoring ve sürekli re-scanning süreçleri devreye alınmalıdır.

Sık Sorulan Sorular

Konteyner güvenliği nedir?

Konteyner güvenliği image oluşturma, registry saklama, deployment ve runtime aşamalarındaki riskleri kontrol etme disiplinidir. Amaç yalnızca bilinen CVE'leri bulmak değildir. Yetki sınırlandırma, network izolasyonu, secret yönetimi, image signing ve runtime detection da sürecin parçalarıdır. Güvenli tasarım build aşamasında başlar. Production gözlemiyle devam eder.

Docker container güvenli midir?

Docker güçlü izolasyon mekanizmaları sunar fakat yanlış yapılandırılmış container güvenli kabul edilemez. Root kullanım, privileged mode ve Docker socket mount gibi ayarlar izolasyonu zayıflatabilir. Image içindeki zafiyetler de ayrı risk oluşturur. Bu nedenle Docker güvenliği default ayarlara bırakılmamalıdır. Non-root çalışma, capability sınırlandırma ve image scanning birlikte uygulanmalıdır.

Container image scanning nedir?

Container image scanning image içindeki paket ve dependency sürümlerini bilinen güvenlik açıklarıyla karşılaştıran otomatik analiz sürecidir. Bazı araçlar secret, configuration ve license kontrollerini de yapabilir. Scanner raporu CVE ve severity bilgisi verir. Bununla birlikte her bulgu gerçek sömürülebilirlik anlamına gelmez. Triage süreciyle iş bağlamı değerlendirilmelidir.

Docker imajı nasıl taranır?

Docker image önce build edilir ve ardından Trivy, Docker Scout, Grype veya benzeri bir scanner ile analiz edilir. CI/CD pipeline içinde taramanın otomatik çalışması tercih edilmelidir. Critical veya belirlenen risk eşiğini aşan sonuçlar deployment'ı durdurabilir. Image registry içinde de düzenli olarak yeniden taranmalıdır. Yeni CVE yayımlandığında daha önce güvenli görünen image yeniden riskli hale gelebilir.

Trivy nedir?

Trivy container image, filesystem ve çeşitli configuration kaynaklarında güvenlik analizi yapabilen açık kaynak bir araçtır. Vulnerability taraması, secret kontrolü ve SBOM üretimi gibi görevlerde kullanılabilir. CI pipeline'a kolayca eklenmesi yaygın kullanım nedenlerinden biridir. Sonuçlar farklı çıktı formatlarına dönüştürülebilir. Güvenlik gate kurallarıyla birlikte otomatik remediation sürecinin parçası olabilir.

Container neden root olarak çalıştırılmamalıdır?

Root kullanıcı container içinde gereğinden geniş ayrıcalıklara sahip olabilir. Uygulama veya runtime tarafındaki başka bir açıkla birleştiğinde saldırının etkisi büyüyebilir. Uygulama root gerektirmiyorsa özel UID ile çalıştırılmalıdır. Kubernetes runAsNonRoot ayarı bu davranışı zorunlu hale getirebilir. Capability drop ve allowPrivilegeEscalation false ayarlarıyla birlikte kullanılması daha güçlü koruma sağlar.

SBOM nedir?

SBOM bir yazılım artifact'ının içerdiği bileşenlerin yapılandırılmış envanteridir. Paket isimleri, sürümler, dependency ilişkileri ve license bilgileri bulunabilir. Yeni güvenlik açığı çıktığında hangi image'ların etkilendiğini hızlıca belirlemeye yardımcı olur. SPDX ve CycloneDX yaygın formatlardır. SBOM'un image digest ve provenance bilgisiyle ilişkilendirilmesi faydalıdır.

Container image neden imzalanmalıdır?

Image signing artifact'ın güvenilir kaynaktan geldiğini ve imzadan sonra değiştirilmediğini doğrulamaya yardımcı olur. İmza image'ın güvenlik açığı içermediği anlamına gelmez. Bu nedenle vulnerability scanning ile birlikte kullanılmalıdır. Admission policy yalnızca doğrulanmış imzaya sahip image'ların deployment edilmesini zorunlu kılabilir. Böylece supply chain üzerinde ek bir güven bariyeri oluşturulur.

İmaj taraması zero-day açıklarını bulabilir mi?

Bir zero-day açığı henüz vulnerability database içinde tanımlanmadıysa klasik CVE tabanlı scanner bunu bulamayabilir. Runtime davranış analizi bazı anormal hareketleri fark edebilir fakat bu da kesin tespit garantisi değildir. Defense in depth yaklaşımı bu nedenle önemlidir. Minimal image, minimum yetki, network segmentasyonu ve runtime monitoring zero-day etkisini azaltabilir. Tarama tek başına yeterli güvenlik kanıtı değildir.

Konteyner güvenliğinde imaj taraması nasıl yapılır ve hangi güvenlik açıkları kontrol edilmelidir?

Konteyner güvenliğinde imaj taraması nasıl yapılır sorusuna verilecek pratik cevap, taramayı build sonrasına eklemek ve registry içinde düzenli yeniden tarama yapmaktır. İşletim sistemi paketleri, language dependency'leri, Critical ve High CVE'ler, gömülü secret'lar ve configuration hataları kontrol edilmelidir. Tarama sonucunda fix sürümü bulunan riskler önceliklendirilmelidir. Aktif exploit, internet erişimi ve reachability gibi bağlamlar da hesaba katılmalıdır. Böylece yalnızca CVE sayan değil gerçek riske odaklanan bir süreç kurulur.

Docker ve Kubernetes ortamlarında konteyner yetkileri least privilege prensibine göre nasıl sınırlandırılır?

Docker ve Kubernetes container yetkileri nasıl sınırlandırılır sorusunun temel cevabı root kullanımını azaltmak ve yalnızca ihtiyaç duyulan kernel ile API izinlerini vermektir. Dockerfile USER ile non-root kullanıcı tanımlanabilir. Kubernetes SecurityContext içinde runAsNonRoot, allowPrivilegeEscalation false, readOnlyRootFilesystem ve capability drop kullanılabilir. ServiceAccount için wildcard RBAC izinlarından kaçınılmalıdır. NetworkPolicy ve Pod Security politikaları da bu minimum yetki yaklaşımını tamamlar.

Trivy, Clair ve benzeri araçlarla container image zafiyet taramaları CI/CD süreçlerine nasıl entegre edilir?

Scanner build işleminden sonra otomatik pipeline adımı olarak çalıştırılabilir. Sonuçlar severity, fix availability ve kurumun risk politikasına göre security gate'e gönderilebilir. Kritik risklerde pipeline durdurulurken düşük riskler takip sistemine aktarılabilir. SBOM aynı pipeline içinde üretilip artifact ile saklanabilir. Registry push ve deployment yalnızca security policy geçen image için devam etmelidir.

Root olmayan kullanıcı, RBAC, Security Context ve Pod Security yapılandırmaları konteyner güvenliğini nasıl artırır?

Bu kontroller saldırganın ele geçirilmiş bir container üzerinden sahip olabileceği yetkiyi azaltır. Non-root kullanıcı Linux seviyesinde ayrıcalığı düşürür. SecurityContext capability, privilege escalation ve filesystem erişimini sınırlar. RBAC Kubernetes API üzerinde workload'ın yapabileceği işlemleri daraltır. Pod Security ise riskli deployment özelliklerini cluster seviyesinde standartlaştırır.

Konteyner imaj taraması ve yetki sınırlandırma konusunda yakınımda DevSecOps danışmanlığı veya eğitim nerede bulabilirim?

Konteyner güvenliği ve Kubernetes danışmanlığı yakınımda şeklinde arama yapan ekipler için yalnızca teorik eğitim değil uygulamalı çalışma ortamı da önemlidir. Diyarbakır'da yazılım, DevOps ve güvenlik konularında topluluk odaklı çalışmaları takip etmek için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Kurumsal konteyner güvenliği imaj tarama ve Kubernetes hardening hizmeti arayan ekipler de önce mevcut build, registry, RBAC ve runtime süreçlerini analiz ederek ihtiyaçlarını netleştirmelidir. Uygulamalı workshop veya laboratuvar çalışması öğrenmeyi ciddi biçimde hızlandırır. Container security en iyi gerçek Dockerfile, CI pipeline ve Kubernetes manifestleri üzerinde çalışılarak öğrenilir.

Sonuç: Güvenli Konteyner Sadece Taranmış Konteyner Değildir

Konteyner Güvenliği: İmaj Taraması ve Yetki Sınırlandırma yaklaşımında scanner önemli bir başlangıçtır fakat sürecin tamamı değildir. Güvenilir ve minimal image ile başlayın, her build'i otomatik tarayın, SBOM ve provenance üretin ve deployment edilen artifact'ları imzalayın. Container'ları non-root çalıştırın, gereksiz capability'leri kaldırın ve Kubernetes politikalarıyla bu kuralları zorunlu hale getirin. Registry içindeki image'ları yeni CVE'ler için sürekli yeniden tarayın. Runtime davranışını izleyerek build'den production'a kadar kesintisiz bir güven zinciri kurun.

Ekibinizle container security, Kubernetes hardening, açık kaynak güvenlik araçları ve DevSecOps uygulamaları üzerinde birlikte çalışmak istiyorsanız Diyarbakır Yazılım Topluluğu çalışmalarını inceleyebilirsiniz. Proje örnekleri ve topluluk çalışmalarına https://www.diyarbakiryazilim.com.tr/projects üzerinden ulaşabilirsiniz. Topluluğun genel yapısı ve çalışma alanları için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz. Konteyner Güvenliği: İmaj Taraması ve Yetki Sınırlandırma konusunu öğrenmenin en güçlü yolu küçük bir laboratuvar kurup güvenlik kontrollerini sırayla uygulamaktır. Build'den runtime'a kadar her adımı ölçülebilir ve tekrar edilebilir hale getirdiğinizde container güvenliği tek seferlik kontrolden sürdürülebilir bir mühendislik pratiğine dönüşür.