Kubernetes Role: Berechtigungen bündeln – einfach erklärt

Eine Role ist in Kubernetes ein Regelwerk, das Berechtigungen bündelt – für Aktionen an Ressourcen innerhalb eines einzelnen Namespace. Zusammen mit der ClusterRole, RoleBinding und ClusterRoleBinding bildet sie das Grundgerüst von RBAC.

Was eine Role darf – und was nicht

Eine Role gilt nur in ihrem eigenen Namespace. Sie kann Rechte an Pods, Deployments, Services, Secrets oder ConfigMaps dieses Namespace vergeben, aber nicht an clusterweite Ressourcen wie Nodes oder PersistentVolumes. Dafür ist die ClusterRole zuständig, die dieselbe Struktur besitzt, aber ohne Namespace-Bindung wirkt.

Eine Role definiert lediglich die Rechte. Wirksam wird sie erst, wenn eine RoleBinding sie einem Subjekt zuordnet – einem Nutzer, einer Gruppe oder einem ServiceAccount. Wird die Role später geändert, gilt die Änderung automatisch für alle Bindings.

Typische Felder

rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  • apiGroups: API-Gruppe der Ressource – leer ("") für Core-Ressourcen wie Pods, apps für Deployments, batch für Jobs.
  • resources: die Ressourcenarten, auch mit Unterressourcen wie pods/log oder deployments/scale.
  • verbs: erlaubte Aktionen – get/list/watch (lesen), create/update/patch/delete (schreiben), deletecollection (alles löschen).

Optional schränkt resourceNames die Rechte auf einzelne benannte Objekte ein – etwa nur das Secret db-passwort lesen zu dürfen.

Beispiel: Secrets nur für einen Dienst

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: produktion
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
  resourceNames: ["db-passwort"]

Diese Role erlaubt ausschließlich das Lesen eines einzigen Secrets. Sie wird dann per RoleBinding an den ServiceAccount der Anwendung gebunden – ein Musterbeispiel für Least Privilege.

Verwandte Konzepte

  • ClusterRole: clusterweit oder als Vorlage für mehrere Namespaces (z. B. die eingebaute cluster-admin).
  • RoleBinding: verbindet Role/ClusterRole mit Subjekten im Namespace.
  • ClusterRoleBinding: verbindet eine ClusterRole clusterweit.

Mit kubectl create role pod-reader --verb=get,list,watch --resource=pods -n default lässt sich eine Role direkt anlegen; die Sicht auf die eigenen Rechte gibt kubectl auth can-i --list. Das Gesamtsystem aus Rollen und Bindings erklärt der Artikel Kubernetes RBAC, die Identität für Pods der Beitrag Kubernetes ServiceAccount.