1. GİRİŞ

Kubernetes RBAC (Role‑Based Access Control) bulut‑native platformlarda güvenliğin temel taşlarından biridir. Kubernetes cluster'ları birçok ekip, hizmet hesabı (service account) ve otomasyon aracı tarafından paylaşıldığı için erişim kontrolünü kontrollü, tekrar edilebilir ve denetlenebilir şekilde yönetmek zorunludur. RBAC, kimin hangi kaynaklara hangi izinlerle erişebileceğini belirleyen mekanizmadır ve doğru uygulanmadığında lateral movement, veri sızıntısı veya kontrol düzlemi manipülasyonu gibi ciddi güvenlik riskleri ortaya çıkabilir.

Bu konu neden konuşuluyor?

• Kubernetes benimsenmesi arttıkça, multi‑team ve multi‑tenant senaryolarında erişim yönetimi kritik hale geldi.
• Regülasyonlar ve denetimler (audit) şirketleri RBAC politikalarını güçlü, belgelenmiş ve test edilebilir kılmaya zorluyor.
• CI/CD entegrasyonlarının artmasıyla otomasyon süreçlerinin yetki sınırlarının net tanımlanması gerekiyor.

Kimler için önemli?

• Platform mühendisleri, SRE ve güvenlik ekipleri
• Kubernetes cluster yöneticileri ve DevOps mühendisleri
• Geliştiriciler — service account ve erişim ihtiyaçlarını planlayanlar

Hangi problemleri çözüyor?

• İnce taneli yetkilendirme ve least‑privilege uygulama
• Erişimlerin merkezi, sürümlenebilir ve denetlenebilir halde tutulması
• Audit gereksinimlerinin karşılanması ve uyumluluk süreçlerinin desteklenmesi

2. KAVRAMSAL TEMELLER

2.1 RBAC nedir — kısa tanım

RBAC, kullanıcılara (user), gruplara (group) ve service account'lara rol (Role/ClusterRole) atayarak hangi kaynaklara hangi eylemleri (verbs: get, list, watch, create, update, delete vb.) yapabileceklerini belirleyen yetkilendirme modelidir. Kubernetes'te iki tür rol vardır: namespace scoped (Role) ve cluster scoped (ClusterRole). Bu roller RoleBinding veya ClusterRoleBinding aracılığıyla subject'lara bağlanır.

2.2 Temel bileşenler

• Role / ClusterRole: İzinlerin (rules) tanımlandığı obje. Role namespace sınırlıdır; ClusterRole cluster genelidir.
• RoleBinding / ClusterRoleBinding: Role veya ClusterRole'ü subject (user, group, serviceAccount) ile ilişkilendirir.
• Subject: Erişim sağlanan kimlik; user, group veya serviceAccount olabilir.
• Verb: Resource üzerinde yapılabilecek işlem (get, list, watch, create, delete, patch vb.).
• Resource: API objesi (pods, deployments, secrets, configmaps vb.) veya cluster‑scoped kaynaklar (nodes, persistentvolumes).

2.3 RBAC ile ilgili terminoloji

• Least privilege: Her subject'a yalnızca ihtiyaç duyduğu en düşük izinler verilmesi ilkesi.
• Separation of duties: Yönetim ve uygulama rollerinin ayrılması, potansiyel suiistimal riskini azaltır.
• Policy as code: RBAC tanımlarının YAML ile versiyonlanarak Git üzerinden yönetilmesi.
• Audit log: API Server tarafında hangi subject'ın hangi eylemi ne zaman yaptığı bilgisi.

3. NASIL ÇALIŞIR? — Teknik Mimari

3.1 Erişim akışı

Bir kullanıcı veya servis Kubernetes API Server'a bir istek gönderdiğinde authentication (kimlik doğrulama) sürecinden geçer — bu OIDC, client certificate veya static token olabilir. Kimlik doğrulandıktan sonra API Server authorization (izin kontrolü) mekanizmalarına başvurur: RBAC, ABAC (eski), veya webhook tabanlı authorizer'lar. RBAC burada ilgili Role/ClusterRole kaynaklarını değerlendirir ve izin varsa isteğe izin verir; değilse reddeder. Bu akış, audit log'lara yazılarak izlenir.

3.2 Authentication ve identity yönetimi

Kubernetes'teki authentication, kimliklerin doğrulanmasını sağlar; RBAC ise bu kimliklere yetki atar. Modern üretim ortamlarında OIDC tabanlı identity provider (IdP) entegrasyonu (Azure AD, Google Identity, Keycloak vb.) kullanılır. Bu yaklaşım merkezi kimlik yönetimi, MFA ve grup temelli rolleri mümkün kılar.

3.3 Authorization sıralaması

API Server önce authentication, sonra authorization adımlarını uygular. Eğer RBAC izin vermezse diğer authorizer'lar (ör. webhook authorizer) tercih edilmez; RBAC etkinken diğer authorizer'lar da konfigürasyona bağlı çalışabilir. Önemli: order ve precedence (kimin hangisini kontrol ettiği) dikkatli tasarlanmalıdır.

3.4 Audit logging ve gözlemlenebilirlik

RBAC düzenlemeleri audit log'lara yansıtılmalıdır. Audit politikaları hangi çağrıların, hangi alanların kaydedileceğini belirler. Audit verileri SIEM veya log yönetim sistemine (ELK, Splunk, Datadog) gönderilip anomali tespiti ve uyumluluk raporlaması yapılabilir.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Büyük ekipler için least‑privilege ve izleme

Büyük platformlarda yüzlerce servis hesabı ve onlarca ekip olduğu için Netflix tarzı organizasyonlarda RBAC politikaları otomatik olarak üretilir, testedilir ve pipeline içinde enforce edilir. Audit log analitiği anormal API çağrılarını tespit etmek için kullanılır.

Uber — Multi‑tenant izolasyonu ve namespace politikaları

Çok sayıda ekipten oluşan platformlarda namespace bazlı izolasyon, Role/RoleBinding şablonları ve merkezi yönetilen ClusterRole'ler ile sağlanır. Ayrıca service account'ların kullanımı sınırlandırılarak otomasyon süreçleri ayrıştırılır.

Amazon — OIDC entegrasyonu ve managed policies

Managed Kubernetes hizmetleri OIDC ile IdP entegrasyonlarını kolaylaştırır; AWS IAM veya benzeri mekanizmalar ile kullanıcıların kısa süreli credentials ile API erişimi sağlanır. RBAC ile IAM arasındaki koordinasyon dikkatle kurulmalıdır (mapping, federation).

OpenAI — Model access ve service account governance

MLOps ve model serving platformlarında model erişimi, dataset erişimi gibi kritik izinler service account'lar üzerinden verilir; RBAC politikaları bu hesapların hangi persistent volumes, secrets veya namespace'lere erişebileceğini sınırlar.

Stripe — Fintech, audit ve uyumluluk

Finans sektöründe RBAC politikaları sıkı bir şekilde denetlenir. Değişiklikler PR ile yönetilir, audit log'lar arşivlenir ve periyodik review süreçleriyle least‑privilege doğrulaması yapılır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• İnce taneli yetkilendirme: Namespace veya resource bazlı kontrollere izin verir.
• Policy as code: YAML ile RBAC tanımları versiyonlanıp CI/CD ile yönetilebilir.
• Uyumluluk ve audit: Erişimlerin merkezileştirilmesi denetim süreçlerini kolaylaştırır.

Sınırlamalar

• Kompleksite: Büyük organizasyonlarda yüzlerce Role/Binding yönetimi karmaşıklaşır.
• Yanlış konfigürasyon riski: Overprivileged ya da eksik yetkiler operasyonda sorun yaratabilir.
• Identity mapping: İdP ile RBAC arasında doğru grup ve claim eşlemesi gerekli; yanlış mapping güvenlik açığı yaratır.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Least‑privilege ilkesini uygulayın: herkese ve her servise en düşük yetkiyi verin.
• Role ve ClusterRole'leri reuse edilebilir, modüler parçalar olarak tasarlayın; tekil, audit edilmiş ClusterRole'ler oluşturun.
• RoleBinding'leri sınırlayın: cluster‑wide binding'leri minimize edin; namespace‑scoped izinleri tercih edin.
• RBAC değişikliklerini PR tabanlı yönetin; değişikliklerin planını, reviewers ve otomatik testlerle kontrol edin.

Performans ve ölçeklenebilirlik

• Role/Binding sayısı arttığında yönetimi kolaylaştırmak için naming konvansiyonları ve etiketleme kullanın.
• Audit log'larını SIEM ile entegre edip erişim anomalilerini otomatik tespit edin.

Güvenlik

• Service account kullanımını zorunlu kılın; default service account kullanımını engelleyin.
• IdP (OIDC) ile kullanıcı ve grup yönetimini merkezi hale getirin; kısa süreli token ve MFA kullanın.
• ClusterRole'leri olabildiğince az kullanın; yönetimsel işler için ayrı bir yönetim plane (bootstrap account) mekanizması belirleyin.

Otomasyon ve test

• RBAC policy'lerini unit/integration test'lerle doğrulayın (konftest, kubeval vb.).
• DRY prensibini uygulayın: tekrar eden role tanımlarını şablonlayın ve registry veya internal module ile paylaşın.

8. SIK YAPILAN HATALAR

• default service account'a geniş izinler vermek — uygulama kaynaklarını aşırı yetkilendirmek.
• ClusterRoleBinding ile namespace rolünü yanlışlıkla cluster genelinde açmak.
• RBAC değişikliklerini doğrudan prod'a apply etmek; PR ve review sürecini atlamak.
• IdP‑RBAC mapping'ini test etmeden uygulamak — grup veya claim eşleştirme hataları oluşur.
• Audit log'ları ve revizyon geçmişi olmadan erişim değişikliklerini izlememek.

9. GELECEK TRENDLER

1. Policy as code evrimi: Tek bir policy diline doğru konsolidasyon ve merkezi governance araçlarının yükselişi.
2. Fine‑grained identity federation: Daha gelişmiş OIDC claim mapping ve attribute‑based erişim modelleri RBAC ile hibrit çalışacak.
3. AI destekli anomali tespiti: Erişim kalıplarını öğrenen modellerle sıra dışı kullanımın hızlı tespiti ve otomatik müdahale.
4. Dynamic least privilege: Zaman veya konteks bazlı izin ramping (çalışma anında açılma, görev bitince kapanma) çözümleri yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Role ile ClusterRole arasındaki temel fark nedir?

   Role namespace scoped iken ClusterRole cluster scoped'tur. Role yalnızca tanımlı namespace içinde geçerlidir; ClusterRole tüm cluster'da kullanılabilir.

2. 2. RoleBinding ile ClusterRoleBinding farkı nedir?

   RoleBinding namespace içindeki Role'ü subject ile bağlar. ClusterRoleBinding ise ClusterRole'ü subject ile cluster genelinde bağlar.

3. 3. Default service account kullanmak güvenli mi?

   Hayır. Default service account genelde geniş erişimlere sahip olabilir. Her uygulama için özel service account oluşturup yalnızca gereken izinleri atayın.

4. 4. RBAC değişikliklerini nasıl test etmeliyim?

   Role/Binding tanımlarını unit test'lerle kontrol edin, staging ortamında integration test'leri çalıştırın ve PR incelemeleri ile manuel review yapın. Konftest gibi araçlarla policy doğrulaması yapılabilir.

5. 5. OIDC ile RBAC nasıl entegre edilir?

   API Server'ı OIDC provider ile konfigure edip IdP'den gelen claim'leri (ör. groups) kullanarak RBAC RoleBinding'lerini oluşturursunuz. Claim mapping doğruluğu kritik olduğundan test edilmelidir.

6. 6. Çok sayıda Role/Binding ile nasıl başa çıkarım?

   Naming convention, etiketleme, module/templating (Helm, Kustomize veya iç araçlar) ve merkezi registry ile yönetimi kolaylaştırın. Ayrıca periyodik temizlik ve review süreçleri uygulayın.

7. 7. RBAC audit loglarını nereye göndersem?

   SIEM (Splunk, ELK/Opensearch, Datadog) veya bulut sağlayıcınızın log management servisine gönderin; anomali detection ve alert kuralları oluşturun.

8. 8. Kubernetes'te izinleri en küçük parçaya nasıl bölerim?

   Resource ve verb bazlı izin tanımları yapın; örneğin sadece 'get' izni verip 'delete' yetkisini ayrı role koyun. Ayrıca namespace bazlı ayrım yaparak erişimi sınırlandırın.

Anahtar Kavramlar

Role / ClusterRole

Yetki tanımlarını içeren kaynak; Role namespace scoped, ClusterRole cluster scoped.

RoleBinding / ClusterRoleBinding

Role veya ClusterRole ile subject arasındaki ilişkiyi tanımlar.

Subject

Kullanıcı, grup veya service account gibi yetki verilen kimlik.

Least privilege

Her kimliğe yalnızca gerekli minimum izinlerin verilmesi prensibi.

Audit log

API çağrılarının kaydı; erişim ve değişikliklerin izlenmesi için kullanılır.

Öğrenme Yol Haritası

1. 0–1 ay: RBAC temel kavramları (Role, RoleBinding, ClusterRole, ClusterRoleBinding) ve basit örneklerle başlayın.
2. 1–3 ay: OIDC entegrasyonu, service account kullanımı, audit log ve policy as code pratiklerini uygulayın.
3. 3–6 ay: Large scale RBAC yönetimi, otomatik policy testi (konftest), SIEM entegrasyonu ve periyodik erişim review süreçleri kurun.
4. 6–12 ay: Dynamic least privilege, attribute‑based erişim pattern'leri ve merkezi authorization servisleri ile ileri düzey uygulamalar geliştirin.