Helm: Fehler: configmaps ist verboten: Benutzer „system:serviceaccount:kube-system:default“ kann Ressource „configmaps“ nicht in API-Gruppe „“ im Namespace „kube-system“ auflisten

Erstellt am 26. Dez. 2018  ·  16Kommentare  ·  Quelle: helm/helm

Ich versuche, INSTALLING TILLER zu folgen, bekomme aber folgenden Fehler:

$ helm list
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system"
$

Ausgabe von helm version :

$ helm version
Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
$ 

Ausgabe von kubectl version :

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
$ 

Cloud-Anbieter/Plattform (AKS, GKE, Minikube etc.):

Bare-Metal, Linux

möglicherweise verwandt, versuche ich auch, auf Tiller und rollenbasierte Zugriffskontrolle zuzugreifen, erhalte jedoch 404.

Hilfreichster Kommentar

Es ist nicht gut, ein Problem zu schließen, ohne zu erklären, wie es behoben werden kann :-)
Lass es mich dann stattdessen machen.

Fehler: configmaps ist verboten: Benutzer „ system: serviceaccount:kube -system:default “ kann nicht auflisten

Zunächst einige Informationen für Neulinge.
In Kubernetes gibt es:

  • Konto - so etwas wie Ihre ID. Beispiel: Johannes
  • Rolle – eine Gruppe im Projekt darf etwas tun. Beispiele: cluster-admin, it-support, ...
  • Bindung - Konto mit Rolle verbinden. "John in it-support" - ist eine Bindung.

Daher sehen wir in unserer obigen Nachricht, dass unser Tiller als Konto „default“ fungiert, das im Namespace „kube-system“ registriert ist. Höchstwahrscheinlich haben Sie ihn nicht an eine ausreichende Rolle gebunden.

Nun zurück zum Problem.
Wie verfolgen wir es:

  • Überprüfen Sie, ob Sie ein spezielles Konto für die Pinne haben. Normalerweise hat es den gleichen Namen - "Tiller":
    kubectl [--namespace kube-system] get serviceaccount
    erstellen wenn nicht:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • Überprüfen Sie, ob Sie eine Rolle oder Clusterrolle haben (Clusterrolle ist "besser" für Neulinge - sie ist Cluster-weit im Gegensatz zu Namespace-weiter Rolle). Wenn es sich nicht um eine Produktion handelt, können Sie die hochprivilegierte Rolle „cluster-admin“ verwenden:
    kubectl [--namespace kube-system] get clusterrole
    Sie können den Rolleninhalt überprüfen über:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • Überprüfen Sie, ob das Konto „Tiller“ in der ersten Klausel eine Bindung an die Clusterrolle „Cluster-Admin“ hat, die Sie für ausreichend halten:
    kubectl [--namespace kube-system] get clusterrolebinding
    Wenn es anhand von Namen schwer herauszufinden ist, können Sie einfach neue erstellen:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • schließlich, wenn Sie das Konto, die Rolle und die Bindung zwischen ihnen haben, können Sie überprüfen, ob Sie wirklich als dieses Konto agieren:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Ich vermute, dass Ihre Ausgabe keine Einstellungen "serviceAccount" und "serviceAccountName" haben wird:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
...

Wenn ja, dann fügen Sie ein Konto hinzu, das Tiller verwenden soll:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(Wenn Sie PowerShell verwenden, suchen Sie unten nach Posts von @snpdev)
Jetzt wiederholen Sie den vorherigen Prüfbefehl und sehen den Unterschied:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: tiller                     <-- new line
serviceAccountName: tiller          <-- new line
terminationGracePeriodSeconds: 30
...

Ja. So ähnlich.

Alle 16 Kommentare

Neue URL für alle Suchenden: https://helm.sh/docs/rbac/#role -based-access-control

Es ist nicht gut, ein Problem zu schließen, ohne zu erklären, wie es behoben werden kann :-)
Lass es mich dann stattdessen machen.

Fehler: configmaps ist verboten: Benutzer „ system: serviceaccount:kube -system:default “ kann nicht auflisten

Zunächst einige Informationen für Neulinge.
In Kubernetes gibt es:

  • Konto - so etwas wie Ihre ID. Beispiel: Johannes
  • Rolle – eine Gruppe im Projekt darf etwas tun. Beispiele: cluster-admin, it-support, ...
  • Bindung - Konto mit Rolle verbinden. "John in it-support" - ist eine Bindung.

Daher sehen wir in unserer obigen Nachricht, dass unser Tiller als Konto „default“ fungiert, das im Namespace „kube-system“ registriert ist. Höchstwahrscheinlich haben Sie ihn nicht an eine ausreichende Rolle gebunden.

Nun zurück zum Problem.
Wie verfolgen wir es:

  • Überprüfen Sie, ob Sie ein spezielles Konto für die Pinne haben. Normalerweise hat es den gleichen Namen - "Tiller":
    kubectl [--namespace kube-system] get serviceaccount
    erstellen wenn nicht:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • Überprüfen Sie, ob Sie eine Rolle oder Clusterrolle haben (Clusterrolle ist "besser" für Neulinge - sie ist Cluster-weit im Gegensatz zu Namespace-weiter Rolle). Wenn es sich nicht um eine Produktion handelt, können Sie die hochprivilegierte Rolle „cluster-admin“ verwenden:
    kubectl [--namespace kube-system] get clusterrole
    Sie können den Rolleninhalt überprüfen über:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • Überprüfen Sie, ob das Konto „Tiller“ in der ersten Klausel eine Bindung an die Clusterrolle „Cluster-Admin“ hat, die Sie für ausreichend halten:
    kubectl [--namespace kube-system] get clusterrolebinding
    Wenn es anhand von Namen schwer herauszufinden ist, können Sie einfach neue erstellen:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • schließlich, wenn Sie das Konto, die Rolle und die Bindung zwischen ihnen haben, können Sie überprüfen, ob Sie wirklich als dieses Konto agieren:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Ich vermute, dass Ihre Ausgabe keine Einstellungen "serviceAccount" und "serviceAccountName" haben wird:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
...

Wenn ja, dann fügen Sie ein Konto hinzu, das Tiller verwenden soll:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(Wenn Sie PowerShell verwenden, suchen Sie unten nach Posts von @snpdev)
Jetzt wiederholen Sie den vorherigen Prüfbefehl und sehen den Unterschied:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: tiller                     <-- new line
serviceAccountName: tiller          <-- new line
terminationGracePeriodSeconds: 30
...

Ja. So ähnlich.

@m-abramovich-Lösung hat bei mir funktioniert.

Hinweis: Bei Verwendung von Powershell lautet der Befehl:

kubectl --namespace kube-system patch deploy tiller-deploy -p '{\"spec\":{\"template\":{\"spec\":{\"serviceAccount\":\"tiller\"}}}}'

und 2 Monate und 1/2 Ihre Erklärung ist immer noch hilfreich. Vielen Dank, dass Sie sich trotz Ihres vollen Terminkalenders die Zeit genommen haben, detailliert und hilfreich zu sein. @m-abramovich im Gegensatz zu @bacongobbler

und 2 Monate und 1/2 Ihre Erklärung ist immer noch hilfreich. Vielen Dank, dass Sie sich trotz Ihres vollen Terminkalenders die Zeit genommen haben, detailliert und hilfreich zu sein. @m-abramovich im Gegensatz zu @bacongobbler

Die Person, die dieses Problem geschlossen hat, war die Person, die es geöffnet hat. Offensichtlich hatten sie das Gefühl, dass das Problem gelöst war.

Darüber hinaus wurde in der ursprünglichen Beschreibung nach dem richtigen Link zur rollenbasierten Zugriffssteuerungsdokumentation gefragt, die bereitgestellt wurde, ohne das Problem zu schließen.

Schließlich nahm sich @bacongobbler die Zeit, die gewünschten Informationen am 25. Dezember bereitzustellen, der für viele ein wichtiger Feiertag ist. Es tut mir leid, @iamaverrick , aber ich finde deinen Kommentar ziemlich unangemessen.

Beeindruckend. Ich kann mich nicht einmal erinnern, auf diesen Thread geantwortet zu haben ... Schon eine Weile her.

Die Annahme von @marckhouzam hier ist richtig: Die Ausgabe wurde am Weihnachtstag eröffnet. Ich war an diesem Tag zufällig bei meiner Familie, aber ich sah diese kurze Frage vom OP:

möglicherweise verwandt, versuche ich auch, auf Tiller und rollenbasierte Zugriffskontrolle zuzugreifen, erhalte jedoch 404.

Also dachte ich, ich würde eine schnelle Antwort mit dem richtigen Link schießen und mich wieder auf das Feiern von Weihnachten begeben. Am nächsten Tag schloss das OP das Problem, daher ging ich davon aus, dass keine weitere Nachverfolgung erforderlich war.

Es regt mich wirklich auf zu glauben, dass mein Kommentar als knapp oder nicht hilfreich angesehen wurde. Ich habe nicht versucht, das Problem zu lösen; Ich habe lediglich Kontext bereitgestellt, während das OP versucht, die Lösung während der Ferienzeit selbst zu finden.

Vielen Dank an @m-abramovich und @snpdev für die Nachverfolgung und Bereitstellung von Antworten auf das Problem von OP.

@iamaverrick Das Bereitstellen eines Links zur Dokumentation ist nicht ungewöhnlich, wenn auf ein Problem geantwortet wird. Das ist nicht wenig hilfreich, sondern ein Glaube an unsere Dokumentation, in die wir als Community viel Zeit investieren. Wenn die Dokumentation unzureichend ist, antwortet die Person normalerweise, und dies gibt dem Antwortenden die Möglichkeit, mehr Kontext bereitzustellen. Es macht uns auch bewusst, dass das Dokument verbessert werden muss. Ohne Interaktion oder Feedback wie dieses von Benutzern wird die Dokumentation nicht verbessert.

Auf lange Sicht hilft eine bessere Dokumentation den Menschen mehr, als Probleme für nicht verwandte Fehler oder Funktionen melden zu müssen.

Auf einer anderen Ebene ist es ziemlich beeindruckend, dass @bacongobbler während der Ferienzeit überhaupt reagiert. Denken Sie daran, dass wir alle Menschen sind, die versuchen, unser Bestes zu geben.

Leute, bitte nehmt es locker.
Wir sind alle Softwareentwickler und teilen dieselben Werte im Leben. Wir haben viel mehr gemeinsam, als Sie sich vorstellen können. Lasst uns bitte einander respektieren.

@marckhouzam unangemessen? In keiner Form habe ich mit meinem Kommentar jemanden respektlos behandelt. Ich habe einfach die Fakten aus meiner Sicht dargestellt. Dieser Kommentar wurde direkt @bacongobbler erwähnt, nicht alle anderen, die dort 2 Cent investiert haben. Ich danke @bacongobbler dafür, dass er den Link an einem Feiertag eingefügt hat. Die ursprüngliche Frage besagt, dass er Probleme hatte und eine Anleitung brauchte, keinen Link. Leute, wenn ihr keine konstruktive Kritik vertragen könnt, dann postet nichts in diesen Threads. Wir sind alle Softwareentwickler, die versuchen, besser zu werden und bessere Informationen bereitzustellen.

Ich entschuldige mich dafür, dass ich meine Antwort nicht ausführlicher bewiesen habe, da ich die Antwort in meiner Frage irgendwie angedeutet habe und dann @bacongobbler meine Antwort bestätigt hat, gefolgt von einem großartigen Kommentar von @m-abramovich

Ich schätze wirklich die Hilfe und/oder den Input aller und ich werde versuchen, das nächste Mal besser zu werden, versprochen!

und nochmal, es tut mir leid, dass ich das verursacht habe (ich hätte wirklich nicht gedacht, dass es so weit kommen würde ...

Meine zwei Cent: Wenn Sie https://helm.sh/docs/intro/quickstart/ folgen, wird RBAC nicht erwähnt und die dortigen Anweisungen führen zu einer nicht funktionierenden Installation von Tiller. Eine Google-Suche führt dann zu diesem Problem hier.

Vielleicht kann es als "Schnellstartanleitung verbessern, damit es Neulinge vor dieser Falle warnt" wieder geöffnet werden?

Unter den Voraussetzungen steht „Entscheiden, welche Sicherheitskonfigurationen auf Ihre Installation angewendet werden sollen, falls vorhanden“, aber da ich es gerade auf einem Wegwerfcluster ausprobiert habe, implizierte das „falls vorhanden“, dass ich es nicht interessiere, da es mir egal ist nichts tun müssen.

Auch wenn ich gemerkt hätte, dass ich etwas tun muss, gibt es keinen Link zu einer Anleitung.

Meine zwei Cent: Wenn Sie https://helm.sh/docs/intro/quickstart/ folgen, wird RBAC nicht erwähnt und die dortigen Anweisungen führen zu einer nicht funktionierenden Installation von Tiller. Eine Google-Suche führt dann zu diesem Problem hier.

Vielleicht kann es als "Schnellstartanleitung verbessern, damit es Neulinge vor dieser Falle warnt" wieder geöffnet werden?

@pohl
Patrick, ich glaube, das ist nicht mehr relevant.
Helm v3 verwendet Tiller nicht. Vielleicht ist das alles jetzt wertlos.

@m-abramovich Danke! Ihre ausführliche Anleitung hat mir geholfen, dieses Problem zu lösen. Ich schätze die Zeit, die Sie sich genommen haben, um Ihre Antwort zu schreiben, sehr.

Diese Erklärung ist großartig! Danke!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen