Kubernetes RoleBinding: Rollen im Namespace zuweisen – einfach erklärt

Ein RoleBinding ist das RBAC-Objekt in Kubernetes, das eine Role oder ClusterRole an Subjekte bindet – beschränkt auf einen Namespace. Es beantwortet die Frage: Wer darf in diesem Namespace was tun?

Subjekte und roleRef

Ein RoleBinding besteht aus zwei Teilen: subjects (User, Gruppen oder ServiceAccounts) und roleRef (der Verweis auf Role oder ClusterRole). Das Feld roleRef mit apiGroup: rbac.authorization.k8s.io ist unveränderlich: Soll eine Bindung eine andere Rolle bekommen, muss das RoleBinding gelöscht und neu angelegt werden.

Beispiel

Der folgende Befehl gibt dem User bob im Namespace default die Standardrolle admin (eine ClusterRole, hier aber nur im Namespace wirksam):

kubectl create rolebinding bob-admin --clusterrole=admin --user=bob --namespace=default

Als YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bob-admin
  namespace: default
subjects:
- kind: User
  name: bob
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

ClusterRole im RoleBinding

Verweist ein RoleBinding auf eine ClusterRole, werden nur die Namespace-Ressourcen dieser Rolle im eigenen Namespace gewährt – clusterweite Ressourcen wie Nodes oder Namespaces bleiben gesperrt. So lässt sich eine einmal definierte ClusterRole (etwa view) in vielen Namespaces wiederverwenden, ohne sie zu duplizieren.

Abgrenzung

Ein ClusterRoleBinding wirkt dagegen über den gesamten Cluster: Es bindet eine ClusterRole in allen Namespaces und schaltet zusätzlich clusterweite Ressourcen frei. Wer Rechte nur für ein Team-Projekt braucht, sollte ein RoleBinding verwenden (Least Privilege).

Verwandte Grundlagen: Kubernetes RBAC, Kubernetes, kubectl-Befehle.