Kubernetes'te Production Debug Güvenliği: Rehber

⏱️ 12 dk okuma📅 22 Nisan 2026🔄 Güncelleme: 15 Temmuz 2026👁️ görüntülenme

Şöyle bir sahne düşünün: Gece saat 02:00, production’da bir pod durmadan crash loop’a giriyor, Slack kanalı da resmen alarm modunda. Nöbetçi arkadaş ne yapıyor? Hemen cluster-admin alıyor, bastion sunucuya bağlanıyor, oradan kubectl exec ile pod’a dalıyor; sorun çözülüyor, tamam. Ama işin can sıkıcı tarafı şu: O cluster-admin yetkisi hâlâ orada dürüyor, bastion’daki SSH key de expire olmamış oluyor, iki hafta sonra bakıyorsunuz ki o “geçici” erişim artık herkesin alışkanlığına dönüşmüş. Kötü sürpriz.

📋 İçindekiler

Özellik	Sadece RBAC	RBAC + Access Broker
Pod exec izni	✅ Var	✅ Var
Komut kısıtlama (exec içinde)	❌ Yok	✅ Var
Manuel onay gerektirme	❌ Yok	✅ Var
Otomatik session expire	❌ Yok (token ömrüne bağlı)	✅ Var
Session kaydı (video/text)	❌ Yok	✅ Var
Grup yönetimi (dinamik)	Kısmen (IdP ile)	✅ Tam entegre

Broker’ın policy’si bir JSON ya da YAML dosyasında tutulabiliyor ve — açıkçası benim en sevdiğim taraf da bu — Git’te versiyonlanıp code review sürecinden geçebiliyor. “Production debug policy’sını değiştireyim” diyorsunuz, PR açıyorsunuz, biri bakıyor, yorum yazıyor, sonra merge oluyor; yanı güvenlik politikası da bildiğin IaC disiplinine giriyor, fena değil.

Küçük bir startup için bu kadar katman şart mı? Açık konuşayım, çoğu zaman değil. Beş kişilik ekipseniz ve tek namespace’ınız varsa, RBAC ile kısa ömürlü credential’lar idare eder; ama 50+ kişilik ekipte, multi-tenant cluster’da, üstüne bir de regülasyon baskısı varsa (şaşırtıcı ama gerçek). iş değişiyor.

Neyse uzatmayalım. Enterprise tarafına geçtiğiniz anda broker ihtiyacı kendini gösteriyor, hatta bazen sessizce değil bayağı yüksek sesle geliyor.

Evet.

Pratik Uygulama Rehberi: Nereden Başlamalı?

Bakın, Tamam, teori tamam. Peki yarın sabah ne yapacaksınız? Ben olsam işi uzatmadan şöyle başlarım, çünkü ilk gün hedefi doğru koymazsanız sonra her şey biraz dağınık gidiyor, bir bakmışsınız yetki listesi büyümüş, kim neye erişiyor belli değil, sonra da “biz bunu nasıl öldü da fark etmedik?” diye dönüp duruyorsunuz.

1. Mevcut RBAC durumunuzu audit edin. kubectl get clusterrolebindings -o json ile başlayın. Kaç tane cluster-admin binding var? Bunların kaçı gerçekten lazım? Geçen ay bir müşteride 23 tane cluster-admin binding bulduk — 19’u gereksizdi. Açık konuşayım, sayı ilk bakışta küçük gibi geliyor ama detaylara inince tablo değişiyor; işte asıl mesele de bu, görünmeyen fazlalıklar en çok buradan çıkıyor.

Bakın, 2. Namespace bazlı debug Role’leri oluşturun. Yukarıdaki örneği template gibi kullanın, sonra her team’in ihtiyacına göre ufak ufak oynayın. Herkese aynı kalıbı vermek kolay,. Pratikte pek işlemiyor; mesela bir ekip sadece log okuyacakken diğeri pod içine girip bakmak istiyor, yanı ihtiyaç aynı değil, rol de aynı kalmamalı.

Tuhaf ama, 3. Statik kubeconfig’leri temizleyin. Eğer hâlâ static token veya client certificate ile erişim varsa, bunları OIDC tabanlı kimlik doğrulamaya geçirin. AKS’deyseniz Entra ID entegrasyonu iş görüyor, vanilla Kubernetes tarafında işe Dex veya Keycloak kullanabilirsiniz; burada önemli olan tek şey modern görünmek değil, yönetilebilir ve izlenebilir bir akış kurmak.

4. Gateway veya broker değerlendirin. Teleport, Boundary (HashiCorp) veya kendi çözümünüzü düşünün. Bütçe sıkışıksa açık kaynak seçeneklere — en azından ben öyle düşünüyorum — bakın — Teleport Community Edition fena değil, hatta baya iş görüyor. Şey… burada küçük bir not düşeyim: her ortamda broker şart değil ama yetkiyi doğrudan kümeye saçıyorsanız, sonra toparlaması can sıkabiliyor.

Hmm, bunu nasıl anlatsamdı…

💡 Bilgi: AKS kullanıyorsanız, Azure Policy + Entra ID Conditional Access kombinasyonu ile broker benzeri bir yapı kurabilirsiniz. Tam bir broker kadar esnek olmasa da, “sıfır maliyet” avantajı var. Maliyet hassasiyeti olan Türkiye’deki orta ölçekli şirketler için güzel bir başlangıç noktası.

Bir de şunu ekleyeyim: bu süreçte en çok direnci “ama incident anında yavaşlar” argümanından göreceksiniz. Haklı bir endişe. O yüzden break-glass (acil durum) prosedürünü de tanımlayın; yanı cluster-admin yetkisi olsun ama sadece emergency durumda açılsın, otomatik expire etsin ve mutlaka post-incident review’a girsin. Daha önceki yazılarımda Kubernetes güvenlik konularına da değinmiştim — Kubernetes’te AI Agent Sandbox: Pratik Rehber yazısında sandbox isolation konusunu detaylı ele almıştım, orası da ilgili bir referans. Sız ne dersiniz? Peki neden? Çünkü kağıt üstünde hızlı görünen şeyler, olay gerçek hayatta patlayınca çoğu zaman ters köşe yapıyor.

Audit Log’ları: Kanıt Yoksa Güvenlik de Zayıf Kalıyor

Ve son bir şey daha: hatta çoğu kişinin ilk vazgeçtiği yerde, audit log’larını açın ve merkezî bir yere akıtın. Kubernetes audit policy ile hangi API çağrısının loglanacağını seçiyorsunuz; işin aslı, burada fazla yaratıcı olmaya gerek yok, en azından pods/exec, pods/portforward, secrets erişimleri. RBAC değişiklikleri kayıt altına alınmalı.

Hmm, bunu nasıl anlatsamdı…

pods/exec — kim hangi pod’da komut çalıştırdı
pods/portforward — kim hangi porta tünel açtı
secrets — kim hangi secret’a erişti (bunu loglamak BDDK/KVKK tarafında neredeyse şart gibi)
RBAC değişiklikleri — kim yeni binding oluşturdu veya role değiştirdi

Bu log’ları Azure Monitör, Elastic ya da Loki’ye gönderin. Kubernetes’in varsayılan retention süresi kısa kalıyor, ayrıca audit log’u etcd içinde tutmak pek akıllıca değil (performans düşüyor, kapasite şişiyor, sonra bir bakmışsınız sistem nefes nefese). Azure DevOps Güvenlik Taraması: Tek Tıkla Başlıyor yazısında da güvenlik taraması tarafına değinmiştim, orası da yanına iyi gidiyor.

AZ-500 sınavına hazırlanırken bu audit işiyle epey uğraştım. Sınavda da çıkıyor zaten; “en az yetki prensibi ile audit log’ları nasıl birlikte çalışır?” gibi sorular geliyor. Teori tamam da, pratikte uygulayanı hâlâ az görüyorum maalesef.

Evet.

Sıkça Sorulan Sorular

Production debug için cluster-admin yetkisi vermek neden bu kadar riskli?

Şöyle düşün: cluster-admin tüm namespace’lerde, tüm kaynaklarda sınırsız yetki veriyor. Bir hata ya da kötü niyetli bir kullanım, tüm cluster’ı yerle bir edebilir. Bir de üstüne ortak kullanıldığında kimin ne yaptığını takip etmek neredeyse imkansız hâle geliyor. Bence bu, “şimdilik böyle kalsın” deyip geçiştirilen ama sonradan çok pişman olunan konuların başında geliyor. Burada, bunun yerine namespace bazlı, sadece gerçekten gerekli yetkileri içeren Role tanımları kullanın.

Kubernetes RBAC, exec session içinde çalıştırılan komutları kısıtlayabiliyor mu?

Hayır, kısıtlayamıyor. RBAC aslında sadece “bu kullanıcı pods/exec yapabilir mi?” sorusunu yanıtlıyor. İçeride hangi komutun çalıştığıyla hiç ilgilenmiyor (ben de ilk duyduğumda şaşırmıştım). Yanı komut kısıtlaması istiyorsanız, üzerine bir access broker veya gateway katmanı eklemeniz şart — başka yolu yok.

Kısa ömürlü credential nasıl oluşturulur?

İnanın, OIDC tabanlı kimlik doğrulama kullanarak yapabilirsiniz bunu. AKS’de Entra ID entegrasyonu zaten varsayılan olarak sağlıyor. Vanilla Kubernetes’te işe Dex, Keycloak veya benzeri bir OIDC provider kurmanız. Token lifetime’ını — mesela 30-60 dakika arası — ayarlamanız gerekiyor. Açıkçası bu kurulumu bir kez yapınca “neden daha önce yapmadım” diyorsunuz.

Bu yapıyı küçük bir ekipte de kurmak gerekli mi?

Tam gateway + broker yapısı, hani 5 kişilik bir startup için gerçekten overkill olabilir. Ama en azından iki şeyi her ölçekte yapmalısınız: namespace bazlı RBAC ve statik token yerine OIDC tabanlı erişim. Bunlar pazarlık konusu değil bence. Bir de regülasyon altındaysanız — finans, sağlık, kamu gibi — ekip büyüklüğü hiç fark etmiyor, audit trail zorunlu.

Break-glass (acil durum) erişimi nasıl tasarlanmalı?

Tecrübeme göre en sağlıklı yaklaşım şu: ayrı bir ClusterRoleBinding oluşturun ama normalde kimseye atamayın. Acil durumda belirli bir onay süreciyle — ya da otomatik. Zaman sınırlı olarak — bu binding aktif edilsin, incident sonrası da otomatik expire olsun. Önemli olan şu: tüm break-glass kullanımlarını mutlaka post-incident review’da masaya yatırın. Yoksa “bir daha olmaz” denen şeyler hep tekrarlanıyor.

Kaynaklar ve İleri Okuma

Kubernetes RBAC Resmî Dokümantasyonu (şaşırtıcı ama gerçek)

Açıkçası, Kubernetes Auditing Rehberi

AKS’de Azure RBAC ile Kubernetes Yetkilendirmesi — Microsoft Docs

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102