Giriş: “Güvenli” Sandığınız Cluster Aslında Öyle Olmayabilir

Merhaba! Bugün sizlerle Kubernetes (K8s) güvenliği hakkında konuşacağız. Biliyorum, “güvenlik” kelimesi kulağa sıkıcı gelebilir ama inanın bana, bu yazıyı okuduktan sonra cluster’larınıza bir daha aynı gözle bakmayacaksınız.

Kubernetes, konteyner yönetimi (container orchestration) dünyasının kralı haline geldi. Ancak bu güç beraberinde büyük bir sorumluluk getiriyor. İşte size şok edici bir istatistik: 2023 yılında yapılan bir Cloud Native Computing Foundation (CNCF) anketine göre, katılımcıların %93’ü son bir yıl içinde en az bir Kubernetes güvenlik olayı yaşadı [1][2]. Üstelik katılımcıların %78’i güvenlik duruşlarından (security posture) emin olmadıklarını belirtti [3].

Daha da kötüsü, 2024 verilerine göre organizasyonların %59’u Kubernetes veya konteyner ortamlarında güvenlik olayları yaşadı ve bunların %30’u veri ihlali (data breach) veya ağ güvenliğinin ihlal edilmesiyle sonuçlandı [4]. Peki bunun asıl sebebi ne? Kubernetes’in varsayılan ayarları (default settings) güvenlikten çok kullanım kolaylığına öncelik veriyor.

Bugün sizlerle birlikte Kubernetes’in beş temel güvenlik gerçeğini keşfedeceğiz, gerçek dünyadan örneklerle bu konuları somutlaştıracağız ve en önemlisi, kendinizi nasıl koruyacağınızı öğreneceğiz.

1. Secret Dediğimiz Şeyler Gerçekten Secret Mi?

Base64 Şifreleme Değildir

Kubernetes Secret (Sır) objelerinin adı sizi yanıltmasın. Varsayılan olarak bu “sırlar” hiç de gizli değil! Kubernetes’in veri deposu olan etcd içinde base64 kodlamasıyla (base64 encoding) saklanıyorlar [5].

Base64’ü bir şifreleme yöntemi (encryption method) sanıyorsanız, sizi üzmek istemem ama o sadece bir kodlama şeması (encoding scheme). Bunu şöyle düşünün: “MERHABA” kelimesini “NFSIBCB” olarak yazmak gibi. Bakıldığında anlamsız görünüyor ama biraz uğraşırsanız kolayca çözülebiliyor. Gerçek bir güvenlik sağlamıyor.

Tesla’nın Acı Deneyimi: Gerçek Bir Vaka

Hadi size 2018 yılından gerçek bir örnek vereyim [6][7]. Tesla’nın bulut altyapısı (cloud infrastructure) hackerlar tarafından ele geçirildi. Nasıl mı? Şifre korumalı olmayan bir Kubernetes konsolu aracılığıyla.

İşte olay nasıl gelişti:

• Hackerlar, password koruması olmayan Tesla’nın Kubernetes yönetim konsoluna (administrative console) erişti
• Bir Kubernetes pod içinden AWS (Amazon Web Services) kimlik bilgileri açığa çıktı
• Bu kimlik bilgileri, telemetri, haritalama ve araç servis verilerinin bulunduğu Amazon S3 bucket’larına (depolama alanı) erişim sağladı
• Hackerlar Stratum adlı kripto madenciliği yazılımını (cryptocurrency mining software) yüklediler
• Yaklaşık 0.9 Bitcoin (o dönem ~6,000 dolar değerinde) madencilik yaptılar [8]

Daha da kötüsü, hackerlar tespit edilmemek için birçok ileri seviye kaçınma tekniği (evasion technique) kullandılar:

• Mining pool (madencilik havuzu) sunucusunun gerçek IP adresini CloudFlare arkasına gizlediler
• CPU kullanımını düşük tuttular
• Standart olmayan portlar kullandılar [9][10]

Çözüm: Encryption at Rest

Kubernetes resmi dokümantasyonu bu konuda net bir uyarıda bulunuyor: “Kubernetes Secret’ları varsayılan olarak API sunucusunun altında yatan veri deposunda (etcd) şifrelenmemiş olarak saklanır” [11].

Yapmanız gereken ilk şey “Encryption at Rest” (Dinlenme Halinde Şifreleme) özelliğini etkinleştirmek. Bu, Secret verilerinizin kaydedilmeden önce şifrelenmesini sağlar. Ancak bu varsayılan olarak gelmez, siz açıkça yapılandırmalısınız [5][11].

İpucu: Daha da güvenli olmak için HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault gibi harici sır yönetim araçlarını (external secrets management tools) kullanın [12]. Bu araçlar merkezi sır yönetimi (centralized secret management), erişim günlükleme (access logging) ve otomatik rotasyon (automatic rotation) gibi gelişmiş özellikler sunar.

2. Cluster Ağı Aslında “Serbest Bölge”

Varsayılan: Herkes Herkesle Konuşabilir

Kubernetes ağ modelinin (network model) varsayılan yapılandırması tamamen açık. Hazır kurulumda, her pod aynı namespace içindeki diğer tüm pod’larla kısıtlama olmaksızın iletişim kurabilir [13]. Kullandığınız ağ eklentisine (network plugin) bağlı olarak, bu genellikle namespace’ler arası trafiğe (cross-namespace traffic) de uzanır.

Kubernetes dokümantasyonu bunu açıkça onaylıyor: “Varsayılan olarak, bir namespace içinde hiçbir politika yoksa, o namespace’deki pod’lara gelen ve giden tüm trafik kabul edilir” [14].

350+ Şirket Açıkta Kaldı

2023 yılında Aqua Security’nin Nautilus araştırma ekibi üç aylık bir soruşturma sonucunda şok edici bir gerçeği ortaya çıkardı: 350’den fazla organizasyon, açık kaynak proje ve bireye ait Kubernetes cluster’ları açıkça erişilebilir ve korumasız durumdaydı [15]. Bunların %55’inden fazlası ihlal edilmiş ve aktif kötü amaçlı yazılım/arka kapı (malware/backdoor) barındırıyordu [16].

Bu açıklıklar iki yanlış yapılandırmadan (misconfiguration) kaynaklanıyordu:

1. Ayrıcalıklı anonim erişime (anonymous access with privileges) izin veren yapılandırma
2. Kubernetes cluster’larının internete açık olması

Etkilenen şirketler arasında finansal hizmetler, havacılık, otomotiv, endüstriyel ve güvenlik sektörlerinden büyük firmalar vardı [15][16]. Fortune 500 şirketlerinin bile bir kısmı bu listede yer alıyordu.

2024’te OpenMetadata Saldırısı

Daha güncel bir örnek mi istiyorsunuz? 2024 Nisan ayında, tehdit aktörleri OpenMetadata’daki kritik güvenlik açıklarını (vulnerabilities) kullanarak Kubernetes iş yüklerine (workloads) yetkisiz erişim sağladılar ve kripto madenciliği yaptılar [17]. Microsoft Threat Intelligence’a göre, bu açıklar aktif olarak istismar edildi.

Saldırganlar kimlik doğrulamayı atlayıp (bypassing authentication) konteynerler içinde kod çalıştırabildiler. Erişim sağladıktan sonra ortamı keşfedip, kendi altyapılarına ping göndererek bağlantıyı doğruladılar. Sonrasında uzak bir sunucudan kripto madenciliği kötü amaçlı yazılımını yüklediler [17].

Çözüm: NetworkPolicy ile “Varsayılan Reddet”

Yerli çözüm NetworkPolicy kaynaklarını uygulamaktır. Bu, trafiği kilitlemenize ve “varsayılan reddet” (default deny) duruşu oluşturmanıza olanak tanır – yani sadece açıkça izin verilen bağlantılara müsaade edilir [18].

Örnek NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Bu basit politika, “production” namespace’indeki tüm pod’lar için hem gelen hem giden trafiği varsayılan olarak reddeder [19].

Gelişmiş Araçlar:

• Cilium: eBPF tabanlı, gelişmiş ağ görünürlüğü (network visibility) ve politika uygulama sunar [20]
• Calico: Ağ politikalarının yanı sıra güvenlik politikaları da sağlar [21]
• Istio/Linkerd: Service mesh (servis ağı) çözümleri, pod’lar arası trafiği şifreler ve mutual TLS (mTLS) uygular [22]

3. API Sunucusu Çok Katmanlı Bir Güvenlik Kontrolü

Dört Aşamalı Güvenlik Süreci

Kubernetes API sunucusuna gelen her istek, üzerinde işlem yapılmadan önce çok aşamalı bir güvenlik süzgecinden (security gauntlet) geçer [23]. Bu sadece basit bir giriş kontrolü değil; farklı amaçlara sahip bir dizi kontrol noktası gibi düşünün:

1. Transport Security (Taşıma Güvenliği): Bağlantı TLS ile güvence altına alınır, tüm iletişim şifrelenir
2. Authentication (Kimlik Doğrulama): “Kimsiniz?” sorusuna cevap verir, kullanıcının veya servis hesabının kimliğini doğrular
3. Authorization (Yetkilendirme): “Ne yapabilirsiniz?” sorusuna cevap verir, kimliği doğrulanmış kullanıcının istenen işlemi yapma izni olup olmadığını kontrol eder
4. Admission Control (Kabul Kontrolü): Etcd’ye kaydedilmeden önce kontrolörler isteği doğrulayabilir, değiştirebilir veya reddedebilir [24]

Admission Controller’ların Gücü

Admission Control (Kabul Kontrolü) aşaması genellikle gözden kaçırılır ama inanılmaz derecede güçlü bir güvenlik aracıdır. Kontrol düzleminin (control plane) nihai uygulama noktasıdır [25].

Bir admission controller ile programatik olarak daha önce bahsettiğim sorunları engelleyebilirsiniz:

• Güvenilir bir registry’den (kayıt defteri) gelmeyen imajları kullanan pod’ları engelleyebilirsiniz
• Tüm hassas verilerin Kubernetes Secret yerine harici bir sır yöneticisinde saklanmasını zorunlu kılabilirsiniz [26]

Popüler Admission Controller Araçları:

OPA/Gatekeeper: Open Policy Agent (OPA), genel amaçlı bir politika motorudur (policy engine) [27]. Gatekeeper, OPA tarafından yürütülen politikaları uygulayan özelleştirilebilir bir Kubernetes admission webhook’udur. Politikalar Rego dili ile yazılır, bu da karmaşık kurallar için esneklik sağlar ancak öğrenme eğrisi (learning curve) daha dik olabilir [28][29].

Kyverno: Özellikle Kubernetes için tasarlanmış bir politika motoru. OPA’ya kıyasla Kubernetes-native (Kubernetes’e özgü) bir yaklaşım benimser. Politikalar tanıdık YAML dosyaları olarak modellenir, bu da operatörlerin mevcut süreçleri kullanarak yönetmelerini kolaylaştırır [30][31].

Kyverno’nun avantajları:

• YAML ile politika yazımı (öğrenmesi kolay)
• Doğrulama (validation), mutasyon (mutation) ve kaynak oluşturma desteği
• İmaj imzası doğrulama özelliği [32]

4. Pod’larınızı Sıkı Bir Güvenlik Diyetine Koyun

Pod Security Standards: Üç Seviye Güvenlik

Düzinelerce ayarı tek tek düzenlemek yerine, Kubernetes size daha basit bir yaklaşım sunar: Pod Security Standards (Pod Güvenlik Standartları) [33]. Bunları iş yükleriniz için önceden tanımlanmış diyet planları olarak düşünün:

• Privileged (Ayrıcalıklı): Her şeyi yiyebilir (en az kısıtlama)
• Baseline (Temel): Dengeli bir diyet (orta düzey güvenlik)
• Restricted (Kısıtlı): Sıkı, sağlıklı bir diyet (maksimum güvenlik) [34]

Restricted Policy: Altın Standart

Restricted (Kısıtlı) politika, güvenlik açısından kritik uygulamaları sağlamlaştırmak için altın standarttır. Pod’un potansiyel saldırı yüzeyini (attack surface) önemli ölçüde azaltan katı bir minimum ayrıcalık (least privilege) ilkeleri dizisi uygular [35].

Restricted politikanın temel gereksinimleri:

• Konteynerler root olmayan bir kullanıcı olarak çalışmalı
• Ayrıcalık yükseltmeye (privilege escalation) izin verilmemeli
• Konteynerler TÜM yetenekleri (capabilities) bırakmalı, sadece NET_BIND_SERVICE eklenebilir
• RuntimeDefault veya Localhost seccomp (secure computing mode) profili açıkça ayarlanmalı [36]

Gerçek Dünya Etkisi

2024 Red Hat raporuna göre, güvenlik olaylarının %46’sı gelir veya müşteri kaybıyla sonuçlandı [37]. %26’sı çalışan işten çıkarmaya, %30’u ise para cezalarına yol açtı [38]. Bu sadece teknik bir sorun değil, doğrudan işletmenizi etkiliyor.

Örnek Pod Security Standard Uygulaması:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

5. Güvenlik Sadece Çalışma Zamanında Değil, Tam Yaşam Döngüsü (Full Lifecycle Security)

CNCF’nin 4 Aşamalı Modeli

Cloud Native Computing Foundation (CNCF), tüm uygulama yaşam döngüsünü (application lifecycle) kapsayan bütünsel bir güvenlik modeli (holistic security model) savunur: Develop, Distribute, Deploy ve Runtime [39].

1. Develop (Geliştirme)

Güvenlik kod ile başlar. Bu aşama (phase) şunlara odaklanır:

• Güvenli uygulama tasarımı (secure application design)
• Potansiyel riskleri (potential risks) belirlemek için tehdit modelleme (threat modeling)
• Güvenlik odaklı kod incelemeleri (security-focused code reviews) [40]

Araçlar (Tools):

• Checkov: IaC (Infrastructure as Code) taraması için
• Kubesec: Kubernetes kaynakları (resources) için statik analiz (static analysis) [41]

2. Distribute (Dağıtım)

Yazılım tedarik zincirini (software supply chain) güvence altına alır:

• Konteyner imajlarını (container images) bilinen güvenlik açıkları (known vulnerabilities) için tarama (scanning)
• Yazılım eserlerini (software artifacts) kriptografik olarak imzalama (cryptographically signing) [42]

Araçlar (Tools):

Trivy: Çok amaçlı bir güvenlik tarayıcısı (multi-purpose security scanner). Konteyner imajlarını (container images), Git depolarını (repositories), Kubernetes manifestlerini tarar [43]. İşletim sistemi paketlerindeki (OS packages) ve uygulama bağımlılıklarındaki (application dependencies) güvenlik açıklarını (vulnerabilities) tespit eder. Aqua Security tarafından geliştirilen Trivy, kullanım kolaylığı (ease of use) ve kapsamlı tarama yetenekleriyle (comprehensive scanning capabilities) popülerdir [44][45].

Trivy’nin kapsamı (scope):

• Konteyner imajları (container images)
• Dosya sistemleri (filesystems)
• Git depoları (repositories)
• Kubernetes cluster’ları (clusters)
• Bulut servisleri (cloud services)
• IaC şablonları (IaC templates) [46]

Grype & Syft: Anchore tarafından geliştirilen bu araçlar tamamlayıcıdır (complementary). Grype konteyner imajlarını (container images) ve dosya sistemlerini (filesystems) tarar. Syft ise SBOM (Software Bill of Materials – Yazılım Malzeme Listesi) oluşturur, bu da bileşenlerin (components) izlenmesine yardımcı olur [47].

Harbor: VMware tarafından geliştirilip CNCF’ye bağışlanan konteyner imaj registry’si (container image registry). Docker Hub gibi standart registry’lerden farklı olarak daha kapsamlı güvenlik kontrolleri (comprehensive security controls) sunar:

• Role-based access control (RBAC – Rol Tabanlı Erişim Kontrolü)
• Güvenlik açığı taraması entegrasyonu (vulnerability scanning integration)
• İmaj imzalama ve doğrulama (image signing and verification) [48]

3. Deploy (Dağıtım)

Dağıtım zamanında (deployment time) güvenlik, uygulama (enforcement) ile ilgilidir:

• Admission controller’ları kullanarak politika uygulama (policy enforcement)
• Distribute aşamasından imaj imzalarını (image signatures) doğrulama (verification)
• Workload dağıtım izinlerini (deployment permissions) kısıtlama (restricting) [49]

Araçlar (Tools):

• Kube-bench: CIS Kubernetes Benchmark’a karşı cluster yapılandırmasını (configuration) kontrol eder [50]
• Kubescape: ARMO tarafından geliştirilen, Kubernetes cluster’larını, YAML dosyalarını ve Helm chartlarını tarar. NSA ve MITRE ATT&CK çerçevelerine (frameworks) göre risk puanı (risk score) verir [51]

4. Runtime (Çalışma Zamanı)

Uygulama çalışırken güvenlik koruma (protection) ve tespit (detection) odaklıdır:

• Network policy’leri (ağ politikaları) kullanarak trafiği kontrol etme (traffic control)
• Erişim kontrolünü (access control) yönetme (managing)
• Anormal (anomalous) veya kötü amaçlı davranışları (malicious behavior) sürekli izleme (continuous monitoring) [52]

Araçlar (Tools):

Falco: CNCF graduated project olan Falco, gerçek zamanlı tehdit tespiti (real-time threat detection) için açık kaynaklı bir araçtır (open-source tool) [53]. Linux kernel sistem çağrılarını (system calls) izleyerek anormal davranışları (abnormal behaviors) tespit eder.

Falco’nun güçlü yönleri (strengths):

• Özelleştirilebilir kurallar motoru (customizable rules engine)
• Kubernetes ile derin entegrasyon (deep integration)
• Zengin metadata ile bağlamsal uyarılar (contextual alerts with rich metadata)
• eBPF tabanlı izleme (eBPF-based monitoring) [54][55]

Falco şunları tespit edebilir:

• Hassas dosyalara yetkisiz erişim (unauthorized access to sensitive files)
• Ayrıcalık yükseltme denemeleri (privilege escalation attempts)
• Beklenmeyen ağ bağlantıları (unexpected network connections)
• Şüpheli süreç yürütmeleri (suspicious process executions) [56]

Cilium Tetragon: eBPF tabanlı runtime izleme (runtime monitoring) ve uygulama aracı (enforcement tool). Performanstan ödün vermeden (without compromising performance) konteyner davranışına (container behavior) gerçek zamanlı içgörüler (real-time insights) sağlar. Tehdit tespitinin (threat detection) ötesine geçerek, potansiyel riskleri (potential risks) ortaya çıktıkça etkisiz hale getirmek için politikaları (policies) aktif olarak uygular [57].

AKS Cluster’ları 18 Dakikada Saldırı Altında!

Wiz’in 2025 Kubernetes Güvenlik Raporu şok edici bir gerçeği ortaya koyuyor: Azure Kubernetes Service (AKS) cluster’ları dağıtımdan sadece 18 dakika sonra saldırı denemelerine maruz kalıyor [58]!

Bu bulgu önemli bir mesaj veriyor: Kubernetes güvenliğinde hiçbir zaman sonradan düşünülemez. Dijital mürekkep kurumadan cluster’ınız zaten kuşatma altında. Saldırganlar ışık hızında çalışıyor, konfigürasyon dosyalarınızdaki zayıflıkları aramak için henüz deploy ettiğiniz andan itibaren harekete geçiyorlar [58].

Gerçek Maliyetler: Sadece Teknik Değil, İş Etkisi

Kubernetes güvenlik olaylarının etkisi teknik sorunların çok ötesine geçiyor. Red Hat’in 2024 raporuna göre [59]:

• %67 organizasyon artan güvenlik endişeleri nedeniyle uygulama geliştirmesini geciktirdi veya yavaşlattı
• %42 organizasyon konteyner ve Kubernetes stratejileriyle ilgili güvenliği en büyük endişe olarak gösteriyor
• %46 güvenlik olayı sonucu gelir veya müşteri kaybı yaşadı
• %33 uygulama lansmanını ertelemek zorunda kaldı
• %32 uygulama servisinde kesinti yaşadı
• %27 uyumluluk ihlali (compliance violation) yaşadı [60]

Bu sadece sayılar değil, gerçek iş sonuçları. Her gecikme, her ihlal, her müşteri kaybı doğrudan şirketinizin alt çizgisini etkiliyor.

Pratik Uygulama: Başlangıç Yapma Kılavuzu

Şimdi bu bilgileri nasıl uygulayacağınıza bakalım. İşte adım adım yaklaşım:

1. Hızlı Güvenlik Değerlendirmesi (Hemen Yapın!)

# Trivy ile cluster taraması
trivy kubernetes --report summary cluster

# Kubescape ile güvenlik değerlendirmesi
kubescape scan --submit --enable-host-scan

# Kube-bench ile CIS kontrolü
kube-bench run --targets master,node

2. Temel Sağlamlaştırma (İlk Hafta)

Secret’ları Şifreleyin:

• Encryption at Rest’i etkinleştirin
• Harici sır yönetimi düşünün (Vault, AWS Secrets Manager)

Network Policy’leri Uygulayın:

# Her namespace için varsayılan reddet politikası
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Pod Security Standards:

# Restricted politika ile namespace etiketleme
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted

3. Sürekli İzleme (Devam Eden)

Falco’yu Deploy Edin:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace

Trivy Operator Kurulumu:

helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator --namespace trivy-system --create-namespace

4. Politika Uygulama (İlk Ay)

Kyverno ile Başlayın (daha kolay):

kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/install.yaml

Veya OPA/Gatekeeper (daha esnek):

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

Gelişmiş Platformlar: Entegre Çözümler

Birden fazla aracı manuel olarak entegre etmek yerine, entegre platformları da değerlendirebilirsiniz:

ARMO Platform

eBPF teknolojisi üzerinde inşa edilmiş, iş yükü koruması (workload protection), KSPM (Kubernetes Security Posture Management), CADR (Cloud Attack Detection and Response) ve CSPM’i (Cloud Security Posture Management) tek bir çözümde birleştirir [61]. Kubescape üzerine kurulu olan ARMO, bulut-native ortamlarda gerçek zamanlı uygulama davranışını yakalar ve analiz eder.

Sysdig Secure

Falco’nun temelleri üzerine kurulu, güvenlik açığı taraması, duruş yönetimi ve runtime tehdit tespitini birleştiren bir CNAPP (Cloud-Native Application Protection Platform) sağlar [62].

Wiz

Kubernetes cluster’ları için kapsamlı görünürlük ve güvenlik sağlayan bir cloud security platform. Yanlış yapılandırmaları, güvenlik açıklarını ve tehdit göstergelerini tespit eder.

DevSecOps Kültürü: Güvenliği Sola Kaydırın

Araçlar önemli ama kültür daha da önemli. 2024 raporlarına göre, organizasyonların çoğu DevSecOps’un (Development, Security, Operations) değerini kabul ediyor ve DevOps ile güvenlik ekipleri arasında işbirliği geliştiriyor [63].

Olgun organizasyonlar:

• Güvenlik araçlarını ve süreçlerini entegre ve otomatize ediyor
• CI/CD pipeline’larına güvenlik kontrolleri gömüyor
• Güvenliği sonradan değil, baştan tasarlıyorlar [64]

Yeni başlayan organizasyonlar:

• Ortak politikalar ve iş akışları geliştirmeye odaklanıyor
• Güvenlik farkındalığı eğitimleri veriyor
• Küçük adımlarla ilerliyor

Sonuç: Güvenlik Bir Yolculuk, Varış Noktası Değil

Kubernetes güçlü ve esnek bir platform ama güvenlik varsayılanları işletmesel kolaylığa öncelik veriyor, maksimum güvenliğe değil. Bu beş gerçeğin ortak teması açık:

1. Secret’lar varsayılan olarak gizli değil → Encryption at Rest ve harici vault kullanın
2. Ağlar tamamen açık → NetworkPolicy’lerle “varsayılan reddet” uygulayın
3. API sunucusu çok katmanlı → Admission controller’ların gücünden yararlanın
4. Pod’lar fazla ayrıcalıklı → Pod Security Standards ile sıkılaştırın
5. Güvenlik yaşam döngüsü boyunca → Develop’tan Runtime’a kadar her aşamada güvenlik

Tesla’nın başına gelenler, 350+ şirketin açık cluster’ları, OpenMetadata saldırıları – bunlar hepsi gerçek dünya örnekleri. %93’ünüzün geçen yıl bir güvenlik olayı yaşadığı bir dünyada yaşıyoruz [1]. AKS cluster’larınız 18 dakika içinde taranıyor [58].

Ama umutsuzluğa kapılmayın! Bugün öğrendiklerinizi uygularsanız, kendinizi büyük ölçüde koruyabilirsiniz:

• Falco ile runtime izleme
• Trivy ile güvenlik açığı taraması
• Kyverno veya OPA ile politika uygulama
• NetworkPolicy’ler ile ağ segmentasyonu
• Pod Security Standards ile pod sağlamlaştırma

Kaynaklar

[1] SentinelOne. (2024). “Top 10 Kubernetes Security Issues.” https://www.sentinelone.com/cybersecurity-101/cloud-security/kubernetes-security-issues/

[2] CheckRed. (2025). “Three Kubernetes Security Incidents in 2024.” https://checkred.com/resources/blog/three-kubernetes-security-incidents-in-2024/

[3] SentinelOne. (2024). “Kubernetes Security: CNCF Survey Results.”

[4] Infosecurity Magazine. (2025). “Over Half of Users Report Kubernetes/Container Security Incidents.” https://www.infosecurity-magazine.com/news/half-users-kubernetescontainer/

[5] Kubernetes Documentation. “Encrypting Secret Data at Rest.”

[6] CNBC. (2018). “Hackers hijack Tesla’s cloud system to mine cryptocurrency.” https://www.cnbc.com/2018/02/21/hackers-hijack-teslas-cloud-system-to-mine-cryptocurrency-redlock.html

[7] Electrek. (2018). “Tesla’s cloud was ‘hijacked’ by hackers to mine cryptocurrencies.” https://electrek.co/2018/02/20/tesla-cloud-hijacked-hackers-mine-cryptocurrencies/

[8] Centre for Cybersecurity. (2024). “Cryptojacking: Case Study on Tesla’s Experience.” https://www.centreforcybersecurity.com/en-sg/post/cryptojacking-case-study-on-teslas-experience

[9] CyberScoop. (2018). “Tesla falls victim to cryptomining scheme, minor breach.” https://cyberscoop.com/tesla-cryptomining-redlock-cloud-breach/

[10] Security Brief. (2021). “Hackers exploit Tesla’s AWS servers to mine cryptocurrency.” https://securitybrief.com.au/story/hackers-exploit-teslas-aws-servers-mine-cryptocurrency

[11] Kubernetes Documentation. “Secrets: Security Properties and Risks.”

[12] Wiz. (2024). “12 Open-Source Container Security Tools.” https://www.wiz.io/academy/open-source-container-security-tools

[13] Medium. (2023). “Kubernetes Security Optimisation: SecOps Best Practices.” https://medium.com/contino-engineering/kubernetes-security-optimisation-secops-best-practices-for-robust-container-platforms-89f02aa7f1b4

[14] Kubernetes Documentation. “Network Policies.”

[15] CSO Online. (2023). “Kubernetes clusters under attack in hundreds of organizations.” https://www.csoonline.com/article/648756/kubernetes-clusters-under-attack-in-hundreds-of-organizations.html

[16] CSO Online. (2023). “Aqua Security Investigation Findings.”

[17] CheckRed. (2025). “OpenMetadata Kubernetes Security Incident 2024.”

[18] Kubernetes Documentation. “NetworkPolicy Resources.”

[19] Medium. (2024). “Kubernetes Security Tools: OPA Gatekeeper & Trivy.” https://medium.com/@noah_h/kubernetes-security-tools-opa-gatekeeper-trivy-5b613eb387ff

[20] Wiz. (2024). “Cilium for Network Security.”

[21] Wiz. (2024). “Project Calico for Network Policies.”

[22] SentinelOne. (2024). “Service Mesh Security with Istio and Linkerd.”

[23] Kubernetes Documentation. “Controlling Access to the Kubernetes API.”

[24] Kubernetes Documentation. “Admission Controllers.”

[25] Trend Micro. “Understanding the Kubernetes Security Triad.” https://www.trendmicro.com/vinfo/us/security/news/virtualization-and-cloud/understanding-the-kubernetes-security-triad-image-scanning-admission-controllers-and-runtime-security

[26] Medium. (2024). “Admission Controllers for Policy Enforcement.”

[27] Spacelift. (2025). “Top 15 Kubernetes Security Tools and Solutions for 2025.” https://spacelift.io/blog/kubernetes-security-tools

[28] Medium. (2024). “OPA Gatekeeper Implementation.”

[29] Wiz. (2024). “Open Policy Agent (OPA) Guide.”

[30] Spacelift. (2025). “Kyverno for Kubernetes Policy Management.”

[31] Atmosly. (2024). “Kubernetes Security Best Practices with Top Open Source Tools.” https://www.atmosly.com/blog/managing-kubernetes-security-with-the-best-open-source-tools

[32] Trend Micro. “Kyverno Features and Architecture.”

[33] Kubernetes Documentation. “Pod Security Standards.”

[34] Kubernetes Documentation. “Pod Security Standards: Privileged, Baseline, Restricted.”

[35] Medium. (2023). “Kubernetes Pod Security Best Practices.”

[36] Kubernetes Documentation. “Restricted Pod Security Standard Requirements.”

[37] Red Hat. (2024). “The State of Kubernetes Security in 2024.” https://www.redhat.com/en/blog/state-kubernetes-security-2024

[38] Red Hat. (2024). “Kubernetes adoption, security, and market trends report 2024.” https://www.redhat.com/en/resources/kubernetes-adoption-security-market-trends-overview

[39] CNCF. “Cloud Native Security Model: Four Phases.”

[40] SecAlign. “Enhancing Cloud-Native Security with Falco, Kyverno, Trivy Operator, and FluxCD.” https://secalign.dev/blog/enhancing-cloud-native-security-with-falco–kyverno–trivy-operator–and-fluxcd

[41] Jit. (2024). “Top 8 Open Source Kubernetes Security Tools and Scanners.” https://www.jit.io/resources/cloud-sec-tools/top-8-open-source-kubernetes-security-tools-and-scanners

[42] SecAlign. “Software Supply Chain Security in Kubernetes.”

[43] Medium. (2024). “Trivy: Comprehensive Security Scanner.”

[44] Spacelift. (2025). “Trivy for DevOps Security.”

[45] Jit. (2024). “Trivy for Vulnerability Scanning.”

[46] Wiz. (2024). “Trivy Scanning Capabilities.”

[47] Wiz. (2024). “Grype and Syft for SBOM and Vulnerability Management.”

[48] Wiz. (2024). “Harbor: Container Registry with Advanced Security.”

[49] CNCF. “Deploy Phase Security Best Practices.”

[50] Spacelift. (2025). “Kube-bench for CIS Benchmark Compliance.”

[51] Atmosly. (2024). “Kubescape for Risk Assessment.”

[52] CNCF. “Runtime Phase Security.”

[53] KodeKloud. (2025). “CNCF Tool Interviews Series: Falco.” https://kodekloud.com/blog/cncf-tool-interviews-series-falco/

[54] SecAlign. “Falco for Real-Time Threat Detection.”

[55] Jit. (2024). “Falco: Runtime Security for Kubernetes.”

[56] Spacelift. (2025). “Falco Capabilities and Use Cases.”

[57] ARMO. (2025). “Runtime Security Tools: A 2025 Guide.” https://www.armosec.io/blog/runtime-security-tools/

[58] Wiz. (2025). “Kubernetes Trends Report 2025.” https://www.wiz.io/blog/kubernetes-report-preview-2025

[59] Red Hat. (2024). “State of Kubernetes Security Report.”

[60] Red Hat. (2024). “Business Impact of Kubernetes Security Incidents.”

[61] ARMO. (2025). “ARMO Platform: eBPF-based Cloud Security.”

[62] ARMO. (2025). “Sysdig Secure CNAPP Platform.”

[63] Security Boulevard. (2024). “Unraveling the State of Kubernetes Security in 2024.” https://securityboulevard.com/2024/08/unraveling-the-state-of-kubernetes-security-in-2024/

[64] ARMO. (2024). “Unraveling the State of Kubernetes Security in 2024.” https://www.armosec.io/blog/unraveling-the-state-of-kubernetes-security-2024/