Kubernetes RBAC: Rol Tabanlı Erişim Kontrolü Detayları

1. Role (Rol)

Bir **Role**, belirli bir `namespace` (ad alanı) içinde izinler kümesini tanımlar. Yalnızca bu ad alanı içindeki kaynaklara uygulanabilecek eylemleri belirtir. Örneğin, bir Role sadece `default` namespace'indeki Pod'ları listeleme izni verebilir. Rollerin kapsamı her zaman ad alanı ile sınırlıdır.

Örnek YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development # Bu rol sadece 'development' namespace'inde geçerlidir
  name: pod-okuyucu
rules: # İzinlerin listesi
- apiGroups: [""] # "" core API grubunu ifade eder (Pod, Service vb.)
  resources: ["pods", "pods/log"] # "pods" ve "pods/log" kaynaklarına izin ver
  verbs: ["get", "watch", "list"] # "get", "watch", "list" eylemlerine izin ver
                

2. ClusterRole (Küme Rolü)

Bir **ClusterRole**, küme genelinde (namespacesiz) veya küme kapsamındaki kaynaklar (düğümler gibi) üzerinde izinler kümesini tanımlar. Ayrıca tüm ad alanlarındaki belirli kaynak türlerine izin vermek için de kullanılabilir. ClusterRole'lar genellikle küme yöneticileri tarafından, küme düzeyinde yönetim görevleri veya tüm ad alanlarında uygulanması gereken politikalar için oluşturulur.

Örnek YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-okuyucu # Bu rol küme genelinde geçerlidir
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["extensions", "apps"] # Deployment'lar gibi kaynaklar için
  resources: ["deployments"]
  verbs: ["list"] # Tüm ad alanlarındaki deployment'ları listeleme izni
                

3. RoleBinding (Rol Bağlama)

Bir **RoleBinding**, bir `Role`'de tanımlanan izinleri bir veya daha fazla "konuya" (Subject: kullanıcılar, gruplar veya ServiceAccount'lar) belirli bir `namespace` içinde atar. Yani, bir RoleBinding, bir Rolü kimin kullanabileceğini ve hangi ad alanında kullanabileceğini belirtir.

Örnek YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-pod-okuyucu-binding
  namespace: development # Bu bağlama 'development' namespace'inde geçerlidir
subjects: # İzin verilecek konular
- kind: User # Konu tipi: Kullanıcı
  name: developer-ali # Kullanıcı adı
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount # Konu tipi: Servis Hesabı
  name: ci-cd-sa # Servis Hesabı adı
  namespace: ci-cd-namespace # Servis Hesabının ait olduğu namespace
roleRef: # Hangi Role'e bağlanıldığı
  kind: Role
  name: pod-okuyucu # Yukarıda tanımlanan 'pod-okuyucu' Role'e referans
  apiGroup: rbac.authorization.k8s.io
                

4. ClusterRoleBinding (Küme Rolü Bağlama)

Bir **ClusterRoleBinding**, bir `ClusterRole`'de tanımlanan izinleri bir veya daha fazla "konuya" (kullanıcılar, gruplar veya ServiceAccount'lar) **küme genelinde** atar. ClusterRoleBinding'ler `namespace`'e bağlı değildir ve ClusterRole'un küme genelindeki izinlerini tüm konulara uygular.

Örnek YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tum-node-okuyucular
subjects:
- kind: Group # Konu tipi: Grup
  name: system:masters # Kubernetes'in varsayılan yönetici grubu
  apiGroup: rbac.authorization.k8s.io
- kind: User
  name: admin-veli
  apiGroup: rbac.authorization.k8s.io
roleRef: # Hangi ClusterRole'e bağlanıldığı
  kind: ClusterRole
  name: node-okuyucu # Yukarıda tanımlanan 'node-okuyucu' ClusterRole'e referans
  apiGroup: rbac.authorization.k8s.io
                

5. Konular (Subjects): Kimlere İzin Verilir?

RBAC izinleri, aşağıdaki konulara atanabilir:

• **User (Kullanıcı):** Genellikle insan kullanıcıları temsil eder. Kubernetes'in yerleşik bir kullanıcı yönetimi sistemi yoktur, bu nedenle kullanıcılar harici kimlik doğrulama sistemleri (örneğin X.509 sertifikaları, OIDC) aracılığıyla kimlik doğrulaması yapılır.
• **Group (Grup):** Birden fazla kullanıcıyı bir araya getiren mantıksal bir kümedir. Kullanıcılarda olduğu gibi, gruplar da harici sistemler aracılığıyla yönetilir.
• **ServiceAccount (Servis Hesabı):** Kubernetes içinde çalışan süreçler (örneğin Pod'lar, kontrolörler) için kimlik sağlar. Kubernetes, Pod'lara otomatik olarak bir ServiceAccount atar ve bu hesaplara RBAC izinleri atanabilir. Bir Pod'un Kubernetes API'si ile etkileşime girmesi gerektiğinde kullanılır.

Bir kullanıcı veya servis (konu), Kubernetes API'sine bir istek gönderdiğinde, bu istek `kube-apiserver` tarafından işlenir. API sunucusu, isteği doğrulamadan (authentication) sonra yetkilendirme (authorization) aşamasına geçer. RBAC, bu yetkilendirme aşamasının bir parçasıdır.

Senaryo 1: Bir Geliştiriciye Belirli Bir Namespace'de Pod Yaratma İzni Verme

Bir geliştirici olan "developer-ayse"nin sadece `dev-apps` namespace'inde Pod'ları ve Deployments'ları oluşturmasına, güncellemesine, listelemesine ve silmesine izin vermek istiyoruz.

1. Role Tanımı (`dev-apps-editor-role.yaml`):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-apps # Bu rol sadece 'dev-apps' namespace'inde geçerlidir
  name: dev-apps-editor
rules:
- apiGroups: ["", "apps", "extensions"] # Core API, apps, extensions grupları
  resources: ["pods", "deployments", "services", "ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
                

2. RoleBinding Tanımı (`dev-apps-editor-binding.yaml`):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-apps-editor-binding
  namespace: dev-apps # Bu bağlama 'dev-apps' namespace'inde geçerlidir
subjects:
- kind: User
  name: developer-ayse # Kullanıcı adı
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-apps-editor # Yukarıdaki Role'e referans
  apiGroup: rbac.authorization.k8s.io
                

Uygulama:

kubectl apply -f dev-apps-editor-role.yaml
kubectl apply -f dev-apps-editor-binding.yaml
                

Artık `developer-ayse` kullanıcısı, sadece `dev-apps` namespace'i içindeki belirli kaynakları yönetebilir. Diğer namespace'lerde herhangi bir işlem yapamayacaktır.

Senaryo 2: Bir CI/CD Servis Hesabına Küme Genelinde Sadece Okuma İzni Verme

Bir CI/CD işlem hattının, küme genelindeki tüm Pod'ları ve Düğümleri okuma (listeleme, alma, izleme) iznine sahip olmasını istiyoruz.

1. ClusterRole Tanımı (`cluster-reader-role.yaml`):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reader
rules:
- apiGroups: [""] # Core API grubu
  resources: ["pods", "nodes", "services", "namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"] # Uygulama API grubu
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch"]
                

2. ServiceAccount Tanımı (`ci-cd-serviceaccount.yaml`):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-cd-viewer
  namespace: default # ServiceAccount'ın bulunacağı namespace
                

3. ClusterRoleBinding Tanımı (`cluster-reader-binding.yaml`):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ci-cd-viewer-binding
subjects:
- kind: ServiceAccount
  name: ci-cd-viewer
  namespace: default # ServiceAccount'ın namespace'i
roleRef:
  kind: ClusterRole
  name: cluster-reader # Yukarıdaki ClusterRole'e referans
  apiGroup: rbac.authorization.k8s.io
                

Uygulama:

kubectl apply -f cluster-reader-role.yaml
kubectl apply -f ci-cd-serviceaccount.yaml
kubectl apply -f cluster-reader-binding.yaml
                

Bu sayede `default` namespace'indeki `ci-cd-viewer` ServiceAccount'ı, tüm küme genelindeki Pod'lar, Düğümler ve diğer belirtilen kaynaklar üzerinde okuma izinlerine sahip olacaktır. Bu ServiceAccount, CI/CD işlem hattında kullanılabilir.

• **"Forbidden" Hataları:** Bir işlem yapmaya çalıştığınızda "Forbidden" hatası alıyorsanız, bu genellikle RBAC izninizin olmadığını gösterir. İlgili kullanıcının/ServiceAccount'ın hangi Rollere veya ClusterRollere bağlı olduğunu ve bu rollerin ihtiyaç duyulan izinleri içerip içermediğini kontrol edin.
• **`kubectl auth can-i`:** Bu komut, belirli bir kullanıcının/ServiceAccount'ın belirli bir kaynak üzerinde belirli bir eylemi yapıp yapamayacağını kontrol etmek için paha biçilmezdir. Örnek: `kubectl auth can-i create deployments --as=developer-ayse --namespace=dev-apps`
• **`kubectl get roles` / `clusterroles` / `rolebindings` / `clusterrolebindings`:** İzin yapılandırmanızı kontrol etmek için bu komutları kullanın.
• **`ServiceAccount` Kullanımı:** Pod'lar için her zaman özel `ServiceAccount`'lar oluşturun ve onlara yalnızca ihtiyaç duydukları minimum izinleri verin. Varsayılan `default` ServiceAccount'ı kullanmaktan kaçının.
• **`ServiceAccount` Token'ları:** Bir Pod içinde çalışan uygulamanızın Kubernetes API'si ile iletişim kurması gerektiğinde, Pod'un bağlandığı `ServiceAccount`'ın otomatik olarak monte edilen token'ını kullanır. Bu token'ın doğru RBAC izinlerine sahip olduğundan emin olun.
• **Audit Logları:** Kubernetes audit loglarını etkinleştirerek, küme içinde kimin ne zaman hangi işlemi yapmaya çalıştığını ve yetkilendirme kararlarını ayrıntılı olarak izleyebilirsiniz. Bu, güvenlik denetimi ve sorun giderme için kritiktir.