Error from server Forbidden: welches Recht fehlt

TL;DR

Error from server (Forbidden) heißt: der API-Server hat den Request gesehen und abgelehnt. Verbindung und Zertifikat sind in Ordnung. Die Meldung nennt meist User oder ServiceAccount, Verb und Ressource. Diesen Satz prüfen, nicht raten:

kubectl auth can-i VERB RESOURCE -n NAMESPACE
kubectl auth can-i --list -n NAMESPACE

yes für get pods und no für get secrets ist ein normales Least-Privilege, kein defekter Cluster. Die Rolle, die das Recht tragen sollte, fehlt oder gilt im falschen Scope. Wer stattdessen cluster-admin vergibt, schließt das Symptom und öffnet das Cluster. Der ausführliche Audit-Weg: RBAC Audit.

Was in der Zeile steht

Eine typische Meldung: User "system:serviceaccount:prod:deploy" cannot list resource "secrets" in API group "" in the namespace "prod".

Vier Felder, alle brauchbar:

list ist nicht get. Ein Dashboard, das die Übersicht lädt, braucht list. Ein kubectl get pod POD braucht get. deployments liegen in der API-Gruppe apps, Pods in "". Eine Role, die nur pods erlaubt, lässt kubectl get deploy weiter mit Forbidden scheitern.

Role und Binding

Das Recht steht in einer Role oder ClusterRole. Es gilt erst durch ein RoleBinding oder ClusterRoleBinding, das diese Role an den User oder ServiceAccount hängt.

kubectl get rolebinding,clusterrolebinding -A -o wide | grep ACCOUNT

Ein RoleBinding gilt nur in seinem Namespace. Ein Binding in default hilft dem Pod in prod nicht. Ein ClusterRoleBinding gilt clusterweit. Für einen CI-Account, der nur in einem Namespace deployen soll, ist das ClusterRoleBinding zu weit. Dann Role plus RoleBinding in genau diesem Namespace, mit den Verben, die die Pipeline wirklich aufruft.

kubectl auth can-i create deployments.apps -n prod --as=system:serviceaccount:prod:deploy prüft, was der Deploy-Account darf, ohne sich als dieser Account anzumelden. --as braucht selbst das Recht, andere Identitäten zu impersonieren. Ohne dieses Recht die Frage im Pod stellen: kubectl exec mit dem ServiceAccount des Pods, oder can-i aus einem Pod dieses Accounts.

Forbidden ist nicht 6443 und nicht der Pod

connection refused auf 6443 erreicht den API-Server nicht. Forbidden schon. Ein Pod auf CrashLoopBackOff kann zusätzlich Forbidden in seinen eigenen Logs haben, wenn die Anwendung die API aufruft und ihr ServiceAccount das Recht nicht hat. Dann ist der Exit der Anwendung oft 1, und die Zeile cannot list resource steht im Previous-Log. Das Recht gehört an den ServiceAccount des Pods, nicht an Ihren kubectl-User.

Quellen

• kubectl auth can-i
• RBAC-Authorisierung