Kubernetes’te Production Debug Güvenliği: Rehber
Şö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.
Tanıdık geldi mi? Bana da geldi (buna dikkat edin)
Geçen yıl bir finans kuruluşunda birebir bunu yaşadık. Incident sırasında verilen geniş yetkiler, 6 ay sonra audit’te karşımıza çıktı ve “bunu kim, neden verdi?” sorusu havada kaldı; kimse net cevap veremedi. İşte bu yazıda Kubernetes’te production debugging yaparken güvenliği nasıl koruyacağınızı, RBAC’i biraz sıkı tutarak, kısa ömürlü credential’larla ve SSH-tarzı gateway modelini kullanarak anlatacağım. Lafı gevelemeden girelim.
Sorunun Kökü: “Geçici” Yetkiler Neden Kalıcılaşıyor?
Bakın, burada teknik bir mesele var ama işin aslı kültürel tarafta düğümleniyor. Incident patladığında herkes hızlı çözüm istiyor, bu da normal; kimse o anda “dur bir dakika, şu RBAC policy’yi düzenleyeyim” diye oturmuyor, zaten production yanıyorken bürokrasiyle uğraşmak pek akıllıca gelmiyor.
Çok konuştum, örnekle göstereyim.
Ama sonra ne oluyor? Incident kapanıyor, herkes biraz nefes alıyor, retro’da da “yetkileri geri alalım” deniyor — itiraf edeyim, beklentimin üstündeydi —. ve garip biçimde kimse dönüp bakmıyor. Logosoft’ta bir telekom müşterisinde bunu birebir gördüm: 14 tane “geçici” ClusterRoleBinding vardı, bazıları 8 ay öncesinden kalmıştı. Hani şu “geçici vergi düzenlemesi” var ya, yıllarca rafta duran şey; aynı his. Evet.
İki temel dert var:
- Audit zorlaşıyor: Ortak bastion hesabı kullanınca kim ne yaptı, takip etmek baya zorlaşıyor. Shared credential olunca accountability neredeyse buharlaşıyor; sonra biri gelir “ben yapmadım” der, sız de loglarda iz sürmeye çalışırsınız.
- Yetki şişmesi (privilege creep): Her incident’ta bir tık daha fazla yetki veriliyor, sonra o yetki geri alınmıyor. Bir süre sonra tablo tuhaflaşıyor; başlangıçta sadece müdahale eden birkaç kişi varken, aradan zaman geçince herkes her şeye dokunabilir hâle geliyor.
Bak şimdi, Türkiye’deki kurumsal şirketlerde bu konu biraz daha can sıkıcı oluyor, çünkü KVKK ve BDDK gibi regülasyonlar erişim kayıtlarını soruyor. “Kim bu pod’a exec yaptı?” sorusuna “bilmiyoruz, ortak hesapla girilmiş” cevabını vermek… açık konuşayım, pek hoş karşılanmıyor. Şimdi, peki neden? Çünkü denetimde ilk bakılan yer tam da burası oluyor.
RBAC ile En Az Yetki: Ama Doğru Şekilde
Açıkçası, Kubernetes RBAC’ı herkes duydu, çoğu kişi de bir şekilde kullanıyor. Ama işin aslı, doğru kullanan az. Emin değilim ama sahada gördüğüm tablo bu.
Namespace Bazlı Debug Role’ü Tanımlamak
Küçük bir detay: İlk kural basit: debug için cluster-admin vermeyin. Nokta. Çünkü sonra bir bakmışsınız, sadece log bakacak kişiye tüm kümeyi emanet etmişsiniz; hani olur ya, “bir şey olmaz” denir, sonra gece üçte alarm çalar. Kimse neyi kimin bozduğunu anlayamaz.
Bunun yerine namespace bazlı bir Role açın, sadece debug sırasında lazım olan yetkileri koyun, gerisini dışarıda bırakın (özellikle de silme ve geniş kapsamlı yazma yetkilerini). Şöyle bir yapı gayet iş görür:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: payments
name: oncall-debug
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "pods/exec", "pods/portforward", "events", "configmaps"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["pods/exec", "pods/portforward"]
verbs: ["create"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list"]Dikkat edin, delete yok. patch yok. create de her yere saçılmıyor; sadece exec ve port-forward için var. Yanı pod loguna bakabiliyorsunuz, gerektiğinde içeri girip kontrol edebiliyorsunuz, ama deployment silmeye kalkamıyorsunuz. Basit gibi dürüyor. Evet. Ama garip biçimde çoğu yerde eksik olan tam da bu (bizzat test ettim)
Bir bakıma, peki neden? Çünkü insanlar genelde “iş görüyor mu?” diye bakıyor, “fazla mı yetki verdim?” sorusunu biraz geç soruyor. Sonra da geri dönüp düzeltmek zorunda kalıyorlar.
Gruplara Yetki Verin, Kişilere Değil
Bak şimdi, burada ikinci kritik nokta geliyor: RoleBinding’i tek tek kullanıcılara bağlamayın. Gruplara bağlayın. Neden? Çünkü nöbetçi ekip değişiyor, biri takım değiştiriyor, biri ayrılıyor, biri başka projeye kayıyor; bireysel binding takibi bir süre sonra tam anlamıyla baş ağrısı oluyor.
Açık konuşayım, bireysel kullanıcı bazında RBAC yönetimi ilk başta düzenli gibi görünür ama birkaç ay sonra elinizde dağınık bir liste kalır (kimde ne vardı, niye vardı, hâlâ gerekiyor mu). Mantıklı değil mi? Grup yaklaşımıysa daha sakın ilerliyor; güncellemesi kolay, iz bırakması daha net.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: payments
name: oncall-debug-binding
subjects:
- kind: Group
name: "oncall-payments-team"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: oncall-debug
apiGroup: rbac.authorization.k8s.ioKimlerin bu gruba dahil olacağını identity provider yönetsin; Entra ID olur, Okta olur, başka bir sistem olur fark etmez. Kubernetes tarafında sız sadece “bu gruba şu yetkiyi ver” diyorsunuz. Temiz dürüyor mu? Bence evet. Bir de audit tarafı var tabii; orada da baya iş görüyor.
Burada, neyse uzatmayalım. İşin özü şu: en az yetki prensibini kağıt üstünde bırakmayın (yanlış duymadınız). Namespace ile sınır koyun, role’u dar tutun, erişimi gruplar üzerinden yönetin (yanlış duymadınız). Sonra hem güvenlik ekibi rahat ediyor hem de operasyon sırasında kimse birbirine mail atıp durmuyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Kısa Ömürlü Credential’lar: Anahtar Curumeli
Bilmem anlatabiliyor muyum, 2019’da kendi test ortamımda bir şey denemiştim: kubeconfig dosyalarına statik token koyup ne kadar süre fark edilmeden kalabileceklerini test ettim. Sonuç? 7 ay. Yedi ay boyunca o token aktifti, kimse de gidip “bu ne yahu” demedi. Korkunç biraz, hatta baya can sıkıcı.
Tuhaf ama, Kısa ömürlü credential dediğimiz şey su: bir kullanıcı debug erişimi istediğinde kimlik doğrulama yapılıyor (MFA dahil), sonra ona mesela 30 dakikalık bir token veriliyor. Otuz dakika sonra bitti gitti. Yeniden istemesi gerekiyor. Kolay gibi dürüyor ama işin tadı da burada çıkıyor zaten.
Statik kubeconfig dosyaları production ortamında olmamalı. Her erişim kimlik doğrulama ile başlamalı ve zaman sınırlı olmalı. Buna “zero standing privilege” deniyor — kimsenin sürekli açık yetkisi yok.
Azure Kubernetes Service (AKS) kullanıyorsanız, Entra ID entegrasyonu ile bunu nispeten kolay yapabilirsiniz. az aks get-credentials komutu zaten Entra ID üzerinden token alıyor, bu token’in ömrünü Conditional Access policy’leriyle kontrol edebilirsiniz. Ama dur bir saniye — AKS dışında, vanilla Kubernetes’te aynı şeyi yapmak biraz daha uğraştırıyor; OIDC provider kurmanız, token rotation ayarlamanız gerekiyor (yanı işin içi biraz elle tutuluyor). Zor değil ama “out of the box” gelmiyor.
SSH-Tarzı Gateway Modeli: Kapıdan Giriş Kuralı
Şimdi işin en ilginç tarafına geldik. Klasik SSH dünyasında bastion ya da jump box vardı; önce oraya girerdiniz, sonra hedef sunuculara sıçrardınız. Kubernetes tarafında da benzer bir mantık var, ama biraz daha derli toplu, hatta açık konuşayım, daha az baş ağrıtan bir hali var.
İşte tam da bu noktada devreye giriyor.
Nasıl Çalışıyor?
Bak şimdi, olayın özü şu: cluster içinde bir gateway pod çalışıyor (ister sürekli ayakta dürüyor olsun, ister on-demand kalksın; ihtiyaç anında açılması da gayet mümkün). Debug yapmak isteyen kişi önce kendi kimliğiyle bağlanıyor, kısa ömürlü credential kullanıyor. Sonra gateway üzerinden içeri adım atıyor.
- Kendi kimliğiyle (kısa ömürlü credential ile) gateway’e bağlanıyor
- Gateway, Kubernetes API’ye gidip bu kişinin RBAC yetkilerini kontrol ediyor
- Yetki varsa, izin verilen scope dahilinde session açılıyor (pods/log, pods/exec vs.)
- Session otomatik expire oluyor, log’lar hem gateway hem Kubernetes audit log’una yazılıyor
Vallahi, Peki neden güzel? Çünkü ortada ortak bir bastion hesabı yok. Her session’ın sahibi belli kalıyor. Kim ne zaman hangi pod’a girdi, hangi komutu çalıştırdı; bunların hepsi kayıt altında dürüyor (kendi tecrübem). Şey gibi değil yanı, “birisi yapmış işte” diyebileceğiniz bulanık bir yapı olmuyor.
Türkiye’deki Kurumsal Gerçeklik
Ha burada küçük bir parantez açayım: bunu Türkiye’deki kurumsal şirketler açısından düşünmek lazım. Bankacılıkta BDDK denetimi geldiğinde size sık sık “bu kişi production veritabanına ne zaman ve nasıl erişti?” diye soruyorlar. Shared bastion hesabı varsa iş zorlaşıyor; çünkü cevap netleşmiyor (bu beni çok şaşırttı). Ama gateway modelinde her erişim identity-bound olduğu için tablo baya değişiyor.
Durun, bir saniye.
Yanı denetçiye şunu rahatça gösterebiliyorsunuz: şu kişi, şu saat, şu pod, şu komut. İşin aslı bu kadar basit. Denetçi mutlu oluyor, sız de arşiv karıştırmıyorsunuz. Tamamdır. Bu konuyla ilgili Node.js Addon’larını.NET Native AOT ile Yazmak yazımıza da göz atmanızı tavsiye ederim.
Bir bankacılık projesinde bu modeli Teleport ile kurmuştuk. İlk hafta ekip biraz mızmızlandı — “niye her seferinde kimlik doğrulama yapıyoruz?” dediler. Haklılardı aslında; ilk bakışta ekstra sürtünme gibi geliyor. Ama bir ay sonra security incident patlayınca kimin neye eriştiğini 5 dakikada çıkardık ve herkesin yüz ifadesi değişti. Evet, tam da öyle öldü.
Access Broker: RBAC’ın Üstüne Bir Katman Daha
Açıkçası, RBAC tek başına yeterli mi? Hmm, bir düşüneyim (ciddiyim) (eh, fena değil). Pek değil. RBAC sana sadece “bu kişi pods/exec yapabilir” diyor,. “içeride ne çalıştırabilir?” kısmını boş bırakıyor; yanı biri kubectl exec ile pod’a girip rm -rf / yazarsa, RBAC çoğu senaryoda bunu tek başına durdurmuyor (şaşırtıcı ama gerçek)
İşte access broker tam burada devreye giriyor. RBAC’ın üstüne oturan bir policy katmanı gibi düşün; dışarıdan bakınca küçük bir detay sanıyorsun, sonra bir bakmışsın işin asıl güvenlik kontrolü orada dönüyor: AI Maliyet Optimizasyonu: ROI’yi Gerçekten Artırmanın Yolu yazımızda bu konuya da değinmiştik.
| Ö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. Bu konuyla ilgili Codex Kurumsal Ölçekte: Ne Vaat Ediyor, Ne Eksik? yazımıza da göz atmanızı tavsiye ederim.
Evet. Daha fazla bilgi için SQL MCP Server: Veritabanını Ajanlara Açmanın Yolu yazımıza bakabilirsiniz.
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. Bu konuyla ilgili Cosmos DB Dynamic Data Masking: Veri Güvenliğinde Yeni Dönem yazımıza da göz atmanızı tavsiye ederim.
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ı…
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
İçeriği paylaş:
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments