Kubernetes Forbidden Error: RBAC Debugging Anleitung

TL;DR

"Error from server (Forbidden): User cannot list resource" bedeutet: RBAC blockiert die Anfrage. Debuggen Sie mit kubectl auth can-i list pods --as=<user>, prüfen Sie bestehende Bindings mit kubectl get clusterrolebindings -o wide und erstellen Sie die fehlende RoleBinding oder ClusterRoleBinding.

kubectl get pods -n production
Error from server (Forbidden): pods is forbidden: User "developer@example.com" cannot list resource "pods" in API group "" in the namespace "production"

Diese Fehlermeldung sagt Ihnen exakt, was fehlt: Wer (User), was (list pods), wo (Namespace production). Damit können Sie das Problem gezielt lösen.

Schritt 1: Berechtigungen prüfen mit kubectl auth can-i

Der schnellste Weg, RBAC-Probleme zu verstehen:

# Kann der aktuelle User Pods listen?
kubectl auth can-i list pods -n production

# Als anderer User testen (Impersonation)
kubectl auth can-i list pods -n production --as=developer@example.com

# Alle Berechtigungen eines Users in einem Namespace
kubectl auth can-i --list -n production --as=developer@example.com

Die Ausgabe von --list zeigt alle erlaubten Aktionen:

Resources   Non-Resource URLs   Resource Names   Verbs
pods        []                  []               [get list watch]
services    []                  []               [get list]

Wenn die nötige Berechtigung fehlt, brauchen Sie eine Role + RoleBinding (Namespace-Level) oder eine ClusterRole + ClusterRoleBinding (Cluster-Level).

Schritt 2: Bestehende Bindings finden

Bevor Sie neue Bindings erstellen, prüfen Sie was bereits existiert:

# Alle RoleBindings in einem Namespace
kubectl get rolebindings -n production -o wide

# Alle ClusterRoleBindings (clusterweit)
kubectl get clusterrolebindings -o wide | grep developer

# Details einer RoleBinding anzeigen
kubectl describe rolebinding developer-binding -n production

RBAC-Hierarchie verstehen

Ressource	Scope	Beschreibung
Role	Namespace	Definiert Berechtigungen in einem Namespace
ClusterRole	Cluster	Definiert Berechtigungen clusterweit
RoleBinding	Namespace	Verbindet Role/ClusterRole mit User in einem Namespace
ClusterRoleBinding	Cluster	Verbindet ClusterRole mit User clusterweit

Ein häufiges Missverständnis: Eine ClusterRole kann über eine RoleBinding an einen Namespace gebunden werden. Das ist sogar Best Practice -- Sie definieren die Rolle einmal und binden sie pro Namespace.

Schritt 3: Fehlende Berechtigungen erstellen

Beispiel: Developer darf Pods lesen in einem Namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-pod-reader
  namespace: production
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f developer-rbac.yaml

# Sofort testen
kubectl auth can-i list pods -n production --as=developer@example.com
# Erwartete Ausgabe: yes

Beispiel: ServiceAccount für CI/CD Pipeline

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cicd-deployer
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "update", "patch"]
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cicd-deployer-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: cicd-deployer
    namespace: production
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Typische Forbidden-Fehler und ihre Lösungen

"cannot list resource 'nodes'"

Nodes sind clusterweite Ressourcen. Hier brauchen Sie eine ClusterRoleBinding, keine RoleBinding:

kubectl create clusterrolebinding node-viewer \
  --clusterrole=system:node-reader \
  --user=developer@example.com

"cannot create resource 'deployments' in API group 'apps'"

Der User hat eventuell Rechte auf die Core API Group (""), aber nicht auf die apps API Group. Prüfen Sie die apiGroups in der Role:

# Welche API Group braucht die Ressource?
kubectl api-resources | grep deployments
# Ausgabe: deployments   deploy   apps/v1   true   Deployment

ServiceAccount Token fehlt

Ab Kubernetes 1.24 werden keine automatischen Secret-Tokens mehr für ServiceAccounts erstellt. Für Anwendungen, die ein langlebiges Token brauchen:

apiVersion: v1
kind: Secret
metadata:
  name: cicd-deployer-token
  namespace: production
  annotations:
    kubernetes.io/service-account.name: cicd-deployer
type: kubernetes.io/service-account-token

Audit Log: Wer hat was versucht?

Wenn Sie nachvollziehen wollen, welche RBAC-Fehler im Cluster auftreten:

# Audit Policy für RBAC-Fehler (kube-apiserver Konfiguration)
# Suchen Sie nach "Forbidden" in den API Server Logs
kubectl logs -n kube-system -l component=kube-apiserver --tail=100 \
  | grep -i forbidden

Für produktive Cluster empfiehlt sich ein Audit-Webhook, der Forbidden-Events an ein zentrales Logging-System sendet.

RBAC-Debugging mit kubectl-Plugins

Das kubectl-Plugin kubectl-who-can zeigt, welche Subjects eine bestimmte Aktion ausführen dürfen:

# Installation
kubectl krew install who-can

# Wer darf Pods in production löschen?
kubectl who-can delete pods -n production

# Wer darf Secrets lesen?
kubectl who-can get secrets -n production

Das ist besonders nützlich für Security Audits.

Best Practices für RBAC

Vermeiden Sie diese häufigen Fehler:

# SCHLECHT: Zu breite Berechtigungen
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

# BESSER: Least Privilege
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
    # Kein "delete", "create" wenn nicht nötig

Nutzen Sie die eingebauten ClusterRoles als Ausgangspunkt:

ClusterRole	Berechtigungen
view	Lesen aller Ressourcen (kein Secrets)
edit	Lesen + Schreiben (kein RBAC, kein Namespace)
admin	Alles im Namespace inkl. RBAC
cluster-admin	Volle Cluster-Kontrolle

# Eingebaute ClusterRole an User binden (Namespace-scoped)
kubectl create rolebinding dev-view \
  --clusterrole=view \
  --user=developer@example.com \
  -n production

FAQ

Warum bekomme ich Forbidden obwohl ich eine RoleBinding erstellt habe?

Drei mögliche Ursachen: (1) Die RoleBinding ist im falschen Namespace, (2) der Subject-Name stimmt nicht exakt mit dem User/ServiceAccount überein, (3) die apiGroup in der Role deckt die Ressource nicht ab. Prüfen Sie alles mit kubectl describe rolebinding.

Kann ich RBAC temporär deaktivieren zum Testen?

Nein, und das sollten Sie auch nicht. Nutzen Sie stattdessen kubectl auth can-i --list --as=<user> zum Debuggen und Impersonation zum Testen: kubectl get pods --as=developer@example.com.

Was ist der Unterschied zwischen User und ServiceAccount in RBAC?

Users werden extern verwaltet (Zertifikate, OIDC, etc.) und existieren nicht als Kubernetes-Objekte. ServiceAccounts sind Kubernetes-Ressourcen in einem Namespace und werden für Anwendungen und Automatisierung genutzt.

Wie finde ich heraus, welcher ServiceAccount ein Pod verwendet?

kubectl get pod <name> -o jsonpath='{.spec.serviceAccountName}' -- wenn nicht explizit gesetzt, nutzt der Pod den ServiceAccount default im jeweiligen Namespace.

Wenn Sie ein RBAC-Konzept für Ihren Cluster aufbauen wollen oder Unterstützung bei der Absicherung Ihrer Kubernetes-Umgebung brauchen, helfen wir gerne -- Kontakt aufnehmen.

Weiterführende Artikel:

Kubernetes Forbidden Error lösen: RBAC Debugging Guide