1. Kubernetes Güvenlik Temelleri
K8s güvenliği, tek bir ayar değil; katmanlar sistemidir. En pratik okuma sırası:
- Cluster erişimi (kubeconfig, API server)
- Yetkilendirme (RBAC)
- İzolasyon (namespace)
- Ağ politikaları (NetworkPolicy/Ingress)
- Node ve pod güvenliği (OS hardening, Pod Security)
Kubernetes cluster güvenliği nasıl sağlanır?
Kubernetes güvenliği; cluster API erişimini kısıtlamak, RBAC ile least-privilege rol matrisi kurmak, namespace ile projeleri/ortamları ayırmak ve NetworkPolicy ile pod trafiğini default-deny yapıp sadece gerekli iletişime izin vermekle başlar. Node OS hardening ve Pod Security kontrolleri modeli tamamlar.
Default riskler (neden “sonra bakarız” tehlikeli?)
- •Geniş yetkili servis hesapları
- •Namespaceler arası kontrolsüz erişim
- •Pod’ların sınırsız outbound/ingress trafiği
- •Kubeconfig/cluster credential sızıntısı
☑ Mini Check : İlk 30 gün güvenlik barı
- •Kubeconfig erişimleri kişiye özel ve geri alınabilir mi?
- •Cluster-admin kimlerde? Minimal mi?
- •Namespace’ler proje/ortam bazlı ayrıldı mı?
- •NetworkPolicy var mı (default-deny hedef)?
- •Pod’lar non-root / minimum capability ile mi çalışıyor?
Ne yapmalıyım?
- • Cluster-admin erişimini daralt, audit et.
- • Namespace’leri proje+env bazlı ayır.
- • NetworkPolicy ile “herkes her yere”yi kapat.
- • Pod Security standardı koy (non-root, read-only FS hedefi).
2. Cluster ve Node Güvenliği
K8s’te cluster güvenliği API server erişimi ve kubeconfig yönetimiyle başlar. Node güvenliği ise container’ların üzerinde koştuğu zemindir: OS hardening, patch ve runtime kısıtları olmazsa izolasyon zayıflar.
Kubeconfig ve erişim hijyeni
- •Kubeconfig kişiye özel olmalı
- •Eski kullanıcı erişimi hızlı kapatılmalı
- •CI/CD servis hesapları ayrı yönetilmeli
- •Mümkünse IP/konum kısıtı ve MFA ile birlikte düşünülmeli
Node OS hardening
- •Patch yönetimi ve minimal OS yaklaşımı
- •Gereksiz servis kapatma
- •Runtime güvenliği (container runtime policy)
- •Log/metric ajanlarının standardize edilmesi
☑ Mini Check : Cluster/node güvenliği
- •Cluster erişimi (kubeconfig) envanterli mi?
- •Cluster-admin erişimleri kayıtlı mı?
- •Node OS patch rutini var mı?
- •Node’larda gereksiz servisler kapalı mı?
- •Node log/metrics izleniyor mu? (Internal link: /tr/veri-analiz-ve-raporlama)
Ne yapmalıyım?
- • Kubeconfig ve servis hesabı erişimini envanterle.
- • Node’ları “golden baseline” ile harden et.
- • Upgrade/patch sürecini bakım döngüsüyle senkronla (Internal link: /tr/yazilim/bakim-ve-destek).
- • Node gözlemlenebilirliğini (log/metrics) standartlaştır.
3. Namespace ile İzolasyon
Namespace, K8s’te izolasyonun ilk katmanıdır: projeleri, ortamları (staging/prod) ve ekipleri ayırır. Doğru kullanılmazsa “her şey default namespace’de” anti-pattern’i oluşur.
RBAC ve namespace ile neyi izole etmeliyim?
Namespace ile proje ve ortamları ayırmalı; RBAC ile her ekibin/sistemin sadece kendi namespace’ine erişmesini sağlamalısınız. Prod namespace’inde daha sıkı erişim ve deploy kuralları, staging’de daha kontrollü esneklik uygulanabilir. Bu ayrım, hem güvenliği hem operasyonel netliği artırır.
Proje/çevre (env) ayrımı
- •project-a-prod, project-a-staging gibi net isimlendirme
- •Shared servisler için ayrı namespace (observability gibi)
- •Çok tenant’lı B2B’de tenant izolasyonu için ek politika (mimariye göre)
☑ Mini Check : Namespace hijyeni
- •Default namespace boş veya minimum mu?
- •Prod/staging namespace’leri ayrık mı?
- •Ekip bazlı erişim sınırları net mi?
- •Secret/config dağıtımı namespace bazlı mı?
- •Namespace arası iletişim NetworkPolicy ile kontrol ediliyor mu?
Ne yapmalıyım?
- • Default namespace’i “çalışma alanı” olmaktan çıkar.
- • Prod/staging ayrımını isimlendirme + RBAC ile uygula.
- • Shared servisleri ayrı namespace’e al.
- • Namespace bazlı secret yönetimini standardize et.
4. Network Policy ve Ingress Kuralları
Kubernetes’te “asıl büyük risk” çoğu zaman budur: NetworkPolicy yoksa pod’lar birbirine ve dışarıya sınırsız konuşabilir. Bu, lateral movement ve veri sızıntısı riskini büyütür.
NetworkPolicy neden önemli, nasıl kurgulanır?
NetworkPolicy, pod’lar arası trafiği kontrol ederek “default allow” durumunu “default deny” yaklaşımına çevirir. Önerilen kurgulama; önce namespace içinde ve namespace’ler arası iletişimi kapatmak, sonra sadece gerekli servis→servis akışlarına izin vermektir. Ingress kuralları da dış dünyadan iç servislere giriş noktalarını sınırlar ve WAF/rate limit ile tamamlanır.
“Herkesten herkese” trafiği kesmek için pratik yaklaşım
- •İlk adım: default-deny policy (en azından prod)
- •İkinci adım: gerekli allowlist (API gateway→service, service→DB)
- •Üçüncü adım: outbound kontrolü (mümkünse)
- •Dördüncü adım: gözlemle/kalibre et (breakage yönetimi)
Pod Security (context, capabilities, read-only FS) ile tamamlamak
NetworkPolicy yalnız ağdır; pod içi yetkiler de kısıtlanmalıdır:
- •Non-root çalıştırma
- •Minimum capabilities
- •Read-only filesystem hedefi
- •Secret’ların doğru mount edilmesi
☑ Mini Check : Policy seti
- •Prod namespace’lerinde default-deny var mı?
- •Gerekli servis akışları allowlist ile tanımlı mı?
- •Ingress giriş noktaları minimal mi?
- •Pod security context non-root mu?
- •Network policy değişiklikleri versiyonlanıyor mu?
Ne yapmalıyım?
- • Prod’da default-deny ile başla, sonra allowlist ekle.
- • Ingress’i minimal tut; rate limit/WAF ile destekle.
- • Pod security standardı koy (non-root, read-only hedefi).
- • Policy değişikliklerini IaC/review ile yönet.
5. Otel ve B2B İçin K8s Senaryoları
K8s güvenliği, iş akışlarıyla bağlanmadıkça soyut kalır. Otel ve B2B’de tipik cluster senaryoları ve risk noktaları:
Otel — rezervasyon/raporlama microservice cluster’ı
- •Rezervasyon servisi: en kritik; policy en sıkı
- •Raporlama servisi: ağır işler; ayrı namespace/policy ve kaynak limit
- •Entegrasyon servisleri: outbound erişim daraltılmalı
- •Observability: log/metric standardı zorunlu
B2B — API ve worker cluster’ları
- •API gateway: ingress noktası; rate limit + policy
- •Worker’lar: outbound erişim minimal; queue tabanlı
- •Multi-tenant ise: namespace/policy stratejisi daha kritik
Otel ve B2B için K8s cluster güvenlik checklist’i nasıl olmalı?
Checklist; kubeconfig/RBAC erişim hijyeni, namespace izolasyonu, prod’da default-deny NetworkPolicy, ingress giriş noktalarının minimalleştirilmesi, node OS hardening, Pod Security (non-root/capabilities) ve log/metrics izlenebilirliğini içermelidir. Ayrıca upgrade’ler bakım döngüsüyle senkron yürütülmelidir.
Fark yaratan mini bölüm (Trend gerçekliği)
K8s kullanan ekiplerin çoğu ilk aşamada manifest’lere odaklanır; RBAC ve NetworkPolicy “sonra” kalır. Bu rehberin hedefi, “sonra”yı ilk 30–90 güne çekerek saldırı yüzeyini erkenden daraltmaktır.
☑ Mini Check : İlk 90 gün roadmap
- •RBAC least-privilege matrisi çıkarıldı
- •Namespace’ler proje/ortam bazlı ayrıldı
- •Prod default-deny NetworkPolicy var
- •Ingress minimal + korumalı
- •Node hardening + upgrade planı var
- •Log/metrics dashboard’ı hazır
Ne yapmalıyım?
- • RBAC ve namespace’i “ilk sprint” işi yap.
- • Prod default-deny policy’yi erken uygula; allowlist’i iteratif ekle.
- • Upgrade’leri bakım-destek planına bağla (Internal link: /tr/yazilim/bakim-ve-destek).
- • Log/metrics’i raporlama panellerine bağla (Internal link: /tr/veri-analiz-ve-raporlama).
6. İçerik içi tablo (Örnek RBAC / NetworkPolicy özeti)
| Alan | Amaç | Örnek kontrol (çerçeve) | Not |
|---|---|---|---|
| Kubeconfig | Erişim hijyeni | Kişi bazlı + offboarding | Paylaşılan config yok |
| RBAC | Least privilege | Role/ClusterRole minimal | Cluster-admin minimum |
| Namespace | İzolasyon | prod/staging ayrımı | Default namespace boş |
| NetworkPolicy | Trafik kontrolü | Prod default-deny + allowlist | Lateral movement azaltır |
| Pod Security | Yetki kısıtı | non-root, read-only hedefi | Privileged exception kayıtlı |
| Node hardening | Zemini sağlamlaştır | patch + minimal OS | Upgrade planı şart |
7. Kubernetes RBAC/Namespace/NetworkPolicy Güvenlik Checklist Şablonunu İndir
Kubernetes RBAC/Namespace/NetworkPolicy Güvenlik Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset; Kubernetes’te en yüksek etkiye sahip üç katmanı (RBAC, namespace izolasyonu, NetworkPolicy) hızlıca standardize etmek için hazırlanmıştır. Default-deny yaklaşımıyla lateral movement riskini azaltır; node hardening ve Pod Security kontrolleriyle tamamlar. Upgrade/bakım döngülerine entegre edilerek sürdürülebilir güvenlik sağlar.
Kim Kullanır?
DevOps/SRE, platform ekibi, otel/B2B microservice ekipleri.
Nasıl Kullanılır?
- Cluster erişim envanteri ve RBAC rol matrisini çıkar.
- Namespace planını oluştur ve prod’da default-deny NetworkPolicy uygula.
- Pod security + node hardening kontrollerini ekleyip periyodik doğrula.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kubeconfig erişimleri envanterli ve kişi bazlı
- ▢ ✅ Cluster-admin minimum
- ▢ ✅ RBAC least-privilege rol matrisi var
- ▢ ✅ Prod/staging namespace ayrımı var
- ▢ ✅ Default namespace kullanım dışı/minimum
- ▢ ✅ Prod’da default-deny NetworkPolicy var
- ▢ ✅ Allowlist servis akışları tanımlı
- ▢ ✅ Ingress giriş noktaları minimal + korumalı
- ▢ ✅ Pod Security (non-root, capabilities) standardı var
- ▢ ✅ Node hardening + upgrade planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •RBAC rol matrisi
- •Namespace planı
- •NetworkPolicy seti
- •Pod security standardı
- •Upgrade + observability planı
Bir Sonraki Adım
RBAC, namespace ve network policy’lerle cluster izolasyonunu kurup “herkes her yere” riskini azaltmak isteyen otel ve B2B K8s ekipleri için.
Sık Sorulan Sorular
Kubernetes cluster güvenliği nasıl sağlanır?▾
RBAC ve namespace ile neyi izole etmeliyim?▾
NetworkPolicy neden önemli, nasıl kurgulanır?▾
Otel ve B2B için K8s cluster güvenlik checklist’i nasıl olmalı?▾
Kubernetes kullanıyoruz ama güvenlik ayarlarını hiç ellemiyoruz, risk büyük mü?▾
İlgili İçerikler