case-rbac

Kubernetes'te salt okunur rol: Secret yok, exec yok, değişiklik yok

Ekiplerin pod ve loglarını görebildiği ama Secret okuyamadığı, exec yapamadığı ve hiçbir şeyi değiştiremediği bir Kubernetes RBAC rolü tasarlamak.

  • Kubernetes
  • RBAC
  • Rancher
  • güvenlik

Ekipler kendi uygulamalarının durumunu görebilmeli: pod çalışıyor mu, kaç replika var, log ne diyor? Ama bunu görebilmek için cluster-admin ya da edit rolü vermek, aynı kişiye Secret'ları okuma, container içine girme ve canlı ortamı değiştirme yetkisi de vermek demektir.

Varsayılan view rolü yetmez mi?

Kubernetes'in hazır view ClusterRole'ü iyi bir başlangıçtır ve Secret okumaya izin vermez. Yine de kendi rolünüzü yazmanın iki avantajı var: neye izin verdiğinizi tek bakışta görürsünüz ve ihtiyaç duyulmayan kaynakları (ör. ConfigMap) bilinçli olarak dışarıda bırakabilirsiniz.

Rol

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: team-readonly
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "endpoints", "events", "namespaces"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["batch"]
    resources: ["jobs", "cronjobs"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch"]

Burada olmayanlar en az olanlar kadar önemli:

  • secrets yok. Uygulama parolaları ve token'lar görünmez.
  • pods/exec, pods/attach, pods/portforward yok. Container içine girilemez.
  • create, update, patch, delete fiilleri yok. Hiçbir şey değiştirilemez.

Bağlama

Rolü küme genelinde değil, ekibin namespace'inde bağlamak daha güvenlidir:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-readonly
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: team-readonly
  apiGroup: rbac.authorization.k8s.io

Rancher kullanıyorsanız aynı kuralları özel bir proje rolü olarak tanımlayıp ekibe proje seviyesinde atayabilirsiniz. Mantık aynıdır.

Doğrulama

Yetkiyi tahmin etmeyin, test edin. kubectl auth can-i ile kullanıcıyı taklit ederek kontrol edin:

kubectl auth can-i list pods        -n team-a [email protected] --as-group=team-a-developers   # yes
kubectl auth can-i get pods/log     -n team-a [email protected] --as-group=team-a-developers   # yes
kubectl auth can-i get secrets      -n team-a [email protected] --as-group=team-a-developers   # no
kubectl auth can-i create pods/exec -n team-a [email protected] --as-group=team-a-developers   # no
kubectl auth can-i delete pods      -n team-a [email protected] --as-group=team-a-developers   # no

Ders

Görünürlük ile yetki aynı şey değil. Ekipler ihtiyaç duydukları her şeyi görebilir; Secret, exec ve değişiklik ise ayrı, gerekçeli ve kayıtlı bir yetki olarak kalır.

Kurum ve ortam bilgileri çıkarılmış, komut ve yapılandırma örnekleri genelleştirilmiştir. Kendi ortamınızda önce test edin.

Bu not, sitedeki vaka dosyalarından birinin uzun hâlidir. Taslağı Claude ile hazırlandı.

ls ~/notlar

Diğer notlar

Tüm notlar

Bir altyapı sorusu, proje ya da rota önerisi mi var?

En hızlı yol e-posta. Seyahatteysem bir sonraki Wi-Fi'da dönerim.

E-posta gönder