RoleBindings einrichten

Kubernetes steuert Zugriffsrechte über Role Based Access Control (RBAC). Damit begrenzen Sie, welche Benutzer und Anwendungen welche Ressourcen lesen oder verändern dürfen.

Voraussetzungen

• Ein Kubernetes Cluster im Status Running und eine geprüfte Verbindung per kubectl

Die vier Objekttypen

Objekt	Geltungsbereich	Zweck
Role	Ein Namespace	Definiert Rechte innerhalb eines Namespace
ClusterRole	Gesamtes Cluster	Definiert clusterweite Rechte
RoleBinding	Ein Namespace	Weist eine Role oder ClusterRole innerhalb eines Namespace zu
ClusterRoleBinding	Gesamtes Cluster	Weist eine ClusterRole clusterweit zu

Rechte werden ausschließlich additiv vergeben: Es gibt keine verbietenden Regeln. Was nicht ausdrücklich erlaubt ist, ist untersagt.

Tipp

Ein RoleBinding kann auch eine ClusterRole referenzieren. Die darin definierten Rechte gelten dann nur innerhalb des Namespace des Bindings. So verwenden Sie vordefinierte Rollen wie view oder edit namespace-begrenzt, ohne eigene Rollen zu schreiben.

Vordefinierte ClusterRoles

Kubernetes bringt Rollen mit, die die meisten Anwendungsfälle abdecken:

ClusterRole	Rechte
view	Lesender Zugriff auf die meisten Ressourcen, ohne Secrets
edit	Lesen und Ändern der meisten Ressourcen, ohne RBAC-Objekte
admin	Vollzugriff innerhalb eines Namespace inklusive RBAC
cluster-admin	Uneingeschränkter Zugriff auf das gesamte Cluster

Rechte für einen ServiceAccount

Anwendungen im Cluster authentifizieren sich über einen ServiceAccount. Standardmäßig hat dieser nahezu keine Rechte – das ist beabsichtigt.

1. ServiceAccount anlegen

kubectl create serviceaccount app-sa -n produktion

2. Role mit den benötigten Rechten definieren

Vergeben Sie nur die Rechte, die die Anwendung tatsächlich benötigt:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-leser
  namespace: produktion
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]

Gängige Verben sind get, list, watch, create, update, patch und delete.

3. Role zuweisen

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-sa-configmap-leser
  namespace: produktion
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: produktion
roleRef:
  kind: Role
  name: configmap-leser
  apiGroup: rbac.authorization.k8s.io

Anwenden:

kubectl apply -f rbac.yaml

4. ServiceAccount im Deployment verwenden

    spec:
      serviceAccountName: app-sa
      containers:
        - name: app
          image: registry.example.com/app:1.0

Lesenden Zugriff auf einen Namespace vergeben

Für Personen, die einen Namespace nur einsehen sollen, genügt die vordefinierte ClusterRole view:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-lesezugriff
  namespace: produktion
subjects:
  - kind: User
    name: entwickler@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Rechte prüfen

Mit kubectl auth can-i prüfen Sie, ob eine bestimmte Aktion erlaubt ist:

# Eigene Rechte prüfen
kubectl auth can-i create deployments -n produktion

# Rechte eines ServiceAccounts prüfen
kubectl auth can-i list configmaps \
  --as=system:serviceaccount:produktion:app-sa \
  -n produktion

# Alle Rechte eines ServiceAccounts auflisten
kubectl auth can-i --list \
  --as=system:serviceaccount:produktion:app-sa \
  -n produktion

Bestehende Bindings einsehen:

kubectl get rolebindings -n produktion
kubectl get clusterrolebindings
kubectl describe rolebinding app-sa-configmap-leser -n produktion

Empfehlungen

• Vergeben Sie Rechte nach dem Prinzip der geringsten Berechtigung – beginnen Sie restriktiv und ergänzen Sie gezielt.
• Verwenden Sie Role und RoleBinding statt clusterweiter Objekte, wenn die Rechte auf einen Namespace begrenzt werden können.
• Vergeben Sie cluster-admin nur an administrative Konten, niemals an Anwendungen.
• Achten Sie besonders auf Rechte an secrets: Wer diese lesen darf, sieht alle darin hinterlegten Zugangsdaten im Klartext.
• Legen Sie je Anwendung einen eigenen ServiceAccount an, statt den default-ServiceAccount zu verwenden.

Verwandte Themen

• Sicherheit
• Best Practices