Kubernetes RBAC: En Az Ayrıcalık İlkesiyle Küme Erişimini Güvenli Hale Getirin

Kubernetes kümelerinin yönetiminde en önemli güvenlik adımlarından biri, kullanıcıların yalnızca ihtiyaç duydukları erişimi almasını sağlamaktır. Bu noktada Kubernetes RBAC (Role-Based Access Control) devreye giriyor. RBAC, kullanıcıların yalnızca görevlerine uygun izinlere sahip olmasını sağlayarak, küme güvenliğini artırıyor ve potansiyel tehditleri minimize ediyor.

Kubernetes RBAC ile Erişim Yönetiminin Temel Prensipleri

Kubernetes’in RBAC sistemi, API sunucusu düzeyinde çalışarak her kubectl komutunu veya doğrudan API çağrısını dört temel bileşene ayırır: kullanıcı, eylem (verb), kaynak (resource) ve ad alanını (namespace). Sistem, kullanıcıların erişim taleplerini değerlendirirken RoleBinding veya ClusterRoleBinding kurallarını kontrol eder. Örneğin, bir kullanıcı kubectl get pods komutunu çalıştırdığında, sistem önce kimlik doğrulamasını yapar, ardından RBAC motoru aracılığıyla yetkilendirmeyi gerçekleştirir.

RBAC’in en önemli avantajlarından biri, politika tanımlarının (Role) erişim atamalarından (RoleBinding) ayrılmasıdır. Buradaki temel kural şudur: Roller yalnızca belirli bir ad alanına uygulanırken, ClusterRoller küme genelinde geçerlidir. Bu ayrım, gereksiz yere geniş yetkilerin kullanılmasını önleyerek güvenliği artırır.

Aşağıda, production ad alanında yalnızca Pod ve Servis kaynaklarına okuma erişimi sağlayan bir Role örneği yer alıyor:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-okuyucu
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

Bu tanımlama, erişim politikasını belirler ancak kullanıcıya doğrudan erişim sağlamaz. Erişimin verilmesi için bir RoleBinding oluşturulması gerekir. Örneğin, alice@example.com kullanıcısına bu rolü atamak için aşağıdaki gibi bir RoleBinding kullanılır:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-pod-okuyucu
  namespace: production
subjects:
- kind: User
  name: alice@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-okuyucu
  apiGroup: rbac.authorization.k8s.io

Uygulandıktan sonra erişim doğrulanabilir:

kubectl apply -f rol.yaml
kubectl get pods -n production --as alice@example.com

Aynı kullanıcı, farklı bir ad alanına erişmeye çalıştığında hata alır:

kubectl get pods -n staging --as alice@example.com
# Hata: pods listesi engellendi — kullanıcı staging ad alanında pods listesini görüntüleyemez

En Az Ayrıcalık İlkesini Uygularken İzlenmesi Gereken Adımlar

RBAC politikaları oluştururken en önemli kural, kullanıcılara yalnızca görevleri için gerekli olan izinleri vermektir. Bu süreçte dikkat edilmesi gereken unsurlar şunlardır:

• Gerekli kaynakların belirlenmesi: Hangi Kubernetes kaynaklarına erişim gerektiği (örneğin, deployments, pods, services)
• Eylemlerin sınırlandırılması: Kullanıcıların hangi eylemleri gerçekleştirebileceği (get, create, patch, delete)
• Ad alanlarının daraltılması: Erişimin yalnızca gerekli ad alanlarında sınırlandırılması

Örneğin, bir CI/CD boru hattının staging ad alanına dağıtım yaparken yalnızca şu izinlere ihtiyacı vardır:

• deployments üzerinde get, update, patch eylemleri
• pods üzerinde create ve delete eylemleri
• secrets üzerinde get eylemi

Bu gereksinimlere uygun olarak aşağıdaki gibi bir Role tanımlanabilir:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: staging
  name: ci-dağıtıcı
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]

Bu rol, GitHub Actions tarafından kullanılan bir hizmet hesabına bağlanabilir. Bu yaklaşım, rollerin kullanıcılardan bağımsız olarak işlevsel sorumluluklara göre tanımlanmasını sağlar.

Sadece Okuma Yetkisine Sahip Geliştirici Rolü Örneği

Geliştiricilerin küme üzerinde hata ayıklaması gerektiğinde, ancak kaynakları değiştirmemesi gerektiği durumlar sıkça karşılaşılan senaryolardandır. Bu tür durumlarda, yalnızca okuma yetkisine sahip bir rol oluşturmak en güvenli yaklaşımdır. Aşağıdaki örnek, dev-team-alpha ad alanında yalnızca okuma erişimi sağlayan bir rol tanımlar:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-alpha
  name: geliştirici-okuyucu
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasetler"]
  verbs: ["get", "list", "watch"]

Bu rol, tüm geliştirici ekibine grup düzeyinde atanabilir:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ekip-geliştirici-okuyucu
  namespace: dev-team-alpha
subjects:
- kind: Group
  name: dev-team-alpha@company.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: geliştirici-okuyucu
  apiGroup: rbac.authorization.k8s.io

Bu yapılandırma sayesinde ekip üyeleri kubectl logs, describe ve get komutlarını kullanabilirken, konteynerlere exec yapamaz veya kaynakları silemezler.

Alt Kaynaklara Erişimde Karşılaşılan Yaygın Sorunlar ve Çözümleri

Kubernetes’te bazı işlemler, kaynak düzeyinde değil alt kaynak düzeyinde gerçekleşir. Örneğin, kubectl logs komutu, pods/log alt kaynağına erişim gerektirir. Eğer bir rol yalnızca pods üzerindeki get eylemi için izin veriyorsa, loglara erişim başarısız olur:

kubectl logs api-7689b7b8d5-2xklp -n dev-team-alpha --as geliştirici
# Hata: pods/log kaynağına erişim engellendi

Bu sorunun çözümü, alt kaynağa özel izinlerin tanımlanmasıdır:

- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

RBAC politikaları oluştururken alt kaynaklara ve özel eylem türlerine dikkat etmek, beklenmedik erişim hatalarının önüne geçilmesini sağlar.

Sonuç: RBAC ile Küme Güvenliğini En Üst Düzeye Çıkarın

Kubernetes kümelerinde güvenlik, yalnızca küme yöneticilerinin değil, tüm kullanıcıların sorumluluğundadır. RBAC politikalarını tasarlarken en az ayrıcalık ilkesini benimsemek, hem güvenliği artırır hem de potansiyel tehditleri minimize eder. Roller ve bağlamaların (bindings) doğru şekilde yapılandırılması, kullanıcıların yalnızca görevleri için gerekli olan kaynaklara erişmesini sağlar.

Günümüzde birçok kuruluş, gereksiz yere geniş yetkiler vererek riskleri artırıyor. RBAC’in sunduğu esneklik ve kontrol mekanizmaları sayesinde, kümelerinizi daha güvenli ve yönetilebilir hale getirebilirsiniz. Gelecekte Kubernetes ortamlarınızda RBAC politikalarını sürekli olarak gözden geçirerek, güvenlik standartlarınızı yükseltmeye devam edin.