Kubernetes RBAC: Roller ve Rol Bağlamaları ile Güvenli Yetkilendirme

Kubernetes’te yetkilendirme ve erişim kontrolü nasıl sağlanır? RBAC (Rol Tabanlı Erişim Kontrolü), kullanıcıların ve servis hesaplarının küme kaynaklarına erişimini güvenli bir şekilde yönetmek için merkezi bir yöntem sunar. Bu makalede, Kubernetes RBAC’ın temel taşları olan Roller ve Rol Bağlamaları kavramlarını detaylıca inceleyerek, küme güvenliğinizi nasıl güçlendirebileceğinizi öğreneceksiniz.

Kubernetes, modern uygulama geliştirme ve dağıtım süreçlerinin vazgeçilmez bir parçası haline gelmiş, konteyner tabanlı iş yüklerini yönetmek için güçlü bir platform sunar. Ancak bu gücün beraberinde getirdiği en önemli sorumluluklardan biri de güvenliktir. Özellikle çok kullanıcılı veya çok takımlı ortamlarda, kimin neye erişebileceğini, hangi işlemleri gerçekleştirebileceğini kontrol etmek hayati önem taşır. İşte tam da bu noktada RBAC (Role-Based Access Control – Rol Tabanlı Erişim Kontrolü) devreye girer. RBAC, Kubernetes kümesindeki kullanıcılara (gerçek kullanıcılar, servis hesapları veya gruplar) belirli kaynaklar üzerinde belirli eylemleri gerçekleştirme yetkisi tanımlamanın standart ve en güvenli yoludur.

Erişim kontrolü olmadan, herhangi bir kullanıcının veya uygulamanın kümedeki tüm kaynaklara sınırsız erişimi olabilir ki bu, ciddi güvenlik zafiyetlerine yol açar. Örneğin, geliştirme ekibinden birinin yanlışlıkla üretim veritabanını silmesi veya kötü niyetli bir aktörün kritik küme bileşenlerine erişim sağlaması gibi senaryolar felaketle sonuçlanabilir. RBAC, bu tür riskleri ortadan kaldırmak için “en az ayrıcalık prensibi”ni uygulamanıza olanak tanır. Bu prensibe göre, bir kullanıcıya veya servise yalnızca görevlerini yerine getirebilmeleri için kesinlikle gerekli olan minimum yetkiler verilmelidir. Bu yaklaşım, yetki yükseltme saldırılarının ve istenmeyen erişimlerin önüne geçerek kümenizin genel güvenlik duruşunu önemli ölçüde güçlendirir.

Geçmişte Kubernetes’te ABAC (Attribute-Based Access Control) gibi yetkilendirme yöntemleri de kullanılmış olsa da, RBAC çok daha esnek, okunabilir ve yönetilebilirdir. ABAC, politikaların karmaşık ve ölçeklendirmesi zor olmasına neden olurken, RBAC’ın declarative (bildirimsel) yapısı sayesinde politikaları YAML dosyalarıyla kolayca tanımlayabilir, versiyon kontrol sistemlerinde izleyebilir ve GitOps prensipleriyle otomatikleştirebilirsiniz. Bu sayede, güvenlik politikalarınız kod gibi ele alınır ve sürekli entegrasyon/sürekli dağıtım (CI/CD) süreçlerine dahil edilebilir. Kısacası, RBAC sadece bir güvenlik mekanizması değil, aynı zamanda küme yönetimi ve otomasyonunun da temel bir yapı taşıdır.

RBAC, üç ana bileşen etrafında şekillenir: Subject (Kim – kullanıcı, grup veya servis hesabı), Verb (Ne Yapabilir – get, create, delete gibi eylemler) ve Resource (Ne Üzerinde – podlar, servisler, deploylar gibi küme kaynakları). Bu makalenin devamında, bu bileşenleri kullanarak nasıl etkili RBAC politikaları oluşturacağınızı, Roller ve Rol Bağlamaları ile kümenizi nasıl güvence altına alacağınızı adım adım keşfedeceğiz. Unutmayın, iyi yapılandırılmış bir RBAC, Kubernetes kümenizin hem güvenliğini hem de operasyonel verimliliğini artıran temel bir yatırımdır.

Kubernetes Rollerini Anlamak: Yetkileri Nasıl Tanımlarız?

RBAC’ın kalbinde “Roller” bulunur. Roller, belirli bir API grubundaki belirli kaynaklar üzerinde hangi fiillerin (verbs) gerçekleştirilebileceğini tanımlayan bir dizi kural koleksiyonudur. Yani, bir rol, “kimin ne yapabileceğini” değil, “ne tür eylemlerin yapılabileceğini” belirler. Roller, yetkilendirme sisteminin temelini oluşturur ve kullanıcıların veya servis hesaplarının hangi ayrıcalıklara sahip olacağını belirleyen soyut kurallar kümesini temsil eder. Kubernetes’te iki ana Rol tipi vardır ve bunlar, yetki kapsamlarına göre farklılık gösterir:

1. Role (Namespace Scope): Bir Role nesnesi, yetkileri yalnızca belirli bir Kubernetes namespace’i (ad alanı) ile sınırlar. Bu, geliştirme, test veya üretim gibi farklı ortamlar için ayrı ayrı, izole yetkilendirme politikaları oluşturmak istediğinizde oldukça kullanışlıdır. Örneğin, “dev” namespace’inde pod oluşturma ve loglarını okuma yetkisi veren bir Role tanımlayabilirsiniz. Bu Role, “prod” namespace’indeki kaynaklar üzerinde herhangi bir etkiye sahip olmayacaktır.
2. ClusterRole (Cluster Scope): Bir ClusterRole nesnesi ise yetkileri tüm Kubernetes kümesi genelinde tanımlar. Bu tür roller, namespace’e bağlı olmayan kaynaklar (örneğin, Node’lar, PersistentVolume’lar) üzerinde yetki vermek veya küme genelindeki tüm namespace’lerde geçerli olacak yetkileri tanımlamak için kullanılır. Örneğin, tüm namespace’lerde podları listeleyebilen veya küme genelinde yeni namespace’ler oluşturabilen bir ClusterRole tanımlayabilirsiniz. ClusterRoleler genellikle yönetici (admin) veya küme gözlemcisi (cluster-viewer) gibi geniş kapsamlı roller için tercih edilir.

Bir rol tanımlarken, rules alanı altında apiGroups, resources ve verbs belirtilir. apiGroups, yetki verilen API grubunu belirtir (örn. "" core API grubunu, apps Deployment’ları vb. temsil eder). resources, üzerinde işlem yapılabilecek kaynakları (örn. pods, deployments, services), verbs ise yapılabilecek eylemleri (örn. get, list, watch, create, update, delete, patch) ifade eder. Bu üçlüyü doğru bir şekilde bir araya getirerek, çok hassas yetkilendirme kuralları oluşturabilirsiniz. Örneğin, “okuyucu” rolü sadece get, list, watch fiillerini içerebilirken, “yönetici” rolü tüm fiilleri (*) içerebilir.

Aşağıdaki örnekte, dev isimli namespace içinde podları ve pod loglarını okuma yetkisi veren bir Role tanımlanmıştır. Bu rol, bir geliştiricinin kendi uygulama podlarının durumunu izlemesi veya loglarını görüntülemesi için yeterli olacaktır, ancak herhangi bir değişiklik yapmasına izin vermeyecektir.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev # Bu rol sadece 'dev' namespace'inde geçerlidir
  name: pod-okuyucu
rules:
- apiGroups: [""] # "" core API grubu anlamına gelir
  resources: ["pods", "pods/log"] # Pod kaynakları ve pod loglarına erişim
  verbs: ["get", "list", "watch"] # Okuma yetkileri: Getir, Listele, İzle

ClusterRole tanımı da benzerdir, ancak metadata.namespace alanı belirtilmez, çünkü küme genelinde geçerlidir. Örneğin, tüm namespace'lerde servisleri listeleyebilen bir ClusterRole şöyle tanımlanabilir:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: servis-listeleyici
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["list", "watch"]

Bu yetkilendirme tanımları, kümenizin güvenlik mimarisini oluştururken temel yapı taşlarıdır. Rolleri doğru bir şekilde tanımlamak, sonraki adımda bu rolleri belirli "kimliklere" nasıl atayacağımızı belirleyeceğimiz Rol Bağlamaları için sağlam bir zemin hazırlar. Unutmayın, güçlü bir güvenlik, iyi düşünülmüş ve ince ayarlanmış rol tanımlarıyla başlar.

Rol Bağlamaları ile Yetkileri Atamak: Kimlere Ne Kadar Yetki Veriyoruz?

Rolleri tanımlamak, yetkilendirme bulmacasının yalnızca ilk parçasıdır. Tanımladığımız bu yetki kurallarını gerçek kullanıcılar, servis hesapları veya kullanıcı gruplarına atamamız gerekir. İşte tam da bu noktada "Rol Bağlamaları" (RoleBindings) devreye girer. Rol Bağlamaları, bir Role'ü veya ClusterRole'ü belirli "subject"lere (konulara) bağlayan Kubernetes kaynaklarıdır. Bu sayede, "kimin" hangi Role'ün tanımladığı "ne yapma yetkisine" sahip olduğunu belirlemiş oluruz. Tıpkı Rollerde olduğu gibi, Rol Bağlamaları da kapsamlarına göre ikiye ayrılır:

1. RoleBinding (Namespace Scope): Bir RoleBinding nesnesi, bir Role'ü (veya bir ClusterRole'ü) belirli bir namespace içindeki subject'lere bağlar. Eğer bir RoleBinding bir ClusterRole'e atıfta bulunuyorsa, bu ClusterRole'ün küme genelindeki tüm yetkileri yalnızca RoleBinding'in tanımlandığı namespace içinde geçerli olacaktır. Bu, ClusterRole'leri daha granüler bir şekilde kullanma esnekliği sağlar. Örneğin, "dev" namespace'inde pod oluşturma yetkisi veren bir Role'ü belirli bir geliştiriciye atamak için RoleBinding kullanılır.
2. ClusterRoleBinding (Cluster Scope): Bir ClusterRoleBinding nesnesi, bir ClusterRole'ü küme genelindeki subject'lere bağlar. Bu, ClusterRole'ün tanımladığı yetkilerin tüm kümede ve tüm namespace'lerde geçerli olacağı anlamına gelir. ClusterRoleBinding genellikle küme yöneticilerine veya küme çapında yetkilere ihtiyaç duyan servis hesaplarına geniş erişim vermek için kullanılır. Örneğin, tüm namespace'lerde podları listeleyebilen ClusterRole'ü bir izleme aracının servis hesabına atamak için ClusterRoleBinding kullanılır.

Bir Rol Bağlaması tanımlarken, subjects ve roleRef olmak üzere iki ana alanı belirtiriz. subjects alanı, yetkilendirilecek kişiyi veya varlığı (kullanıcı, grup veya servis hesabı) belirtir. Kubernetes'te bu subject türleri şunlardır:

• User: Harici bir kimlik doğrulama sistemi (örn. OIDC, sertifika) tarafından doğrulanmış gerçek kullanıcılar. Genellikle name alanında kullanıcının adı belirtilir.
• Group: Bir grup kimlik doğrulama sistemi tarafından doğrulanmış kullanıcı grupları. Bir gruba yetki vermek, o gruptaki tüm kullanıcılara otomatik olarak aynı yetkileri sağlar.
• ServiceAccount: Kubernetes içinde çalışan uygulamaların kendilerini kimlik doğrulaması ve küme API'si ile etkileşim kurması için kullanılan özel hesaplardır. Genellikle botlar, uygulamalar ve kontrolörler tarafından kullanılırlar.

roleRef alanı ise bağlanacak Role'ün veya ClusterRole'ün adını ve türünü belirtir. Bu alan, Rol Bağlamasının hangi yetki kümesine atıfta bulunduğunu açıkça gösterir.

Aşağıdaki örnek, daha önce tanımladığımız pod-okuyucu isimli Role'ü alice adında bir kullanıcıya dev namespace'inde atayan bir RoleBinding YAML'ı gösterir:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-okuyucu-binding
  namespace: dev # Bu bağlama sadece 'dev' namespace'inde geçerlidir
subjects:
- kind: User # Yetki verilecek subject'in türü: Kullanıcı
  name: alice # Kullanıcının adı
  apiGroup: rbac.authorization.k8s.io # RBAC API grubu
roleRef:
  kind: Role # Bağlanacak referansın türü: Role
  name: pod-okuyucu # Bağlanacak Role'ün adı
  apiGroup: rbac.authorization.k8s.io # RBAC API grubu

Benzer şekilde, bir ClusterRoleBinding örneği:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-bob
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin # Kubernetes'in varsayılan, tüm yetkilere sahip ClusterRole'ü
  apiGroup: rbac.authorization.k8s.io

Bu ClusterRoleBinding, bob isimli kullanıcıya Kubernetes kümesinde tam yönetici yetkileri verir. Görüldüğü gibi, Rol Bağlamaları sayesinde, tanımladığımız yetki kurallarını esnek ve modüler bir şekilde farklı kimliklere atayabiliriz. Bu, kümenizin güvenliğini sağlamanın temel direklerinden biridir ve doğru kullanımı, yetkisiz erişim riskini önemli ölçüde azaltır.

Gerçek Dünya Senaryosu: Geliştirici Ortamı İçin Detaylı RBAC Uygulaması

Teorik bilgileri pekiştirmek için şimdi gerçek bir senaryo üzerinden ilerleyelim. Bir şirket düşünelim; bu şirketin "Frontend Takımı" adında bir geliştirici ekibi var. Bu ekip, Kubernetes kümesindeki frontend-dev isimli namespace'te kendi mikroservislerini dağıtacak, yönetecek ve hata ayıklaması yapacak. Ancak, bu takımın backend-prod veya system gibi diğer kritik namespace'lere erişimi olmamalı. Ayrıca, geliştiricilerin sadece kendi namespace'leri içinde Deployment'lar oluşturmasına, Pod'ları ve Servisleri listelemesine izin verilmeli, ancak kritik küme kaynakları üzerinde herhangi bir değişiklik yapamamalılar. İşte bu kısıtlamaları RBAC ile nasıl uygulayacağımızı adım adım görelim:

Adım 1: Geliştirici Namespace'ini Oluşturma

İlk olarak, Frontend Takımı için özel bir namespace oluşturalım. Bu, yetkilendirmeyi izole etmemizi sağlar.

apiVersion: v1
kind: Namespace
metadata:
  name: frontend-dev

Bu YAML dosyasını uygulayarak namespace'i oluşturun: kubectl apply -f namespace.yaml

Adım 2: Geliştiricilerin İhtiyacı Olan Yetkileri Tanımlayan Bir Rol Oluşturma

Şimdi, frontend-dev namespace'inde geçerli olacak, geliştiricilere Deployments, Pods ve Services üzerinde get, list, watch, create, update, patch, delete yetkilerini veren bir Role oluşturalım. Pods/log için de okuma yetkisi ekleyelim.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: frontend-dev # Bu rol sadece bu namespace'te geçerlidir
  name: frontend-developer
rules:
- apiGroups: ["apps"] # Deployment'lar bu API grubundadır
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""] # Core API grubu
  resources: ["pods", "pods/log", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Bu YAML dosyasını uygulayın: kubectl apply -f frontend-developer-role.yaml

Adım 3: Geliştirici Grubu İçin Rol Bağlaması Oluşturma

Şirketimizin kimlik doğrulama sistemi, Frontend Takımı üyelerini frontend-team adında bir grup altında yönetiyor olsun. Bu gruba yukarıda tanımladığımız frontend-developer Rol'ünü atayan bir RoleBinding oluşturalım.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-team-binding
  namespace: frontend-dev
subjects:
- kind: Group # Bir kullanıcı grubu
  name: frontend-team # Grubun adı
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: frontend-developer
  apiGroup: rbac.authorization.k8s.io

Bu YAML dosyasını uygulayın: kubectl apply -f frontend-team-rolebinding.yaml

Yetkileri Doğrulama ve Test Etme

Şimdi, kubectl auth can-i komutu ile bu politikaların doğru çalıştığını test edebiliriz. Bu komut, belirli bir kullanıcı veya grup için belirli bir eylemin mümkün olup olmadığını kontrol etmenizi sağlar.

• frontend-team grubundaki bir üyenin frontend-dev namespace'inde pod oluşturup oluşturamayacağını kontrol edelim:

  
  kubectl auth can-i create pods --namespace frontend-dev --as-group frontend-team
  # Sonuç: yes
        

• Aynı grubun backend-prod namespace'inde deployment oluşturup oluşturamayacağını kontrol edelim:

  
  kubectl auth can-i create deployments --namespace backend-prod --as-group frontend-team
  # Sonuç: no
        

• Bir yöneticinin (varsayılan olarak system:masters grubuna dahil olanlar) frontend-dev namespace'inde her şeyi yapıp yapamayacağını kontrol edelim:

  
  kubectl auth can-i '*' '*' --namespace frontend-dev --as-group system:masters
  # Sonuç: yes
        

Bu senaryo, RBAC'ın nasıl kullanılabileceğini ve ekiplerin küme kaynaklarına erişimini nasıl güvenli bir şekilde yönetebileceğinizi göstermektedir. Geliştiriciler artık kendi ortamlarında bağımsız çalışabilirken, diğer kritik sistemlere veya üretim ortamlarına yanlışlıkla erişimlerinin önüne geçilmiş olur. Bu tür detaylı planlama ve uygulama, Kubernetes kümelerinizin güvenliğini sağlamak için vazgeçilmezdir. Gerçek dünya senaryoları genellikle daha karmaşık olsa da, bu temel adımlar her zaman başlangıç noktası olacaktır.

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

Kubernetes RBAC'ı doğru bir şekilde anlamak ve temel yapı taşlarını kullanmak önemlidir, ancak kümenizin güvenliğini gerçekten pekiştirmek için ileri düzey konuları ve en iyi uygulamaları da göz önünde bulundurmalısınız. Bu bölüm, daha deneyimli kullanıcılar için RBAC'ı daha etkin ve güvenli bir şekilde yönetme konusunda ipuçları ve ek bilgiler sunacaktır.

En Az Ayrıcalık Prensibini Uygulamak

Daha önce de bahsettiğimiz gibi, bu prensip RBAC'ın temelidir. Bir kullanıcıya veya servis hesabına, görevini yerine getirmesi için yalnızca kesinlikle gerekli olan minimum yetkiyi verin. Örneğin, bir uygulama sadece podları listeleyecekse, ona pod oluşturma veya silme yetkisi vermeyin. * (tüm yetkiler) veya "*" (tüm kaynaklar) kullanmaktan kaçının. Bu, saldırı yüzeyini daraltır ve olası güvenlik ihlallerinin etkisini sınırlar.

Varsayılan RBAC Rollerini Anlamak

Kubernetes, kurulum sırasında bir dizi varsayılan ClusterRole ve ClusterRoleBinding ile birlikte gelir. Bunları bilmek, kümenizin başlangıçtaki yetkilendirme durumunu anlamanıza yardımcı olur:

• cluster-admin: Süper kullanıcı yetkileri verir, tüm kaynaklar üzerinde her şeyi yapabilir. Yalnızca güvenilir yöneticilere atayın.
• admin: Bir namespace içinde neredeyse tam yetkilere sahiptir, ancak küme genelindeki kaynaklara erişemez.
• edit: Bir namespace içinde çoğu şeyi değiştirebilir (deployment'lar, servisler vb.), ancak rol bağlamaları veya kota gibi güvenlik/altyapı ayarlarını değiştiremez.
• view: Bir namespace içindeki kaynakları yalnızca okuyabilir (get, list, watch). Hiçbir değişiklik yapma yetkisi yoktur.

Bu varsayılan rolleri doğrudan kullanmak yerine, başlangıç noktası olarak alıp kendi özel rollerinizi oluşturmak genellikle daha güvenlidir, böylece tam olarak hangi yetkileri verdiğinizi bilirsiniz.

ServiceAccount'lar ve RBAC İlişkisi

Kubernetes'te çalışan uygulamalar, küme API'si ile etkileşim kurmak için ServiceAccount'ları kullanır. Her pod, varsayılan olarak bir default ServiceAccount'a bağlanır, ancak kendi ServiceAccount'ınızı oluşturup podunuza atamanız en iyi uygulamadır. Daha sonra, bu ServiceAccount'a belirli Role'ler veya ClusterRole'ler bağlayarak uygulamanızın ihtiyaç duyduğu yetkileri verirsiniz. Bu, uygulamalarınızın sadece gerekli ayrıcalıklara sahip olmasını sağlar ve uygulamalar arası yetki kaçaklarını önler.

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-ns
  name: my-app-service-account

Ardından bu ServiceAccount'a özel bir RoleBinding oluşturulur.

RBAC Denetimi ve Gözetimi

RBAC politikalarınızın doğru çalıştığından ve istenmeyen bir yetki verilmediğinden emin olmak için düzenli denetimler yapın. kubectl auth can-i komutu, anlık kontroller için mükemmeldir. Ayrıca, kümenizin audit loglarını (denetim kayıtlarını) etkinleştirerek ve düzenli olarak inceleyerek, kimin hangi işlemi ne zaman gerçekleştirdiğini izleyebilirsiniz. Bu, güvenlik olaylarını tespit etmek ve kök neden analizini yapmak için kritik öneme sahiptir.

Yetki Yükseltme Saldırılarını Önleme

RBAC politikalarınızı tasarlarken, yetki yükseltme saldırılarını dikkate alın. Örneğin, bir kullanıcının RoleBinding oluşturma yetkisi varsa, kendisine cluster-admin ClusterRole'ünü bağlayarak kümede tam yetki kazanabilir. Bu tür saldırıları önlemek için, RoleBinding veya ClusterRoleBinding oluşturma yetkisini yalnızca çok güvendiğiniz yöneticilere verin ve bu yetkinin kapsamını sınırlayın. Kaynakları verbs: ["*"] ile yetkilendirmek yerine, mümkün olduğunca spesifik fiiller kullanın.

Bu ileri düzey konular ve en iyi uygulamalar, Kubernetes RBAC yönetimini daha güçlü, daha güvenli ve daha yönetilebilir hale getirmenize yardımcı olacaktır. Unutmayın, güvenlik dinamik bir süreçtir ve RBAC politikalarınızın sürekli olarak gözden geçirilmesi ve güncellenmesi gerekir.

Sıkça Sorulan Sorular: Kubernetes RBAC Hakkında Merak Edilenler

Kubernetes RBAC, küme güvenliğinin temelini oluşturur ve doğru anlaşıldığında çok güçlü bir araçtır. Ancak bu karmaşık konu hakkında sıkça sorulan bazı sorular olabilir. İşte onlardan birkaçı ve cevapları:

• RBAC neden ABAC'tan daha iyidir?

  RBAC (Rol Tabanlı Erişim Kontrolü), ABAC'a (Nitelik Tabanlı Erişim Kontrolü) göre önemli avantajlara sahiptir. ABAC, politikaları karmaşık ve okunması zor JSON dosyaları olarak tanımlarken, RBAC daha deklaratif ve insan tarafından okunabilir YAML tanımlamaları kullanır. RBAC'ın modüler yapısı (Roller ve Rol Bağlamaları), politikaların daha kolay yönetilmesini, ölçeklendirilmesini ve denetlenmesini sağlar. Ayrıca, ABAC'ın aksine RBAC, Kubernetes API'si tarafından yerel olarak desteklenir ve küme içindeki kaynakları doğal olarak entegre eder. Bu özellikler, RBAC'ı modern Kubernetes yetkilendirmesi için tercih edilen ve standart hale gelen yöntem yapar, böylece geliştirme ve operasyonel süreçlerde çok daha esneklik ve güvenlik sunar.

• ClusterRole kullanırken nelere dikkat etmeliyim?

  ClusterRole'ler, küme genelinde yetkiler tanımladığı için dikkatli kullanılmalıdır. Bir ClusterRole, tüm namespace'lerde veya namespace'e bağlı olmayan kaynaklar üzerinde (Node'lar, PersistentVolume'lar gibi) yetki verir. Bu nedenle, ClusterRole'leri olabildiğince spesifik tutmalı ve yalnızca gerçekten küme genelinde yetkiye ihtiyaç duyan durumlarda kullanmalısınız. Aşırı geniş yetkilere sahip ClusterRole'ler, güvenlik risklerini artırabilir. Bir ClusterRole'ü bir RoleBinding ile belirli bir namespace'e bağlayarak, ClusterRole'ün yetkilerini daha dar bir kapsamda kullanabilirsiniz. Bu, esneklik sağlarken, potansiyel riskleri azaltmaya yardımcı olur.

• Bir kullanıcının hangi yetkilere sahip olduğunu nasıl kontrol ederim?

  Bir kullanıcının (veya servis hesabının/grubunun) belirli bir namespace'te veya küme genelinde hangi yetkilere sahip olduğunu kontrol etmek için kubectl auth can-i komutunu kullanabilirsiniz. Örneğin:

  
  kubectl auth can-i create pods --namespace my-app-ns --as alice
  kubectl auth can-i delete nodes --as bob --as-group cluster-admins
          

  
  Bu komut, belirli bir eylemin (create pods, delete nodes) belirli bir kimlik (alice, bob ve cluster-admins grubu) tarafından gerçekleştirilip gerçekleştirilemeyeceğini yes veya no olarak döndürür. Daha kapsamlı bir yetki listesi görmek için kubectl auth reconcile -f veya üçüncü taraf araçları (örneğin rbac-manager) kullanabilirsiniz.

• Role ve RoleBinding silinirse ne olur?

  Bir Role silindiğinde, o Role'e atıfta bulunan tüm RoleBindingler ve ClusterRoleBindingler geçersiz hale gelir. Yani, bu bağlamalar aracılığıyla yetki almış subject'ler artık yetkilerini kaybeder. RoleBinding veya ClusterRoleBinding silinirse, ilgili subject'ler artık o Role'ün veya ClusterRole'ün tanımladığı yetkilere sahip olamazlar. Bu, yetkilendirme politikalarınızı güncellerken veya geri alırken dikkatli olmanız gerektiği anlamına gelir. Silme işlemleri, kullanıcının erişimini anında etkileyeceği için dikkatli bir planlama gerektirir.

• Servis hesapları neden önemlidir?

  Servis hesapları (ServiceAccounts), Kubernetes kümesi içinde çalışan uygulamaların kendilerini kimlik doğrulaması ve Kubernetes API'si ile etkileşim kurması için kullanılan özel kimliklerdir. İnsan kullanıcıları için kullanılan hesaplardan farklıdırlar. Uygulamaların genellikle doğrudan küme API'si ile etkileşime girmesi gerektiğinden, her uygulamanın belirli ve sınırlı yetkilere sahip kendi ServiceAccount'ına sahip olması önemlidir. Bu, uygulamaların sadece ihtiyaç duydukları kaynaklara erişmesini sağlar ve güvenlik ihlali durumunda yetkisiz erişimin kapsamını sınırlar. Default ServiceAccount kullanmaktan kaçınarak, her uygulama için özel ServiceAccount'lar ve bunlara bağlı RoleBinding'ler oluşturmak en iyi güvenlik uygulamasıdır.