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.
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:
secretsyok. Uygulama parolaları ve token'lar görünmez.pods/exec,pods/attach,pods/portforwardyok. Container içine girilemez.create,update,patch,deletefiilleri 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.