Kubernetes RBAC: Kümenizde Kim Ne Yapabilir? Yetki Yönetimi Rehberi

Kubernetes RBAC: Kümenizde Kim Ne Yapabilir? Yetki Yönetimi Rehberi

Kubernetes, modern uygulama dağıtım ve yönetiminin vazgeçilmez bir aracı haline gelirken, bu güçlü platformun güvenliğini sağlamak da en az kullanımı kadar kritik bir öneme sahiptir. Özellikle çok kullanıcılı veya çok takımlı ortamlarda, küme kaynaklarına kimin ne kadar erişimi olduğunu kontrol etmek, olası güvenlik ihlallerini ve yanlış yapılandırmaları önlemek için hayati bir gerekliliktir. İşte tam da bu noktada, Kubernetes RBAC (Role-Based Access Control – Rol Tabanlı Erişim Kontrolü) devreye girerek, kümenizdeki yetkilendirme mekanizmasını sağlam bir zemine oturtur ve “kimin ne yapabileceğini” net bir şekilde tanımlamanızı sağlar. Bu makale, RBAC’nin temel prensiplerinden başlayarak, pratik uygulamalarına ve ileri düzey kullanım senaryolarına kadar geniş bir perspektif sunacak ve kümenizin güvenliğini sağlamak için size kapsamlı bir rehber olacaktır.

Kubernetes Ortamlarında Güvenlik Neden Hayati Bir Konudur?

Günümüzün hızla değişen dijital dünyasında, yazılım geliştirme süreçleri ve operasyonları giderek karmaşıklaşıyor. Mikroservis mimarileri, bulut yerel uygulamalar ve sürekli entegrasyon/sürekli dağıtım (CI/CD) yaklaşımları, Kubernetes gibi konteyner orkestrasyon platformlarını merkeze alıyor. Ancak, bu güç ve esneklik beraberinde ciddi güvenlik risklerini de getiriyor. Bir Kubernetes kümesi, yüzlerce hatta binlerce konteyner, depolama birimi, ağ kuralı ve yapılandırma bilgisini barındırabilir. Bu kadar geniş bir ekosistemde, yetkilendirme (authorization) mekanizmalarının zayıf olması veya yanlış yapılandırılması, ciddi sonuçlara yol açabilir.

Düşünün ki, bir geliştirici ekibinin yanlışlıkla üretim ortamındaki kritik bir veritabanı pod’unu silme yetkisi var ya da bir dış kaynaklı denetim aracına gereğinden fazla erişim izni verilmiş. Bu tür senaryolar, veri kaybına, hizmet kesintilerine, fikri mülkiyet hırsızlığına veya mevzuat uyumluluğu ihlallerine neden olabilir. Geliştiriciler, operasyon ekipleri, güvenlik analistleri ve hatta otomatikleştirilmiş CI/CD boru hatları gibi farklı aktörlerin, küme içindeki farklı kaynaklara farklı seviyelerde erişim ihtiyacı vardır. Herkesin her şeye erişebildiği bir ortam, “güvenlik duvarı olmayan bir kale” gibidir. Bu nedenle, Kubernetes’te güçlü bir yetki yönetimi stratejisi uygulamak, sadece bir “en iyi uygulama” değil, aynı zamanda iş sürekliliği ve veri güvenliği için mutlak bir zorunluluktur. RBAC, bu karmaşık yetki matrisini yönetmek için tasarlanmış anahtar mekanizmadır ve kümenizdeki her eylemin, tanımlanmış roller ve izinler çerçevesinde gerçekleşmesini sağlar. Bu sayede, “en az yetki prensibi” (least privilege principle) kolayca uygulanabilir ve potansiyel güvenlik açıklarının önüne geçilebilir.

Ayrıca, büyük ölçekli organizasyonlarda, farklı departmanların veya projelerin kendi Kubernetes namespace’leri (isim alanları) içinde izole çalışması yaygın bir durumdur. Her ekibin sadece kendi sorumluluk alanındaki kaynaklara erişebilmesi, hem operasyonel verimliliği artırır hem de güvenlik risklerini sınırlar. RBAC, bu izolasyonu ve yetki dağılımını esnek bir şekilde yapılandırma imkanı sunar. Örneğin, bir “backend geliştirici” rolü sadece kendi uygulamasının pod’larını ve deployment’larını yönetebilirken, bir “devops mühendisi” rolü ağ politikaları veya küme genelindeki depolama sınıfları üzerinde daha geniş yetkilere sahip olabilir. Bu katmanlı ve detaylı yetkilendirme yapısı, özellikle denetlenebilirlik (auditability) açısından da büyük faydalar sağlar. Herhangi bir olay anında, kimin hangi yetkiyle hangi işlemi gerçekleştirdiğini kolayca tespit etmek, sorun giderme ve güvenlik analizi süreçlerini hızlandırır. Bu nedenle, Kubernetes RBAC, modern bulut yerel altyapılarının temel bir güvenlik bileşeni olarak kabul edilmeli ve dikkatle yapılandırılmalıdır.

RBAC Nedir ve Neden Vazgeçilmezdir? Temel Kavramlara Giriş

Kubernetes RBAC (Rol Tabanlı Erişim Kontrolü), bir Kubernetes kümesi içindeki kaynaklara kimlerin erişebileceğini ve hangi eylemleri gerçekleştirebileceğini belirleyen bir yetkilendirme mekanizmasıdır. Basitçe ifade etmek gerekirse, RBAC, kullanıcıları, grupları ve servis hesaplarını (Service Accounts) belirli “roller” ile ilişkilendirerek, bu rollere atanan izinler doğrultusunda küme kaynakları üzerinde işlem yapmalarına olanak tanır. Bu sayede, güvenlik politikalarınızı merkezi ve yönetilebilir bir şekilde tanımlayabilir, “herkesin her şeye erişimi” senaryosundan kaçınarak “en az yetki prensibi”ni uygulayabilirsiniz.

RBAC’nin Temel Bileşenleri Nelerdir?

RBAC’nin çalışma prensibini anlamak için dört ana bileşeni kavramak önemlidir:

1. Role (Rol): Bir Role, belirli bir Kubernetes namespace (isim alanı) içinde tanımlanan izinler kümesidir. Örneğin, bir Role, “development” namespace’indeki tüm pod’ları okuma (get, list, watch) yetkisine sahip olabilir. Role’ler, rules (kurallar) adı verilen bir dizi ile tanımlanır ve bu kurallar, hangi API kaynakları (pods, deployments, services vb.) üzerinde hangi fiillerin (get, list, create, update, delete vb.) yapılabileceğini belirtir. Role’ler, yalnızca tanımlandıkları namespace içinde geçerlidir.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: pod-okuyucu-rolu
rules:
- apiGroups: [""] # "" core API grubunu temsil eder (pods, services vb.)
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

2. ClusterRole (Küme Rolü): ClusterRole, Role'e benzer ancak kapsamı tüm küme genelidir. Yani, bir ClusterRole, belirli bir namespace ile sınırlı değildir. ClusterRole'lar, üç ana senaryoda kullanılır:
   • Küme genelindeki kaynaklar için yetkiler tanımlamak (örn: Node'lar, PersistentVolumes).
   • Tüm namespace'lerdeki belirli kaynaklar için yetkiler tanımlamak (örn: Tüm namespace'lerdeki Secret'ları okuma).
   • Namespace'e özel kaynaklar için varsayılan Role'ler sağlamak (örn: admin, edit, view gibi ön tanımlı ClusterRole'lar).

   ClusterRole'lar, genellikle küme yöneticileri veya küme genelinde işlem yapması gereken otomasyon araçları için kullanılır.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-yonetici-rolu
rules:
- apiGroups: ["apps"] # Deployment'lar "apps" API grubunda bulunur
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3. RoleBinding (Rol Bağlama): Bir RoleBinding, bir Role'ü belirli bir namespace içindeki bir kullanıcıya, gruba veya ServiceAccount'a bağlar. Bu, Role'de tanımlanan izinlerin, bağlanan "subject" (konu) tarafından kullanılabilmesini sağlar. Örneğin, "development" namespace'indeki "pod-okuyucu-rolu" adlı Role'ü, "ali" adlı kullanıcıya bağlayabilirsiniz. Bu durumda, "ali" sadece "development" namespace'indeki pod'ları okuyabilir.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ali-pod-okuyucu-baglama
  namespace: dev-team-a
subjects:
- kind: User # Kullanıcı
  name: ali # Kullanıcının adı (Kimlik doğrulama sisteminizden gelmeli)
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # Bağlanacak nesnenin türü
  name: pod-okuyucu-rolu # Bağlanacak Role'ün adı
  apiGroup: rbac.authorization.k8s.io

4. ClusterRoleBinding (Küme Rolü Bağlama): ClusterRoleBinding, bir ClusterRole'ü küme genelindeki bir kullanıcıya, gruba veya ServiceAccount'a bağlar. RoleBinding'den farklı olarak, ClusterRoleBinding'in kapsamı tüm kümedir ve belirli bir namespace ile sınırlı değildir. Örneğin, "deployment-yonetici-rolu" adlı ClusterRole'ü "devops-ekibi" adlı bir gruba bağlayabilirsiniz. Bu durumda, "devops-ekibi"ndeki tüm kullanıcılar tüm namespace'lerdeki deployment'ları yönetebilir.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: devops-ekibi-deployment-yonetici-baglama
subjects:
- kind: Group # Grup
  name: devops-ekibi # Grubun adı (Kimlik doğrulama sisteminizden gelmeli)
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole # Bağlanacak nesnenin türü
  name: deployment-yonetici-rolu # Bağlanacak ClusterRole'ün adı
  apiGroup: rbac.authorization.k8s.io

Bu bileşenler bir araya gelerek, Kubernetes kümenizde son derece granüler ve esnek bir yetki matrisi oluşturmanıza olanak tanır. Kullanıcılarınızı ve uygulamalarınızı sadece ihtiyaç duydukları kaynaklara, ihtiyaç duydukları fiillerle erişimini sağlayarak, güvenlik duruşunuzu önemli ölçüde güçlendirebilirsiniz. RBAC'nin doğru bir şekilde yapılandırılması, özellikle çok kullanıcılı ve büyük ölçekli Kubernetes ortamlarında, güvenlik denetimi ve uyumluluk gereksinimleri açısından kritik bir rol oynar.

Uygulamalı RBAC: Rol ve Rol Bağlamaları Nasıl Oluşturulur?

Teorik bilgileri pekiştirmek adına, şimdi gerçek dünya senaryoları üzerinden adım adım RBAC objelerini nasıl oluşturacağımızı ve uygulayacağımızı inceleyelim. Bu bölümde, hem namespace bazında hem de küme genelinde yetkilendirme örnekleri göreceğiz. Unutmayın, bu örnekler sadece başlangıç noktasıdır ve kendi güvenlik ihtiyaçlarınıza göre uyarlanmalıdır.

Senaryo 1: Geliştiriciye Belirli Bir Namespace'te Pod Okuma Yetkisi Verme

Bir geliştirici ekibinizin olduğunu ve bu ekibin sadece kendi dev-proje-x adındaki namespace'inde çalışan uygulamaların pod'larını izlemesi gerektiğini varsayalım. Bu ekibin diğer namespace'lere veya dev-proje-x içindeki diğer kaynaklara (örneğin, Secret'lar, ConfigMap'ler) erişmemesi gerekiyor. Bu senaryoyu RBAC ile şu şekilde yönetebiliriz:

Adım 1: Namespace Oluşturma (Eğer yoksa)

Öncelikle, yetkilendirme yapacağımız namespace'i oluşturalım:

kubectl create namespace dev-proje-x

Adım 2: Role Tanımlama

Şimdi, dev-proje-x namespace'i içinde pod'ları okuma yetkisi verecek bir Role tanımlayalım. Bu Role, sadece get, list ve watch fiillerini pods ve pods/log kaynakları üzerinde uygulayabilecek.

Aşağıdaki YAML dosyasını dev-pod-okuyucu-role.yaml olarak kaydedin:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-proje-x
  name: dev-pod-okuyucu-role
rules:
- apiGroups: [""] # Core API grubu için boş string kullanılır
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Bu Role'ü kümeye uygulayın:

kubectl apply -f dev-pod-okuyucu-role.yaml

Adım 3: RoleBinding Oluşturma

Şimdi bu Role'ü, dev-proje-x namespace'indeki gelistirici-ali adlı bir kullanıcıya bağlayalım. Kimlik doğrulama mekanizmanızın (örn: OIDC, sertifika) gelistirici-ali kullanıcısını tanıdığını varsayıyoruz.

Aşağıdaki YAML dosyasını ali-dev-pod-okuyucu-rb.yaml olarak kaydedin:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ali-dev-pod-okuyucu-binding
  namespace: dev-proje-x
subjects:
- kind: User
  name: gelistirici-ali # Kubernetes kümesine erişim sağlayan kullanıcının adı
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-pod-okuyucu-role
  apiGroup: rbac.authorization.k8s.io

Bu RoleBinding'i kümeye uygulayın:

kubectl apply -f ali-dev-pod-okuyucu-rb.yaml

Artık gelistirici-ali kullanıcısı, sadece dev-proje-x namespace'inde pod'ları listeleyebilir, görüntüleyebilir ve loglarını okuyabilir. Diğer namespace'lere veya dev-proje-x içindeki farklı kaynaklara erişim denemeleri başarısız olacaktır.

Senaryo 2: Operasyon Ekibine Tüm Kümede Deployment Yönetme Yetkisi Verme

Bir operasyon ekibinizin olduğunu ve bu ekibin tüm küme genelindeki tüm namespace'lerde deployment'ları ve ilgili ReplicaSet'leri oluşturma, güncelleme, silme yetkisine sahip olması gerektiğini varsayalım. Bu yetki, küme genelinde bir sorumluluk gerektirdiği için ClusterRole ve ClusterRoleBinding kullanacağız.

Adım 1: ClusterRole Tanımlama

Tüm kümedeki deployment'ları yönetme yetkisi verecek bir ClusterRole tanımlayalım. Bu rol, apps API grubundaki deployments ve replicasets kaynakları üzerinde tam kontrol (get, list, watch, create, update, patch, delete) yetkisi verecek.

Aşağıdaki YAML dosyasını deployment-yonetici-clusterrole.yaml olarak kaydedin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-yonetici-clusterrole
rules:
- apiGroups: ["apps"] # Deployment'lar "apps" API grubunda yer alır
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Bu ClusterRole'ü kümeye uygulayın:

kubectl apply -f deployment-yonetici-clusterrole.yaml

Adım 2: ClusterRoleBinding Oluşturma

Şimdi bu ClusterRole'ü, operasyon-ekibi adlı bir gruba bağlayalım. Bu grup, kimlik doğrulama sisteminiz tarafından tanınan bir grup olmalıdır.

Aşağıdaki YAML dosyasını op-ekibi-deployment-yonetici-crb.yaml olarak kaydedin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: op-ekibi-deployment-yonetici-binding
subjects:
- kind: Group
  name: operasyon-ekibi # Kimlik doğrulama sisteminizdeki grubun adı
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: deployment-yonetici-clusterrole
  apiGroup: rbac.authorization.k8s.io

Bu ClusterRoleBinding'i kümeye uygulayın:

kubectl apply -f op-ekibi-deployment-yonetici-crb.yaml

Bu yapılandırma ile operasyon-ekibi grubundaki tüm kullanıcılar, kümedeki tüm namespace'lerde deployment'ları ve ReplicaSet'leri tam yetkiyle yönetebilirler.

Yetkileri Test Etme: kubectl auth can-i

Oluşturduğunuz RBAC kurallarının doğru çalışıp çalışmadığını test etmek için kubectl auth can-i komutunu kullanabilirsiniz. Bu komut, belirli bir kullanıcı veya ServiceAccount'ın belirli bir eylemi gerçekleştirip gerçekleştiremeyeceğini kontrol eder.

• gelistirici-ali kullanıcısının dev-proje-x namespace'inde pod listeleyip listeleyemediğini kontrol edelim:

  
  kubectl auth can-i list pods --namespace dev-proje-x --as=gelistirici-ali
  # Çıktı: yes
  

• gelistirici-ali kullanıcısının dev-proje-x namespace'inde deployment oluşturup oluşturamayacağını kontrol edelim:

  
  kubectl auth can-i create deployments --namespace dev-proje-x --as=gelistirici-ali
  # Çıktı: no
  

• gelistirici-ali kullanıcısının başka bir namespace'te (örn: default) pod listeleyip listeleyemediğini kontrol edelim:

  
  kubectl auth can-i list pods --namespace default --as=gelistirici-ali
  # Çıktı: no
  

• operasyon-ekibi grubundaki bir kullanıcının (örneğin operasyon-murat) uretim namespace'inde deployment silip silemeyeceğini kontrol edelim:

  
  kubectl auth can-i delete deployments --namespace uretim --as=operasyon-murat --as-group=operasyon-ekibi
  # Çıktı: yes
  

Bu komut, RBAC politikalarınızı doğrulamak ve beklenmedik yetki sorunlarını gidermek için son derece değerli bir araçtır. Unutmayın, as ve as-group parametreleri, kimlik doğrulama sistemi tarafından tanınan kullanıcı veya grup adlarını belirtmelidir. Bu pratik örnekler, RBAC'nin esnekliğini ve güçlü yeteneklerini anlamanıza yardımcı olacaktır. Her zaman "en az yetki prensibi"ni göz önünde bulundurarak, kullanıcılarınıza ve ServiceAccount'larınıza yalnızca işlerini yapmaları için gerekli olan minimum yetkileri vermeye özen gösterin.

En İyi Uygulamalar ve İleri Düzey RBAC Yönetimi

Kubernetes RBAC'yi sadece temel düzeyde kullanmak yerine, ileri düzey teknikler ve en iyi uygulamalarla birleştirerek kümenizin güvenliğini ve yönetimini daha da optimize edebilirsiniz. Bu bölümde, RBAC stratejinizi güçlendirecek bazı önemli noktaları ve vaka analizlerini ele alacağız.

En Az Yetki Prensibi (Least Privilege Principle): Neden Önemli?

En az yetki prensibi, bir kullanıcının, sürecin veya uygulamanın görevini yerine getirmesi için kesinlikle gerekli olan minimum izinlere sahip olması gerektiğini savunan bir güvenlik ilkesidir. Kubernetes RBAC bağlamında bu, geliştiricilere sadece kendi namespace'lerinde pod'ları görebilme, operasyon ekibine sadece belirli kaynakları yönetebilme ve otomasyon araçlarına sadece belirli API çağrılarını yapabilme yetkisi vermek anlamına gelir. Neden bu kadar önemli?

• Saldırı Yüzeyini Azaltma: Daha az yetki, bir saldırganın sistemde hareket etme yeteneğini sınırlar. Eğer bir kullanıcının kimlik bilgileri ele geçirilirse, bu kullanıcının yapabileceği hasar, sahip olduğu yetkilerle orantılı olacaktır.
• Yanlışlıkla Yapılan Hataları Önleme: İnsan hatası kaçınılmazdır. Yanlışlıkla kritik bir kaynağın silinmesi veya değiştirilmesi, yetkilerin kısıtlı olması durumunda çok daha az olasıdır.
• Denetlenebilirlik ve Uyum: Kimin neye erişimi olduğunu net bir şekilde tanımlamak, denetim süreçlerini kolaylaştırır ve sektör standartları ile yasal uyumluluk gereksinimlerini karşılamaya yardımcı olur.
• Karmaşıklığı Yönetme: Büyük kümelerde, her kullanıcının veya uygulamanın tam olarak neye ihtiyacı olduğunu belirlemek zor olabilir. Ancak bu çaba, uzun vadede güvenlik ve operasyonel verimlilik açısından karşılığını fazlasıyla verir.

Bu prensibi uygulamak için, her zaman "neye izin vereceğim?" yerine "neyi yasaklamalıyım?" sorusunu sormak yerine, "bu kullanıcı/servis hesabı bu görevi yerine getirmek için tam olarak hangi yetkilere ihtiyaç duyuyor?" sorusuna odaklanmalısınız. İzinleri adım adım artırmak, başlangıçta geniş yetkiler verip sonra kısıtlamaktan daha güvenli bir yaklaşımdır.

Varsayılan Küme Rolleri (Default ClusterRoles) ve Kullanımı

Kubernetes, kurulumla birlikte gelen bazı önceden tanımlanmış ClusterRole'lara sahiptir. Bunlar, yaygın kullanım senaryolarını kapsar ve RBAC yapılandırmanıza bir başlangıç noktası olabilir:

• cluster-admin: Süper kullanıcı yetkisi. Tüm kaynaklar üzerinde tam kontrol. Sadece en güvendiğiniz kişilere veya otomasyon araçlarına verilmelidir.
• admin: Bir namespace içindeki tüm kaynakları yönetme yetkisi, ancak küme genelindeki kaynakları yönetme yetkisi yoktur. Genellikle bir RoleBinding ile belirli bir namespace'e bağlanır.
• edit: Bir namespace içindeki çoğu kaynağı okuma ve yazma yetkisi (RoleBinding, ClusterRoleBinding hariç). Genellikle bir RoleBinding ile belirli bir namespace'e bağlanır.
• view: Bir namespace içindeki çoğu kaynağı sadece okuma yetkisi. Genellikle bir RoleBinding ile belirli bir namespace'e bağlanır.

Bu varsayılan rolleri kullanarak kendi özel rollerinizi oluşturmaktan kaçınabilir veya onları temel alarak daha spesifik roller türetebilirsiniz. Örneğin, bir geliştiriciye dev-proje-x namespace'inde edit yetkisi vermek için, edit ClusterRole'ünü bir RoleBinding ile o namespace'e bağlamanız yeterlidir.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gelistirici-edit-binding
  namespace: dev-proje-x
subjects:
- kind: User
  name: gelistirici-ayse
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole # Varsayılan ClusterRole'ü kullanıyoruz
  name: edit
  apiGroup: rbac.authorization.k8s.io

Bu, özel bir Role tanımlamaktan daha hızlı ve standart bir yaklaşım olabilir, ancak yine de "en az yetki" prensibine uygun olup olmadığını değerlendirmelisiniz.

RBAC'yi Otomatikleştirmek: GitOps ve CI/CD Entegrasyonu

Büyük ve dinamik Kubernetes ortamlarında RBAC politikalarını manuel olarak yönetmek sürdürülebilir değildir. GitOps ve CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) yaklaşımlarını kullanarak RBAC yönetimini otomatikleştirebilirsiniz. Bu, RBAC YAML dosyalarını bir Git deposunda (repository) tutmak ve bu dosyaların değişikliklerini otomatik olarak kümenize uygulamak anlamına gelir.

• GitOps: RBAC politikalarınızı kod olarak (YAML) Git'te saklayın. Herhangi bir değişiklik, bir Pull Request (Çekme İsteği) ile gözden geçirilir ve onaylandıktan sonra otomatik olarak kümeye senkronize edilir (örn: Argo CD, Flux gibi araçlarla). Bu, denetlenebilir, geri alınabilir ve versiyonlanmış bir RBAC yönetimi sağlar.
• CI/CD Entegrasyonu: Geliştiriciler veya operasyon ekipleri yeni bir uygulama dağıttığında veya mevcut bir uygulamanın yetki gereksinimleri değiştiğinde, ilgili RBAC YAML dosyalarını uygulama kodlarıyla birlikte depoya ekleyebilirler. CI/CD boru hatları, bu değişiklikleri algılayıp RBAC objelerini otomatik olarak kümeye uygulayabilir. Bu, yetki yönetimini uygulama yaşam döngüsünün doğal bir parçası haline getirir.

Vaka Analizi: Büyük Bir Şirketin RBAC ile Güvenlik İhlallerini Önlemesi

Büyük bir e-ticaret şirketi olan "HızlıMarket", birden fazla geliştirme ekibi, operasyon ekibi ve veri analizi ekibiyle çalışan devasa bir Kubernetes kümesi kullanıyordu. Başlangıçta, tüm ekiplere geniş yetkiler verilmişti, bu da sık sık yanlışlıkla kaynak silinmelerine