RBAC Best Practices: Kubernetes-Zugriff sicher steuern

TL;DR

Kubernetes RBAC kontrolliert, wer was in Ihrem Cluster darf. Verwenden Sie Roles statt ClusterRoles wo möglich, vermeiden Sie Wildcard-Berechtigungen und erstellen Sie dedizierte ServiceAccounts für CI/CD-Pipelines. Testen Sie Berechtigungen mit kubectl auth can-i bevor Sie Rollen produktiv einsetzen. Zu breite ClusterRoleBindings sind das häufigste RBAC-Sicherheitsproblem.

Grundlagen: Die vier RBAC-Ressourcen

RBAC in Kubernetes basiert auf vier Ressourcentypen. Bevor Sie Rollen definieren, müssen Sie den Unterschied verstehen:

# Schnell prüfen, ob RBAC aktiv ist
kubectl api-versions | grep rbac.authorization.k8s.io
# Erwartete Ausgabe: rbac.authorization.k8s.io/v1

Die wichtigste Regel: Eine ClusterRole mit einem RoleBinding ergibt Namespace-scoped Berechtigungen. Eine ClusterRole mit einem ClusterRoleBinding ergibt clusterweite Berechtigungen. Der Binding-Typ entscheidet über den Scope.

Praxis: Read-Only-Rolle für Entwickler

Entwickler brauchen Einblick in ihre Anwendungen, aber keine Änderungsrechte. Diese Rolle erlaubt das Lesen von Pods, Services, Deployments und Logs:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-readonly
  namespace: entwicklung
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-readonly-binding
  namespace: entwicklung
subjects:
  - kind: Group
    name: dev-team
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-readonly
  apiGroup: rbac.authorization.k8s.io

Beachten Sie: pods/log ist eine Sub-Resource und muss separat berechtigt werden. Wer Pods lesen kann, kann nicht automatisch Logs sehen.

Praxis: Namespace-Admin für Team-Leads

Team-Leads sollen innerhalb ihres Namespaces alles verwalten dürfen, aber keinen Zugriff auf andere Namespaces oder clusterweite Ressourcen haben:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: namespace-admin
  namespace: team-alpha
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["*"]
    verbs: ["*"]
  - apiGroups: [""]
    resources: ["resourcequotas", "limitranges"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-binding
  namespace: team-alpha
subjects:
  - kind: User
    name: max.mustermann@firma.de
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: namespace-admin
  apiGroup: rbac.authorization.k8s.io

Hier wird ein Wildcard (*) für Resources und Verbs verwendet -- aber nur innerhalb eines Namespaces und nur für definierte API-Gruppen. ResourceQuotas und LimitRanges bleiben read-only, damit Admins nicht versehentlich Cluster-Limits aushebeln.

Praxis: CI/CD ServiceAccount mit minimalen Rechten

CI/CD-Pipelines brauchen einen dedizierten ServiceAccount. Der häufigste Fehler: cluster-admin für Jenkins oder ArgoCD vergeben.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: produktion
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deploy-role
  namespace: produktion
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["services", "configmaps"]
    verbs: ["get", "list", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments/scale"]
    verbs: ["patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deploy-binding
  namespace: produktion
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: produktion
roleRef:
  kind: Role
  name: ci-deploy-role
  apiGroup: rbac.authorization.k8s.io

Der ServiceAccount kann Deployments updaten und skalieren, aber keine neuen erstellen und keine Secrets lesen. Das ist Least Privilege.

Berechtigungen testen mit kubectl auth can-i

Testen Sie jede Rolle bevor Sie sie produktiv einsetzen:

# Als spezifischer User prüfen
kubectl auth can-i get pods --namespace=entwicklung --as=max.mustermann@firma.de
# yes

kubectl auth can-i delete pods --namespace=entwicklung --as=max.mustermann@firma.de
# no

# Als ServiceAccount prüfen
kubectl auth can-i update deployments --namespace=produktion \
  --as=system:serviceaccount:produktion:ci-deployer
# yes

kubectl auth can-i get secrets --namespace=produktion \
  --as=system:serviceaccount:produktion:ci-deployer
# no

# Alle Berechtigungen eines Users auflisten
kubectl auth can-i --list --namespace=entwicklung --as=max.mustermann@firma.de

Integrieren Sie kubectl auth can-i in Ihre CI-Pipeline als Smoke-Test nach RBAC-Änderungen.

Die fünf häufigsten RBAC-Fehler

1. ClusterRoleBinding statt RoleBinding verwenden Ein ClusterRoleBinding auf cluster-admin gibt vollen Zugriff auf alle Namespaces. Verwenden Sie RoleBindings, um ClusterRoles auf einzelne Namespaces einzuschränken.

2. Wildcard-Berechtigungen auf Cluster-Ebene resources: ["*"] mit verbs: ["*"] in einer ClusterRole ist praktisch cluster-admin. Listen Sie Ressourcen und Verbs explizit auf.

3. Default ServiceAccount verwenden Jeder Namespace hat einen default ServiceAccount. Wenn Sie keinen eigenen definieren, nutzen alle Pods diesen Account. Erstellen Sie dedizierte ServiceAccounts pro Workload.

4. Secrets-Zugriff zu breit vergeben Wer Secrets lesen kann, hat Zugriff auf Passwörter, API-Keys und TLS-Zertifikate. Berechtigen Sie secrets nur wenn zwingend nötig und nur in den relevanten Namespaces.

5. RBAC-Konfiguration nicht auditieren Ohne regelmäßige Überprüfung wachsen Berechtigungen über die Zeit. Nutzen Sie Tools wie kubectl-who-can oder rakkess für RBAC-Audits.

# Wer kann Secrets im Namespace lesen?
kubectl-who-can get secrets -n produktion

# Alle Berechtigungen im Cluster visualisieren
kubectl get clusterrolebindings -o wide | grep -v "system:"

FAQ

Was ist der Unterschied zwischen Role und ClusterRole?

Eine Role gilt nur in einem Namespace. Eine ClusterRole gilt clusterweit oder kann per RoleBinding auf einen Namespace eingeschränkt werden. ClusterRoles sind außerdem für clusterweite Ressourcen wie Nodes oder PersistentVolumes nötig.

Kann ich RBAC-Rollen über mehrere Namespaces wiederverwenden?

Ja. Definieren Sie eine ClusterRole und binden Sie sie per RoleBinding in jedem Namespace einzeln. So haben Sie eine zentrale Rollendefinition mit Namespace-spezifischer Zuweisung.

Wie finde ich überprivilegierte ServiceAccounts?

Nutzen Sie kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:NAME für jeden ServiceAccount. Tools wie rakkess oder rbac-lookup automatisieren diese Analyse clusterüberweit.

Soll ich Users oder Groups in RoleBindings verwenden?

Bevorzugen Sie Groups. Wenn ein Teammitglied wechselt, ändern Sie die Gruppenmitgliedschaft in Ihrem Identity Provider statt einzelne RoleBindings anzupassen. Das skaliert besser und ist weniger fehleranfällig.

Wie verhindere ich Privilege Escalation über RBAC?

Kubernetes hat eingebauten Schutz: Ein User kann nur Rollen mit Berechtigungen vergeben, die er selbst besitzt. Achten Sie darauf, dass niemand außer Cluster-Admins bind- und escalate-Verbs auf Rollen hat.

Fazit

RBAC ist kein Feature, das Sie einmal konfigurieren und vergessen. Starten Sie mit restriktiven Rollen, testen Sie mit kubectl auth can-i und auditieren Sie regelmäßig. Die Investition in saubere RBAC-Konfiguration zahlt sich beim ersten Sicherheitsvorfall aus -- weil der Blast Radius begrenzt bleibt.