Bu yazıda Kubernetes dünyasının en kritik güvenlik konularından biri olan Kubernetes RBAC (Role-Based Access Control — Rol Tabanlı Erişim Kontrolü) hakkında konuşacağız. Eğer bir Kubernetes Cluster yönetiyorsanız ya da kullanıyorsanız, bu yazı tam size göre. RBAC’ı birlikte öğreneceğiz, parçalarına ayıracağız ve sonunda “aa bu kadarmış!” diyeceksiniz.
Hazırsanız başlıyoruz!
Önce Sahneyi Kuralım: kubectl apply Dediğimizde Ne Oluyor?
Diyelim ki bir Pod (Pod) tanımı yazdınız ve bunu Kubernetes’e göndermek istiyorsunuz. kubectl apply -f pod.yaml komutunu çalıştırdığınızda arka planda birkaç önemli adım gerçekleşiyor. Tüm bu süreci aşağıdaki akış diyagramında görebilirsiniz:
Gelin bu diyagramdaki her adımı tek tek açalım.
İstemci Tarafı (Client-Side) — Adım 1-4
Diyagramın üst yarısı kubectl’in yani istemcinin sorumluluğundaki adımları gösteriyor:
Adım 1 — Kubeconfig oku: kubectl ilk iş olarak yerel Kubernetes yapılandırma dosyanızı (~/.kube/config) okur. Bu dosyada cluster adresi, kullanıcı kimlik bilgileri ve hangi bağlama (Context) bağlanacağı gibi bilgiler yer alır.
Adım 2 — API keşfi (API Discovery): kubectl, API sunucusuna bağlanarak mevcut API’lerin listesini ve nasıl kullanılacağını keşfeder. Böylece gönderdiğiniz kaynağın API sunucusu tarafından tanınıp tanınmadığını anlar.
Adım 3 — İstemci doğrulama (Client-Side Validation): YAML dosyanızdaki bariz hataları ve yazım yanlışlarını kontrol eden bir doğrulama işlemi yapılır. Örneğin, geçersiz bir alan adı veya yanlış bir API sürümü varsa daha istek gönderilmeden hata alırsınız.
Adım 4 — JSON’a çevir ve gönder: Son olarak kubectl, Pod tanımınızı bir JSON nesnesine (Object) dönüştürüp kube-apiserver’a bir HTTP isteği (Request) olarak gönderir.
Sunucu Tarafı (Server-Side) — Adım 5-7
Diyagramın alt yarısı ise kube-apiserver’ın kritik güvenlik kontrollerini gösteriyor. İsteği aldığında hemen veritabanına (etcd) kaydetmiyor! Önce iki kritik kapıdan geçmesi gerekiyor:
Adım 5 — Kimlik Doğrulama (Authentication): İsteğin meşru olup olmadığını doğruluyor. Yani “Sen kimsin?” sorusuna cevap arıyor. Diyagramda gördüğünüz gibi, bu adımda başarısızlık yaşanırsa süreç kırmızı kutuya düşüyor ve 401 Unauthorized (Yetkisiz) hatası dönüyor.
Adım 6 — Yetkilendirme (Authorization — RBAC): Kimliği doğrulanmış kullanıcının istediği kaynağa erişim hakkı olup olmadığını kontrol ediyor. Yani “Tamam sensin ama bunu yapmaya yetkin var mı?” sorusunu soruyor. Bu adımda başarısızlık olursa 403 Forbidden (Yasaklı) hatası ile karşılaşırız [1].
Adım 7 — etcd’ye kaydet: Eğer her iki kontrol de başarılı olursa, kaynak sonunda etcd veritabanına yazılır ve Pod’unuz oluşturulma sürecine girer.
Diyagramdaki mor renkli karar kutularına dikkat edin: işte biz bu yazıda o kutulardan ikincisine, yani yetkilendirme (Authorization) kısmına odaklanacağız. Ve Kubernetes’te yetkilendirme dendiğinde akla gelen ilk mekanizma RBAC!
RBAC Nedir ve Neden Bu Kadar Önemli?
Kubernetes RBAC (Role-Based Access Control — Rol Tabanlı Erişim Kontrolü), bilgisayar veya ağ kaynaklarına erişimi, kullanıcıların organizasyondaki rollerine göre düzenleyen bir yöntemdir [2]. Kubernetes bağlamında ise RBAC, cluster içindeki kaynaklara kimin hangi işlemleri yapabileceğini belirleyen güvenlik katmanıdır.
Bunu biraz daha somutlaştıralım. Düşünün ki bir şirkettesiniz ve Kubernetes cluster’da geliştirme (Development), hazırlık (Staging) ve canlı (Production) ortamları var. Geliştirici ekibin canlı ortamdaki gizli anahtarları (Secrets) görmemesi gerekiyor. QA ekibinin sadece hazırlık ortamındaki Pod’ları listeleyebilmesi yeterli. Yöneticilerin ise her şeye tam erişimi olmalı. RBAC tam da bu tür senaryolarda hayat kurtarıyor [3].
RBAC’ın önemini daha iyi anlamak için gerçek dünyada yaşanan bir olaya bakalım. 2023 yılında keşfedilen “RBAC Buster” adlı saldırı kampanyasında, saldırganlar yanlış yapılandırılmış Kubernetes API sunucularını hedef almıştır. Kimlik doğrulaması gerektirmeyen anonim istekleri kabul eden bu sunucularda saldırganlar, RBAC mekanizmasını kötüye kullanarak arka kapılar (Backdoor) oluşturmuş ve kripto para madenciliği için cluster kaynaklarını ele geçirmiştir [4][5]. En az 60 cluster’ın bu saldırıdan etkilendiği tespit edilmiştir [6]. Bu olay, RBAC yapılandırmasının ne kadar kritik olduğunu çarpıcı biçimde göstermektedir.
Yetkilendirmeyi Sıfırdan Tasarlayalım
RBAC’ı daha iyi kavramak için bir adım geri gidelim ve sıfırdan bir yetkilendirme sistemi tasarlamaya çalışalım. Diyelim ki bir kullanıcının belirli bir kaynağa yazma erişimi olup olmadığını kontrol etmek istiyoruz. En basit çözüm üç sütunlu bir tablo oluşturmak olabilir: Kullanıcı (User), İzin (Permission) ve Kaynak (Resource).
Örneğin:
- Ahmet → okuma ve yazma → uygulama1
- Mehmet → sadece okuma → uygulama2
- Ayşe → sadece okuma → uygulama2
Bu yaklaşım az sayıda kullanıcı ve kaynak için iş görür. Ama ya Mehmet ve Ayşe aynı takımdaysa ve aynı izinlere sahipse? Her birine ayrı ayrı satır eklemek zorunda kalırız. Kullanıcı sayısı arttıkça bu tablo yönetilemez hale gelir.
İşte burada rol (Role) kavramı devreye giriyor. İzinleri doğrudan kullanıcılara atamak yerine, izinleri bir role atayacağız. Sonra da kullanıcıları bu role bağlayacağız. Böylece iki ayrı tablomuz olacak: birinde izinler rollere, diğerinde roller kullanıcılara eşlenecek. Yeni bir kullanıcı aynı izinlere ihtiyaç duyduğunda, mevcut rolü kullanıp yeni bir bağlama (Binding) oluşturmak yeterli olacak.
Bu yaklaşım büyük organizasyonlarda güvenlik yönetimini ciddi şekilde kolaylaştırıyor. İzinler kullanıcıya değil role atandığı için tekrarlanan tanımlamalardan kurtuluyoruz.
Kubernetes RBAC’ın Yapı Taşları
Kubernetes, yukarıda anlattığımız RBAC modelini cluster içinde kaynaklara erişimi korumak için kullanıyor [7]. Aynı üç temel kavrama dayanıyor ama isimleri biraz farklı. Gelin bu yapı taşlarını tek tek inceleyelim.
1. Kimlikler (Identities): Kullanıcılar, Uygulamalar ve Gruplar
Kubernetes’te üç tür kimlik var:
Kullanıcılar (Users): İnsan kullanıcılar, yani ekibinizdeki kişiler için kullanılır. İlginç olan şu: Kubernetes’te normal kullanıcı hesaplarını temsil eden yerleşik bir nesne (Object) bulunmuyor. Kullanıcılar bir API çağrısıyla doğrudan eklenemez. Bunun yerine, cluster’ın sertifika otoritesi (Certificate Authority — CA) tarafından imzalanmış geçerli bir sertifika sunan herhangi bir aktör kimliği doğrulanmış sayılır. Kubernetes, kullanıcı adını sertifikanın “konu” (Subject) alanındaki ortak ad (Common Name — CN) kısmından alır.
Hizmet Hesapları (Service Accounts): Kubernetes içinde çalışan uygulamalar için kullanılır. Normal kullanıcılardan farklı olarak, Kubernetes tarafından doğrudan yönetilir ve bir YAML dosyasıyla oluşturulabilir [8]. Örneğin, cluster içinde çalışan bir Prometheus’un hedeflerini keşfetmesi veya bir Nginx Ingress Controller’ın arka uç servislerini listelemesi gerektiğinde hizmet hesapları kullanılır.
Gruplar (Groups): Birden fazla kullanıcı veya hizmet hesabını bir araya toplamak için kullanılır. Örneğin, belirli bir Namespace tüm hizmet hesaplarına tek seferde referans vermek istediğimizde gruplar işe yarıyor.
2. Roller (Roles) ve Cluster Rolleri (ClusterRoles)
Roller, Kubernetes kaynaklarına hangi işlemlerin yapılabileceğini tanımlar. Her rol bir dizi kural (Rule) içerir. Her kural şu üç unsuru barındırır:
- apiGroups (API Grupları): Kaynağın hangi API grubuna ait olduğunu belirtir. Boş string (“”) çekirdek API grubunu (Core API Group) ifade eder. Pod’lar, Servisler (Services) gibi yerleşik kaynaklar bu gruba aittir.
- resources (Kaynaklar): Hangi kaynaklara erişim verileceğini belirler. Örneğin: pods, services, secrets, configmaps gibi.
- verbs (Fiiller): Hangi işlemlere izin verileceğini tanımlar. Örneğin: get, list, watch, create, update, patch, delete gibi.
Rol (Role) her zaman belirli bir Namespace içinde izinler tanımlar [9]. Yani bir Role oluşturduğunuzda, hangi namespace’e ait olduğunu belirtmeniz gerekir.
Cluster Rolü (ClusterRole) ise namespace’den bağımsızdır. Tüm cluster genelinde geçerli olabilir [10]. ClusterRole’ler şu durumlarda kullanılır:
- Nodes veya ersistentVolumes gibi cluster kapsamlı kaynaklara erişim vermek istediğimizde
- Tüm namespace’lerdeki kaynaklara erişim tanımlamak istediğimizde
- Ortak izin setleri oluşturup birden fazla namespace’de yeniden kullanmak istediğimizde
İşte örnek bir Role tanımı:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: staging name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
Bu rol, “staging” namespace’deki Pod’ları okuma (get, watch, list) izni verir. Yazma, silme gibi işlemlere izin vermez.
3. Rol Bağlamaları (RoleBindings) ve Cluster Rol Bağlamaları (ClusterRoleBindings)
Roller tek başına hiçbir şey yapmaz. Bir rolün işlevsel hale gelmesi için bir kimliğe bağlanması gerekir. İşte bu bağlama işlemi RoleBinding veya ClusterRoleBinding ile yapılır.
RoleBinding, bir Role veya ClusterRole’ü belirli bir namespace içinde bir kullanıcıya, gruba veya hizmet hesabına bağlar [11].
ClusterRoleBinding ise bir ClusterRole’ü tüm cluster genelinde bir kimliğe bağlar.
İşte örnek bir RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods-binding namespace: staging subjects: - kind: ServiceAccount name: qa-team namespace: staging roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Bu tanım, “staging” namespace’indeki “qa-team” hizmet hesabını “pod-reader” rolüne bağlar. Böylece QA ekibi staging ortamındaki Pod’ları okuyabilir ama başka bir şey yapamaz.
API Uç Noktalarını (Endpoints) Anlamak
RBAC’ın arka planında API uç noktaları yatıyor. Kubernetes’teki her kaynak aslında bir HTTP uç noktası üzerinden erişilir. Genel yapı şöyledir:
- Yerleşik kaynaklar:
/api/v1/namespaces/{namespace}/{resource} - Özel kaynaklar (Custom Resources):
/apis/{apiGroup}/v1/namespaces/{namespace}/{resource}
Role tanımlarındaki apiGroups alanı bu URL yapısını belirler. Boş string, çekirdek API’yi (/api/v1/) işaret eder. Prometheus Operator gibi araçların oluşturduğu özel kaynaklar (Custom Resources) ise kendi API gruplarına sahiptir.
Pratik Senaryolar: RBAC’ı Hayata Geçiriyoruz
Şimdi teoriden pratiğe geçelim ve farklı senaryolarda RBAC’ın nasıl çalıştığını görelim.
Senaryo 1: Aynı Namespace içinde Role ve RoleBinding
En temel senaryo budur. Bir hizmet hesabı, bir rol ve bu ikisini birbirine bağlayan bir RoleBinding, hepsi aynı namespace’de bulunur.
Örneğin, “dev” namespace içinde bir “myapp” hizmet hesabı oluşturup, yine “dev” namespace içinde bir Role ve RoleBinding tanımlayabiliriz. Test etmek için kubectl’in kimliğe bürünme (Impersonation) özelliğini kullanabiliriz:
kubectl auth can-i get pods -n dev \ --as=system:serviceaccount:dev:myapp
Bu komut “myapp hizmet hesabı dev namespace’de Pod’ları listeleyebilir mi?” sorusuna yanıt verir.
Senaryo 2: Farklı Namespace’lerde RoleBinding
İşte işler burada ilginçleşiyor. Bir RoleBinding, farklı bir namespace’deki hizmet hesabını referans alabilir. Yani “dev” namespace’deki bir hizmet hesabına, “staging” namespace’de bir RoleBinding ile izin verebilirsiniz.
Dikkat edilmesi gereken nokta şu: RoleBinding’in roleRef alanında Namespace belirtilmez. Bu, bir RoleBinding’in yalnızca kendi bulunduğu namespace’deki bir Role’e referans verebileceği anlamına gelir. Ama subjects kısmında farklı bir namespace’deki hizmet hesabını işaret edebilirsiniz.
Senaryo 3: ClusterRole ile RoleBinding Kullanmak
Bir ClusterRole, namespace’e bağlı olmayan izinler tanımlar. Ancak bu ClusterRole bir RoleBinding ile bağlandığında, izinler yalnızca o RoleBinding’in bulunduğu namespace için geçerli olur [12]. Yani ClusterRole sanki normal bir Role gibi davranır.
Bu son derece kullanışlı bir özellik. Ortak izin setlerini tek bir ClusterRole’de tanımlayıp, farklı ad alanlarındaki RoleBinding’lerle tekrar tekrar kullanabilirsiniz. Böylece her namespace’de ayrı ayrı Role tanımlama zahmetinden kurtulursunuz.
Senaryo 4: ClusterRole ve ClusterRoleBinding ile Cluster Genelinde Erişim
ClusterRole’ü bir ClusterRoleBinding ile bağladığınızda, izinler tüm cluster genelinde geçerli olur. Herhangi bir namesace kısıtlaması yoktur. Bu en geniş kapsamlı yetkilendirme şeklidir ve dikkatli kullanılmalıdır.
Bu dört senaryodan çıkaracağımız kuralları özetleyelim:
- Role ve RoleBinding aynı namespace’de bulunmalıdır.
- RoleBinding, farklı namespace’deki hizmet hesaplarına referans verebilir.
- RoleBinding bir ClusterRole’e bağlandığında, yalnızca kendi namespace’i için erişim sağlar.
- ClusterRoleBinding, cluster genelinde erişim verir.
- ClusterRoleBinding bir Role’e referans veremez (çünkü Role’ler namespace’e bağlıdır, ClusterRoleBinding ise değildir).
Kubernetes’in Varsayılan Rolleri
Kubernetes, cluster kurulduğunda otomatik olarak bazı roller ve cluster rolleri oluşturur [13]. Bunların arasında en bilinenleri şunlardır:
- cluster-admin: Tüm kaynaklar üzerinde tam yetki sağlar. Çok dikkatli kullanılmalıdır.
- admin: Bir namespace içinde tam yetki verir.
- edit: Bir namespace’deki kaynakları değiştirebilir ama rollere ve bağlamalara erişemez.
- view: Bir namespace’deki kaynakları salt okunur (Read-Only) modda görebilir.
Bu rolleri listelemek için şu komutu kullanabilirsiniz:
kubectl get clusterroles
Detaylarını incelemek için ise:
kubectl describe clusterrole view
RBAC En İyi Uygulamaları (Best Practices)
RBAC yapılandırmasını doğru yapmak, cluster güvenliği için hayati önem taşıyor. İşte uzmanların önerdiği en iyi uygulamalar:
En Az Yetki İlkesi (Principle of Least Privilege)
Her kullanıcıya ve hizmet hesabına yalnızca görevlerini yerine getirmek için gereken minimum izinleri verin [14][15]. Geniş yetkilere sahip roller oluşturmak yerine, her uygulama veya ekip için özel ve dar kapsamlı roller tanımlayın. Bu ilke, bir güvenlik ihlali durumunda zararın yayılma alanını (Blast Radius) minimize eder [16].
Joker Karakter (Wildcard) Kullanmaktan Kaçının
Role tanımlarında "*" joker karakteri kullanmak, tüm kaynaklara veya tüm işlemlere izin vermek anlamına gelir. Bir güvenlik uzmanının ifadesiyle, joker karakterler Kubernetes dünyasında Linux’taki chmod 777 gibidir: kullanımı kolaydır ama ciddi güvenlik açıkları yaratır [17].
Mümkünse Role Kullanın, ClusterRole Değil
İzinleri namespace düzeyinde tanımlamak her zaman daha güvenlidir. ClusterRole ve ClusterRoleBinding yalnızca gerçekten cluster genelinde erişim gerektiğinde kullanılmalıdır [18]. Her ClusterRoleBinding, namespace izolasyonunu (Namespace Isolation) tasarım gereği atladığı için dikkatle gözden geçirilmelidir [19].
system:masters Grubuna Kullanıcı Eklemeyin
Bu grubun üyesi olan herhangi bir kullanıcı, tüm RBAC kontrollerini atlar ve sınırsız süper kullanıcı erişimine sahip olur. Bu erişim, RoleBinding veya ClusterRoleBinding kaldırılarak bile geri alınamaz [20].
Hizmet Hesabı Tokenlerini Otomatik Bağlamayı Kapatın
Kubernetes, Pod’lara otomatik olarak varsayılan hizmet hesabı tokenini bağlar. Bu token, kısıtlanmazsa istenmeyen API erişimine kapı açabilir. Saldırganlar, ele geçirilen konteynerlerde bu tokenleri aramaktadır [21]. API erişimi gerekmeyen Pod’larda automountServiceAccountToken: false ayarını kullanmalısınız [22].
Düzenli Denetim (Audit) Yapın
RBAC politikalarını düzenli aralıklarla gözden geçirin. Artık kullanılmayan roller, gereksiz bağlamalar ve aşırı yetkilendirmeler güvenlik riski oluşturur [23]. Silinen bir kullanıcıyla aynı adda yeni bir hesap oluşturulması durumunda, eski kullanıcının tüm hakları otomatik olarak devralınabilir [24]. Bu nedenle eski bağlamaları temizlemek kritik önem taşır.
RBAC Politikalarını Kod Olarak Yönetin (Infrastructure as Code)
RBAC tanımlarını YAML bildirimleri (Manifests) olarak sürüm kontrolü (Version Control) altında tutun. Değişikliklerin uygulama dağıtımlarıyla aynı titiz süreçten geçmesi, tutarlılık ve hesap verebilirlik sağlar [25].
Yetki Yükseltme Risklerine (Privilege Escalation Risks) Dikkat Edin
Bazı RBAC izinleri, kullanıcıların yetkilerini yükseltmesine olanak tanıyabilir. Bunlar arasında escalate, bind ve impersonate fiilleri özellikle tehlikelidir [26]. escalate fiili, kullanıcıların sahip olduklarından daha fazla hakka sahip roller oluşturmasına izin verir. bind fiili, kullanıcıların henüz sahip olmadıkları haklara sahip rollere bağlanmasını mümkün kılar. impersonate ise diğer kullanıcıların kimliğine bürünme imkânı verir [27].
RBAC’ı Test Etmek: kubectl auth can-i
RBAC yapılandırmanızı test etmek için kubectl’in auth can-i komutunu kullanabilirsiniz. Bu komut, belirli bir kullanıcının veya hizmet hesabının belirli bir kaynağa erişip erişemeyeceğini kontrol eder:
# Mevcut kullanıcı olarak kontrol kubectl auth can-i create deployments -n production # Bir hizmet hesabı olarak kontrol (kimliğe bürünme) kubectl auth can-i get pods -n staging \ --as=system:serviceaccount:dev:myapp # Tüm izinleri listele kubectl auth can-i --list -n dev
Kimliğe bürünme (Impersonation) için --as bayrağı (Flag) kullanılır. Hizmet hesapları için kullanılan desen şöyledir: system:serviceaccount:{namespace}:{service-account-name}.
Daha Kısa ve Okunabilir RBAC Tanımları
RBAC kurallarını yazarken, birden fazla kaynağı ve fiili aynı kuralda birleştirebilirsiniz. Örneğin şu iki kural:
rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] - apiGroups: [""] resources: ["services"] verbs: ["get", "list"]
Şu şekilde daha kısa yazılabilir:
rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list"]
Bu yaklaşım satır sayısını azaltır ve tanımları çok daha okunabilir hale getirir.
Gelişmiş Araçlar ve Entegrasyonlar
RBAC tek başına güçlü bir mekanizma olsa da, büyük ve karmaşık ortamlarda ek araçlarla desteklenebilir:
Open Policy Agent — OPA (Açık Politika Ajanı): Kubernetes RBAC’ın ötesinde dinamik politika uygulaması sağlar. Rego dilinde yazılan özel politikalarla kaynak erişimi hakkında kararlar alır [28]. Örneğin, tüm uygulamaların özel hizmet hesapları tanımlamasını zorunlu kılabilirsiniz.
rbac-manager: Cluster genelinde tutarlı güvenlik politikaları sürdürmeye yardımcı olur. Rol oluşturma, bağlama yönetimi ve politika uygulamayı otomatikleştirebilir [29].
Kubescape RBAC Görselleştirici (Visualizer): RBAC yapınızı görsel olarak incelemenizi sağlar. Hangi ayrıcalıkların hangi kullanıcılara atandığını görmek, potansiyel riskleri tespit etmek için kullanışlıdır [30].
Gerçek Dünya Senaryosu: QA Ekibine Staging Erişimi Vermek
Gelin şimdi baştan sona bir RBAC senaryosu kuralım. Diyelim ki cluster’daki “staging” ve “production” ad alanları var. QA ekibinin yalnızca staging ortamında Pod’ları ve Servisleri listeleyebilmesini ve Pod günlüklerini (Logs) okuyabilmesini istiyorsunuz. Üretim ortamına ise kesinlikle erişememeli.
İlk adım olarak QA ekibi için bir hizmet hesabı oluşturuyoruz:
apiVersion: v1 kind: ServiceAccount metadata: name: qa-team namespace: staging
Ardından izinleri tanımlayan bir Role oluşturuyoruz:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: staging name: qa-role rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get"]
Son olarak hizmet hesabını role bağlıyoruz:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: qa-role-binding namespace: staging subjects: - kind: ServiceAccount name: qa-team namespace: staging roleRef: kind: Role name: qa-role apiGroup: rbac.authorization.k8s.io
Bu tanımları uyguladıktan sonra test edelim:
# Staging'de Pod'ları listeleyebiliyor mu? kubectl auth can-i get pods -n staging \ --as=system:serviceaccount:staging:qa-team # Sonuç: yes # Production'da Pod'ları listeleyebiliyor mu? kubectl auth can-i get pods -n production \ --as=system:serviceaccount:staging:qa-team # Sonuç: no # Staging'de Pod günlüklerine erişebiliyor mu? kubectl auth can-i get pods/log -n staging \ --as=system:serviceaccount:staging:qa-team # Sonuç: yes
Görüldüğü gibi QA ekibi yalnızca staging ortamında ve yalnızca tanımlı kaynaklara erişebiliyor. Üretim ortamına erişim tamamen engellenmiş durumda. İşte RBAC’ın gücü burada ortaya çıkıyor!
Namespace ve Cluster Kapsamlı Kaynakların Farkı
Kubernetes’teki kaynakların bir kısmı namespace’e bağlıdır (Namespaced), bir kısmı ise cluster kapsamlıdır (Cluster-Scoped). Bu ayrım RBAC yapılandırmasını doğrudan etkiler.
Namespace bağlı kaynaklar: Pods, Services, Deployments, ConfigMaps, Secrets gibi kaynaklar belirli bir namespace içinde yaşar. HTTP yollarında namespace bilgisi bulunur: /api/v1/namespaces/staging/pods.
Cluster kapsamlı kaynaklar: Nodes, PersistentVolumes, Namespaces, ClusterRoles gibi kaynaklar herhangi bir namespace’e ait değildir. HTTP yollarında namespace bilgisi bulunmaz: /api/v1/nodes.
Cluster kapsamlı kaynaklara erişim vermek istediğinizde Role değil, ClusterRole kullanmanız gerekir. Bir Role içinde Nodes veya PersistentVolumes tanımlasanız bile bu tanım çalışmaz çünkü Role’ler yalnızca namespace kapsamındaki kaynaklara erişim verebilir.
RBAC Hata Ayıklama (Debugging) İpuçları
RBAC yapılandırmasında sorunlarla karşılaştığınızda şu adımları izleyebilirsiniz:
1. İzin kontrolü yapın: kubectl auth can-i komutu en temel hata ayıklama aracıdır. Belirli bir kullanıcının veya hizmet hesabının ne yapıp ne yapamayacağını anında gösterir.
2. Mevcut rolleri ve bağlamaları listeleyin:
kubectl get roles -n staging kubectl get rolebindings -n staging kubectl get clusterroles kubectl get clusterrolebindings
3. Rollerin detaylarını inceleyin:
kubectl describe role qa-role -n staging kubectl describe rolebinding qa-role-binding -n staging
4. API sunucu günlüklerini kontrol edin: Yetkilendirme hatalarının detayları genellikle kube-apiserver günlüklerinde bulunur. 403 Forbidden hatası alıyorsanız, günlükler hangi iznin eksik olduğunu gösterebilir.
5. Sık yapılan hatalar:
apiGroupsalanını boş bırakmayı unutmak (çekirdek API kaynakları için[""]olmalı)roleRefiçinde yanlışkindbelirtmek (Role yerine ClusterRole yazmak veya tam tersi)- RoleBinding’i yanlış namespace’e yerleştirmek
- Hizmet hesabı adını veya namespace’i yanlış yazmak
RBAC ve Bulut Sağlayıcı IAM Arasındaki Fark
Kubernetes RBAC ile bulut sağlayıcıların IAM (Identity and Access Management — Kimlik ve Erişim Yönetimi) sistemleri birbirine karıştırılabilir. Aralarındaki temel fark şudur:
IAM, bulut altyapısı düzeyinde çalışır. Sanal makineler, veritabanları, depolama alanları gibi çeşitli bulut kaynaklarına erişimi yönetir. Kubernetes RBAC ise yalnızca Kubernetes cluster içindeki kaynaklara erişimi kontrol eder.
Yani bir kullanıcının GKE cluster’a bağlanabilmesi için Google Cloud IAM’da uygun izinlere sahip olması gerekir. Ancak cluster’a bağlandıktan sonra hangi Pod’ları görebileceğini, hangi Servisleri oluşturabileceğini belirleyen RBAC’tır. Bu iki katman birbirini tamamlar ve her ikisinin de doğru yapılandırılması gerekir.
Sonuç: RBAC Olmadan Kubernetes Güvenliği Eksik Kalır
Bu yazıda Kubernetes RBAC’ın ne olduğunu, nasıl çalıştığını ve neden bu kadar önemli olduğunu birlikte inceledik. Özetlemek gerekirse:
- Kimlikler (Identities): Users, Service Accounts ve Groups ile kimlerin erişim sağlayacağını belirliyoruz.
- Roller (Roles / ClusterRoles): Kaynaklara hangi işlemlerin yapılabileceğini tanımlıyoruz.
- Bağlamalar (RoleBindings / ClusterRoleBindings): Kimlikleri rollerle eşleştirerek yetkilendirmeyi aktif hale getiriyoruz.
RBAC, Kubernetes güvenliğinin temel taşıdır. Doğru yapılandırıldığında, cluster’ı yetkisiz erişimlerden, aşırı yetkilendirmelerden ve “RBAC Buster” benzeri saldırılardan korur. Yanlış yapılandırıldığında ise bir güvenlik ihlalinin etkisini kat kat artırabilir.
Unutmayın: güvenlik bir kez ayarlayıp bırakacağınız bir şey değil, sürekli gözden geçirip güncellemeniz gereken dinamik bir süreçtir. En az yetki ilkesini benimseyin, düzenli denetimler yapın ve RBAC tanımlarınızı kod olarak yönetin.
Umarım bu yazı, Kubernetes RBAC konusunu anlamanızı kolaylaştırmıştır. Sorularınız varsa yorumlarda buluşalım!
Kaynaklar
[1] Kubernetes Documentation, “Using RBAC Authorization,” https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[2] Kubernetes Documentation, “Using RBAC Authorization — API Overview,” https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[3] Trilio, “Implementing Kubernetes RBAC: Best Practices and Examples,” https://trilio.io/kubernetes-best-practices/kubernetes-rbac/
[4] Aqua Security, “First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters,” https://www.aquasec.com/blog/leveraging-kubernetes-rbac-to-backdoor-clusters/
[5] BleepingComputer, “Kubernetes RBAC abused to create persistent cluster backdoors,” https://www.bleepingcomputer.com/news/security/kubernetes-rbac-abused-to-create-persistent-cluster-backdoors/
[6] The Hacker News, “Kubernetes RBAC Exploited in Large-Scale Campaign for Cryptocurrency Mining,” https://thehackernews.com/2023/04/kubernetes-rbac-exploited-in-large.html
[7] Portainer, “Kubernetes RBAC: Roles, Permissions & Best Practices,” https://www.portainer.io/blog/kubernetes-rbac
[8] Kubernetes Documentation, “Service Accounts,” https://kubernetes.io/docs/concepts/security/service-accounts/
[9] Kubernetes Documentation, “Using RBAC Authorization — Role and ClusterRole,” https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[10] Spacelift, “Guide to Kubernetes RBAC — Example & Best Practices,” https://spacelift.io/blog/kubernetes-rbac
[11] Kubernetes Documentation, “Using RBAC Authorization — RoleBinding and ClusterRoleBinding,” https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[12] Portainer, “Kubernetes RBAC: RoleBindings and ClusterRoleBindings,” https://www.portainer.io/blog/kubernetes-rbac
[13] Google Cloud Documentation, “Best practices for GKE RBAC,” https://docs.cloud.google.com/kubernetes-engine/docs/best-practices/rbac
[14] Kubernetes Documentation, “Role Based Access Control Good Practices,” https://kubernetes.io/docs/concepts/security/rbac-good-practices/
[15] Apptio, “Chapter 3: RBAC — Kubernetes Guides,” https://www.apptio.com/topics/kubernetes/best-practices/rbac/
[16] ARMO, “Kubernetes RBAC: the Complete Best Practices Guide,” https://www.armosec.io/blog/a-guide-for-using-kubernetes-rbac/
[17] Sysdig, “Kubernetes RBAC Explained: Key Concepts and Best Practices,” https://www.sysdig.com/learn-cloud-native/kubernetes-rbac-explained
[18] Kubernetes Documentation, “Role Based Access Control Good Practices — Namespace-level,” https://kubernetes.io/docs/concepts/security/rbac-good-practices/
[19] Portainer, “Kubernetes RBAC: ClusterRoleBindings Review,” https://www.portainer.io/blog/kubernetes-rbac
[20] Kubernetes Documentation, “Role Based Access Control Good Practices — system:masters,” https://kubernetes.io/docs/concepts/security/rbac-good-practices/
[21] Aikido, “Kubernetes Security Vulnerabilities — Top Risks,” https://www.aikido.dev/blog/kubernetes-security-vulnerabilities
[22] Kubernetes Documentation, “Role Based Access Control Good Practices — Service Account Tokens,” https://kubernetes.io/docs/concepts/security/rbac-good-practices/
[23] Wiz, “Kubernetes RBAC Best Practices — From Basic to Advanced,” https://www.wiz.io/academy/container-security/kubernetes-rbac-best-practices
[24] Google Cloud Documentation, “Best practices for GKE RBAC — Review Access,” https://docs.cloud.google.com/kubernetes-engine/docs/best-practices/rbac
[25] Trilio, “Kubernetes RBAC — Version Control Best Practices,” https://trilio.io/kubernetes-best-practices/kubernetes-rbac/
[26] Kubernetes Documentation, “Role Based Access Control Good Practices — Privilege Escalation,” https://kubernetes.io/docs/concepts/security/rbac-good-practices/
[27] Palo Alto Networks, “Managing Permissions with Kubernetes RBAC,” https://www.paloaltonetworks.com/cyberpedia/kubernetes-rbac
[28] Apptio, “Chapter 3: RBAC — OPA Gatekeeper,” https://www.apptio.com/topics/kubernetes/best-practices/rbac/
[29] Trilio, “Kubernetes RBAC — Automation Tools,” https://trilio.io/kubernetes-best-practices/kubernetes-rbac/
[30] RAD Security, “Kubernetes RBAC: Role-Based Access Control — Kubescape,” https://blog.rad.security/blog/what-is-kubernetes-rbac
[31] Kapak Görseli: Photo by Citadel Life Safety on Unsplash
