1. GİRİŞ

Kubernetes, modern bulut‑native uygulamaların dağıtımında ve operasyonunda bir standart haline geldi. Ancak orkestrasyon sağlayan güçlü özellikler, aynı zamanda geniş saldırı yüzeyi de oluşturur. Kubernetes güvenliği yalnızca birkaç ayarlı bayraktan ibaret değildir; kontrol düzlemi, node'lar, ağ, çalışma zamanı, CI/CD pipeline ve tedarik zinciri dahil olmak üzere bütünsel bir yaklaşım gerektirir. Bu makale mühendis bakış açısıyla Kubernetes güvenliğinin teknik temellerini, gerçek dünya uygulamalarını, sınırlarını ve uygulanabilir en iyi pratikleri derinlemesine ele alır.

Bu konu neden bugün önemli?

• Konteynerleşme ve mikroservislerin artan kullanımı, dağıtık sistemlerin güvenlik risklerini büyütüyor.
• Regülasyon ve uyumluluk (PCI, GDPR, SOC2 vb.) değişiklik izleme, kimlik doğrulama ve erişim kontrolleri gerektiriyor.
• Supply‑chain saldırıları (örn. image poisoning) ve runtime exploitler operasyonel riskleri artırıyor.

Kimler için önemli?

• Platform mühendisleri, SRE ve DevOps ekipleri
• Güvenlik mühendisleri ve bulut mimarları
• Uygulama geliştiriciler – güvenli image üretimi ve dağıtımı için

Hangi problemleri çözüyor?

• Erişim kontrolü ve ilke temelli yönetim
• Network segmentasyonu ve workload izolasyonu
• Image ve CI/CD güvenliği, secret sızıntılarının önlenmesi

2. KAVRAMSAL TEMELLER

2.1 Güvenlik modelleri ve sorumluluk

Kubernetes güvenliği paylaşılan bir sorumluluk modelidir: cloud provider yönetilen bileşenler (managed control plane) ile kullanıcıya düşen görevler (pod güvenliği, network policy, image hardening) ayrışır. Platform mühendisleri genelde kontrol düzlemi ve altyapının güvenliğini sağlar; uygulama ekipleri image üretimi ve runtime güvenliğinden sorumludur.

2.2 Temel bileşenler ve terminoloji

• API Server: Kubernetes'e erişimin merkezi kapısı; authentication, authorization ve admission controller'lar burada çalışır.
• etcd: Cluster'ın source‑of‑truth'u; şifrelenmiş ve sıkı erişim kontrolü gerektirir.
• RBAC: Role‑based access control; kim hangi API kaynaklarına hangi yetkilerle erişebileceğini tanımlar.
• Pod Security: Runtime güvenlik kontrolleri, PodSecurity Admission veya OPA/Gatekeeper policy'leriyle uygulanır.
• NetworkPolicy: Pod seviyesinde trafik kontrolü sağlar; CNI tarafından uygulanır.
• Image signing / Notary / Cosign: Image provenance ve imza doğrulama çözümleridir.

3. NASIL ÇALIŞIR? — KONTROL DÜZLEMİNDEN RUNTIME'A UZANAN GÜVENLİK

3.1 API Server güvenliği

API Server erişimi korunmalıdır: TLS zorunlu, client cert authentication veya OIDC temelli kimlik doğrulama kullanılmalı, audit logging aktif olmalıdır. API Server için public erişim gerekiyorsa, bastion/ingress ve IP whitelisting gibi ilave network kısıtlamaları uygulayın. Admission controller'ları aktif kullanmak (PodSecurity, OPA/Gatekeeper) istenmeyen konfigürasyonları erkenden engeller.

3.2 etcd güvenliği

etcd'yi şifrelemek (TLS iletişim), erişimi sadece API Server ile sınırlandırmak, düzenli yedek ve restore testleri yapmak kritik önemdedir. etcd snapshot'ları hassas veri içerebileceği için storage backend'lerinde encryption at rest ve erişim kontrolü uygulanmalıdır.

3.3 RBAC ve least‑privilege

RBAC politikaları en ince yetki düzeyine göre tasarlanmalıdır. ServiceAccount'lar uygulama bazında ayrılmalı; default service account kullanımından kaçınılmalıdır. Audit log'larında anormal API çağrılarını tespit edecek alert'ler konulmalıdır. Role ve RoleBinding kullanımı namespace‑level yetkilendirme sağlar; ClusterRole ise cluster seviyesinde dikkatle uygulanmalıdır.

3.4 Pod Security: Admission ve runtime

PodSecurity Admission, immutability ilkesi, basit kurallarla (privileged, hostNetwork, hostPID, capabilities) pod'ların güvenlik profilini denetler. Daha kompleks policy ihtiyaçları için OPA/Gatekeeper veya Kyverno kullanılabilir. Runtime güvenliği için Falco (runtime syscall monitoring), eBPF tabanlı izleme ve seccomp profilleri ile potansiyel exploit'ler tespit edilmelidir.

3.5 NetworkPolicy ve microsegmentation

NetworkPolicy ile pod‑pod trafik izinleri sınırlandırılmalı; default deny politikası başlangıç için önerilir. CNI seçimi (Calico, Cilium) policy enforcement ve L7/kural yeteneklerini etkiler. Service mesh'ler (Istio, Linkerd) ek güvenlik katmanları (mTLS, policy) sunsa da network policy katmanı halen kritik önemdedir.

3.6 Secrets yönetimi

Kubernetes Secrets base64 encode edilmiş objelerdir — bu yeterli değil. Secrets'ı KMS‑backed store (Vault, AWS Secrets Manager, Azure Key Vault) ile tutmak ve pod'lara runtime'da inject etmek en iyi uygulamadır. Encryption at rest (etcd) ve pod seviyesinde RBAC sınırlandırması uygulanmalıdır.

3.7 Image provenance ve supply‑chain güvenliği

Güvenli image üretimi; build pipelines'ta SBOM üretimi, vulnerability scanning (Trivy, Clair), image signing (Cosign, Notary) ve registry access kontrolü gerektirir. Admission controller ile yalnızca imzalı ve taranmış image'ların çalıştırılması sağlanmalıdır. CI/CD pipeline'larında secret management, least‑privilege ve artifact provenance otomasyonu kritik unsurlardır.

3.8 Runtime hardening ve host güvenliği

Node OS hardening, kernel parametreleri, sadece gerekli container runtime'ların kullanılması, read‑only root filesystem, seccomp ve AppArmor profilleri uygulanmalıdır. Node erişimi SSH ile sınırlandırılmalı, kubelet ve kube‑proxy iletişimleri TLS ile korunmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — Observability ve policy

Netflix ölçeğinde güvenlik, yüksek gözlemlenebilirlik ve policy enforcement ile birleşir. Canary deploy'lar, anomaly detection ve geniş telemetry ile saldırı/hatayı erken tespit etme stratejileri uygulanır.

4.2 Uber — Multi‑tenant izolasyon

Çok sayıda ekip ve tenant'ı barındıran platformlarda namespace, RBAC ve network policy ile güçlü izolasyon gereklidir. Ayrıca kontrol düzlemi ve node provisioning süreçleri otomatikleştirilir ve kurallar CI ile enforce edilir.

4.3 Amazon / GKE / AKS — Managed güvenlik özellikleri

Managed Kubernetes hizmetleri kontrol düzlemi yönetimini üstlenir ancak kullanıcı hala pod güvenliği, network policy ve image hardening sorumluluğundadır. Cloud vendor'ların sunduğu CSPM/Cloud‑native security özellikleri (GuardDuty, Security Center) ek koruma sağlar.

4.4 OpenAI — Model serving ve data governance

MLOps senaryolarında data access governance, model provenance ve GPU node'larının güvenliği öne çıkar. Secret ve token yönetimi, audit trail ve access policy'leri kritik önemdedir.

4.5 Stripe — Fintech ve compliance

Finans sektöründe RBAC, audit logging, immutable infrastructure ve key management politikaları regülasyon uyumluluğu için zorunlu hale gelir. Immutable images, tam izlenebilirlik ve sıkı review süreçleri uygulanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• İyi yapılandırıldığında yüksek seviyede otomasyon, izlenebilirlik ve ilke temelli güvenlik sağlar.
• Policy as code ve admission kontrol ile güvenlik önlemleri CI/CD'ye entegre edilebilir.
• Ekip izolasyonu, RBAC ve network policy ile uygulanabilir.

Sınırlamalar

• Karmaşık bir teknoloji; eksik veya hatalı konfigürasyon ciddi güvenlik açıklarına yol açar.
• Çok katmanlı güvenlik gereksinimleri operasyonel maliyet artırır.
• Container ve Kubernetes bilgi eksikliği olan takımlar için uygulama güvenliği zayıf kalabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Production kullanımı

• Control plane ve etcd erişimini minimize edin; API Server için güçlü authentication (OIDC, mTLS) ve audit logging etkinleştirin.
• Default deny network policy ile başlayın ve gerektiği kadar izin verin.
• PodSecurity admission veya OPA/Gatekeeper ile kuralları enforce edin (privileged, hostPath, capabilities).
• Image signing, SBOM üretimi ve vulnerability scanning pipeline'larını CI'ye entegre edin.

7.2 Performans ve ölçeklenebilirlik

• Audit log, Falco veya eBPF kaynaklarını dikkatle boyutlandırın; yüksek cardinality telemetry maliyeti artırır.
• Policy değerlendirme maliyetini azaltmak için admission controller'ları optimize edin; preflight (CI) kontroller ile runtime yükünü azaltın.

7.3 Güvenlik operasyonu

• Incident response playbook'ları hazırlayın: pod/namespace izolasyonu, image rollback, restore prosedürleri.
• RBAC ve service account'ları düzenli olarak gözden geçirin; unused permissions'ları revoke edin.
• Etkin izleme: suspicious API calls, anomalous network flows, unexpected container exec/attach olayları.

8. SIK YAPILAN HATALAR

• Secrets'ı doğrudan Kubernetes secret olarak açık bırakmak ve etcd'yi şifrelememek.
• RBAC politikalarını geniş (overprivileged) tutmak — principle of least privilege uygulanmaması.
• NetworkPolicy olmadan "flat" ağ bırakmak; lateral movement riski yükselir.
• Image tarama ve imza doğrulamadan production'a image push etmek.
• Admission controller'ları CI içinde test etmeden prod'a açmak.

9. GELECEK TRENDLER

1. Supply‑chain security'nın zorunluluk hâline gelmesi: SBOM, signed artifacts ve provenance otomasyonları standartlaşacak.
2. eBPF tabanlı runtime koruma: Kernel seviyesinde realtime monitoring ve policy enforcement daha yaygın olacak.
3. AI tabanlı anomaly detection: Telemetry'den öğrenen modeller ile saldırı ve anomali tespiti gelişecek.
4. Policy as code ekosisteminin olgunlaşması: OPA/Gatekeeper, Kyverno gibi araçlarla politika yaşam döngüsü standardize edilecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Kubernetes'te ilk hangi güvenlik önlemini almalıyım?

   Default deny NetworkPolicy, RBAC temelli least‑privilege ve PodSecurity Admission ile başlamanızı öneririm. Bu üç katman temel korumayı sağlar.

2. 2. Secrets'ı Kubernetes'e nasıl güvenle koyarım?

   Secrets'ı dış bir KMS veya Vault gibi çözümlerle saklayıp runtime'da inject edin; etcd encryption at rest ve access kontrol uygulayın.

3. 3. Image signing neden gerekli?

   Image signing ile hangi build'ın, hangi binary'yi içerdiği doğrulanabilir. Bu, supply‑chain saldırılarına karşı önemli bir savunmadır.

4. 4. OPA/Gatekeeper ile ne tür politikalar yazabilirim?

   Image allowlist, resource limit enforcement, disallowed capabilities, allowed hostPath ve network politika gereksinimleri gibi birçok custom kural yazabilirsiniz.

5. 5. Runtime saldırıları nasıl tespit edilir?

   Falco, eBPF‑based monitoring ve audit log correlation ile şüpheli syscalls, exec events ve network anomalileri tespit edilebilir.

6. 6. Managed Kubernetes güvenli mi?

   Managed control plane avantaj sağlar; fakat pod güvenliği, network policy ve image hardening yine kullanıcı sorumluluğundadır.

7. 7. Admission controller'ları CI'de mi yoksa runtime'da mı çalıştırmalıyım?

   Her ikisi de gerekir. CI'de preflight kontroller ile hataları erkende yakalayın, runtime admission controller ile son savunma hattını sağlayın.

8. 8. eBPF hangi alanlarda yardımcı olur?

   Network visibility, syscall monitoring, L7 policy enforcement ve yüksek performanslı observability için eBPF çok güçlüdür.

Anahtar Kavramlar

RBAC

Role‑based access control — kullanıcı ve servis hesapları için izin yönetimi.

PodSecurity Admission

Pod konfigürasyonlarını runtime öncesi doğrulayan admission controller.

NetworkPolicy

Pod seviyesinde inbound/outbound trafik kontrolü.

OPA / Gatekeeper

Policy as code için kullanılan açık kaynak araçlar; admission aşamasında politikaları enforce eder.

SBOM

Software Bill of Materials — artifact içeriğinin tanımı, supply‑chain güvenliği için gereklidir.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes temel kavramları (Pod, Service, Namespace), RBAC temel komutları, basit NetworkPolicy uygulamaları öğrenin.
2. 1–3 ay: PodSecurity, Admission controller'lar (GYatekeeper/OPA, Kyverno), secrets management (Vault) ve temel image hardening pratiklerini uygulayın.
3. 3–6 ay: Runtime monitoring (Falco, eBPF), image signing (Cosign), SBOM ve CI/CD pipeline entegrasyonları üzerinde çalışın.
4. 6–12 ay: Policy as code yaşam döngüsü, incident response playbook'ları ve cluster hardening konularında deneyim kazanın.