Kubernetes Güvenliği 2026: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench

**152**Mesaj · 10-18-2026, 05:07 PM

Merhaba arkadaşlar,

Kubernetes, modern uygulamaların çalıştığı fiili standart haline geldi; ama varsayılan bir küme güvenli değildir. Yanlış yapılandırılmış RBAC, ayrıcalıklı pod'lar ve kısıtlanmamış ağ trafiği, saldırganın bir konteynerden tüm kümeye yayılmasına zemin hazırlar. Bu rehberde Kubernetes güvenliğinin dört temel taşını resmi Kubernetes belgelerine dayanarak savunma gözüyle ele alıyorum: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench ile CIS denetimi. Tüm komutlar kendi test kümenizde (örneğin minikube/kind) çalıştırılmalıdır.

Konuda Anlatılacaklar

Kubernetes saldırı yüzeyi
RBAC ile en az yetki
Pod Security Standards ve Admission
NetworkPolicy ile ağ segmentasyonu
Secret yönetimi
kube-bench ile CIS denetimi
Test lab kurulumu

Kubernetes Saldırı Yüzeyi

Bir Kubernetes kümesinde başlıca risk alanları: API sunucusuna aşırı geniş erişim (RBAC), konteyner kaçışına izin veren ayrıcalıklı pod'lar, pod'lar arası sınırsız yatay trafik (lateral movement), açıkta kalan Secret'lar ve güncellenmemiş bileşenler. Savunma, bu alanların her birine bir kontrol koymaktır.

RBAC ile En Az Yetki

Role-Based Access Control (RBAC), kimin hangi kaynak üzerinde ne yapabileceğini belirler. Kubernetes belgelerine göre Role (namespace kapsamlı) veya ClusterRole (küme geneli) ile izinler tanımlanır, RoleBinding/ClusterRoleBinding ile özneye (kullanıcı, grup, ServiceAccount) atanır. Altın kural: geniş "cluster-admin" dağıtmak yerine dar roller verin.

Yalnızca belirli bir namespace'te pod okuyabilen bir rol örneği:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: uygulama
  name: pod-okuyucu
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Bu rolü bir ServiceAccount'a bağlamak:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-okuyucu-baglama
  namespace: uygulama
subjects:
- kind: ServiceAccount
  name: izleme-sa
  namespace: uygulama
roleRef:
  kind: Role
  name: pod-okuyucu
  apiGroup: rbac.authorization.k8s.io

Kendi yetkinizi kontrol etmek için kubectl'in yerleşik aracı:

Kod:
kubectl auth can-i create deployments --namespace uygulama
kubectl auth can-i '*' '*' --all-namespaces

İkinci komut "yes" dönüyorsa fazla yetkiniz var demektir; bunu daraltın.

Pod Security Standards ve Admission

Kubernetes, PodSecurityPolicy'yi kaldırdı ve yerine yerleşik Pod Security Admission denetleyicisini getirdi. Üç profil vardır: privileged (kısıtsız), baseline (bilinen ayrıcalık yükseltmelerini engeller) ve restricted (sıkı en iyi uygulamalar). Belgelerine göre profiller namespace etiketleriyle uygulanır. "restricted" profili zorunlu kılan etiketleme:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.37

enforce dışında audit ve warn modları da vardır; önce warn/audit ile etkisini görmek iyi bir yaklaşımdır:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted --overwrite

Pod tanımında da sertleştirme yapın: ayrıcalıklı çalıştırmayın, kök olmayan kullanıcı kullanın, salt okunur kök dosya sistemi tercih edin:

Kod:
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

NetworkPolicy ile Ağ Segmentasyonu

Varsayılan olarak bir kümedeki tüm pod'lar birbiriyle serbestçe konuşabilir. NetworkPolicy ile bunu kısıtlarsınız (CNI eklentinizin NetworkPolicy desteklemesi gerekir). Önce namespace'te tüm gelen trafiği varsayılan olarak reddeden bir politika:

Kod:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: varsayilan-ingress-reddet
  namespace: uygulama
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Boş podSelector tüm pod'ları seçer; ingress kuralı tanımlanmadığı için hiçbir gelen trafiğe izin verilmez. Sonra yalnızca gereken trafiği açarsınız (örneğin frontend'den backend'e). Bu "önce hepsini kapat, sonra gerekeni aç" yaklaşımı sıfır güven (zero trust) ağ modelinin temelidir.

Secret Yönetimi

Kubernetes Secret'ları varsayılan olarak yalnızca base64 ile kodlanır, şifrelenmez. Belgelere göre etcd'de bekleyen veri şifrelemesini (encryption at rest) etkinleştirmek ve Secret'lara RBAC ile erişimi kısıtlamak gerekir. Secret'ları asla git deposuna düz metin olarak koymayın; dışarıdan bir gizli bilgi yöneticisi (ör. harici KMS) ile entegrasyon tercih edin. Bir Secret'ı kimlerin okuyabildiğini RBAC ile sınırlayın; "get secrets" iznini herkese vermeyin.

kube-bench ile CIS Denetimi

Aqua Security'nin açık kaynak aracı kube-bench, kümeyi CIS Kubernetes Benchmark'a göre denetler. Resmi belgelere göre küme içinde bir Job olarak çalıştırılır:

Kod:
kubectl apply -f job.yaml
kubectl get pods
# kube-bench-xxxxx Completed olduğunda:
kubectl logs kube-bench-xxxxx

Belgelerde belirtildiği gibi Job hostPID ve host yolu bağlamaları kullanır; kontrol düzlemi düğümünde çalışması için gerekirse nodeSelector ve toleration ekleyin. Çıktı [PASS]/[FAIL]/[WARN] olarak gelir; FAIL maddelerini önceliklendirin.

İleri Seviye: Test Lab Kurulumu

Üretim kümesinde deneme yapmayın. Kendi bilgisayarınızda bir test kümesi kurun:

Kod:
# minikube ile
minikube start --kubernetes-version=stable
kubectl create namespace uygulama
kubectl label namespace uygulama pod-security.kubernetes.io/warn=restricted
# ihlal eden bir pod deneyin, uyariyi gorun
kubectl run test --image=nginx -n uygulama

Bu lab'da RBAC rollerini, PSA profillerini ve NetworkPolicy'leri güvenle deneyip davranışı gözlemleyebilirsiniz. Ardından bir zafiyet tarayıcısıyla (örneğin imajlar için Trivy) konteyner imajlarınızı da tarayın.

Sonuç

Kubernetes güvenliğinde dört temel: RBAC ile en az yetki, Pod Security Admission ile restricted profil, NetworkPolicy ile "önce kapat sonra aç" segmentasyon ve kube-bench ile düzenli CIS denetimi. Bunları bir test kümesinde deneyip sonra üretime taşıyın. Siz kümelerinizde hangi kontrolü ilk uyguluyorsunuz? Yorumlarda paylaşın.

Kaynakça

Kubernetes, Using RBAC Authorization: https://kubernetes.io/docs/reference/acc...uthz/rbac/
Kubernetes, Pod Security Admission: https://kubernetes.io/docs/concepts/secu...admission/
Kubernetes, Enforce Pod Security Standards with Namespace Labels: https://kubernetes.io/docs/tasks/configu...ce-labels/
Kubernetes, Network Policies: https://kubernetes.io/docs/concepts/serv...-policies/
Kubernetes, Encrypting Confidential Data at Rest: https://kubernetes.io/docs/tasks/adminis...rypt-data/
Kubernetes, Authorization (kubectl auth can-i): https://kubernetes.io/docs/reference/acc...orization/
Aqua Security, kube-bench: https://aquasecurity.github.io/kube-bench/

Yasal Uyarı

Bu rehberdeki tüm komutlar yalnızca kendi test kümenizde veya yazılı olarak yetkilendirildiğiniz ortamlarda çalıştırılmalıdır. Başkasına ait Kubernetes kümelerine izinsiz erişim veya denetim 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Kubernetes Güvenliği 2026: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench

Forum

Topluluk

Yardım