Helm: Erreur : configmaps est interdit : l'utilisateur "system:serviceaccount:kube-system:default" ne peut pas répertorier la ressource "configmaps" dans le groupe d'API "" dans l'espace de noms "kube-system"

Créé le 26 déc. 2018  ·  16Commentaires  ·  Source: helm/helm

J'essaie de suivre INSTALLING TILLER , mais je rencontre l'erreur suivante :

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

Sortie de 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"}
$ 

Sortie de 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"}
$ 

Fournisseur/plate-forme cloud (AKS, GKE, Minikube, etc.) :

métal nu, Linux

peut-être lié, j'essaie également d'accéder à Tiller et au contrôle d'accès basé sur les rôles , mais j'obtiens 404.

Commentaire le plus utile

Pas bon de fermer un problème sans expliquer la façon de le réparer :-)
Laissez-moi le faire à la place alors.

Erreur : configmaps est interdit : l'utilisateur " system:serviceaccount :kube- system:default " ne peut pas être répertorié

Tout d'abord, quelques informations pour les débutants.
Dans Kubernetes, il y a :

  • Compte - quelque chose comme votre ID. Exemple : Jean
  • Rôle - un groupe dans le projet est autorisé à faire quelque chose. Exemples : cluster-admin, it-support, ...
  • Liaison - joindre le compte au rôle. "John in it-support" - est une liaison.

Ainsi, dans notre message ci-dessus, nous voyons que notre Tiller agit comme compte "default" enregistré à l'espace de noms "kube-system". Très probablement, vous ne l'avez pas lié à un rôle suffisant.

Revenons maintenant au problème.
Comment le suivons-nous :

  • vérifiez si vous avez un compte spécifique pour la barre. Habituellement, il a le même nom - "tiller":
    kubectl [--namespace kube-system] get serviceaccount
    créer sinon :
    kubectl [--namespace kube-system] create serviceaccount tiller
  • vérifiez si vous avez un rôle ou un rôle de cluster (le rôle de cluster est "meilleur" pour les débutants - il est à l'échelle du cluster contrairement au rôle à l'échelle de l'espace de noms). S'il ne s'agit pas d'une production, vous pouvez utiliser le rôle hautement privilégié "cluster-admin":
    kubectl [--namespace kube-system] get clusterrole
    vous pouvez vérifier le contenu du rôle via :
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • vérifiez si le compte "tiller" dans la première clause a une liaison au clusterrole "cluster-admin" que vous jugez suffisante :
    kubectl [--namespace kube-system] get clusterrolebinding
    s'il est difficile de comprendre en fonction des noms, vous pouvez simplement créer de nouveaux :
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • enfin, lorsque vous avez le compte, le rôle et le lien entre eux, vous pouvez vérifier si vous agissez vraiment en tant que compte :
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Je soupçonne que votre sortie n'aura pas les paramètres "serviceAccount" et "serviceAccountName":

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

si oui, ajoutez un compte que vous souhaitez que le tiller utilise :
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(si vous utilisez PowerShell, vérifiez ci-dessous la publication de @snpdev)
Maintenant, vous répétez la commande de vérification précédente et voyez la différence :

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

Oui. Quelque chose comme ca.

Tous les 16 commentaires

Nouvelle URL pour tous ceux qui recherchent : https://helm.sh/docs/rbac/#role -based-access-control

Pas bon de fermer un problème sans expliquer la façon de le réparer :-)
Laissez-moi le faire à la place alors.

Erreur : configmaps est interdit : l'utilisateur " system:serviceaccount :kube- system:default " ne peut pas être répertorié

Tout d'abord, quelques informations pour les débutants.
Dans Kubernetes, il y a :

  • Compte - quelque chose comme votre ID. Exemple : Jean
  • Rôle - un groupe dans le projet est autorisé à faire quelque chose. Exemples : cluster-admin, it-support, ...
  • Liaison - joindre le compte au rôle. "John in it-support" - est une liaison.

Ainsi, dans notre message ci-dessus, nous voyons que notre Tiller agit comme compte "default" enregistré à l'espace de noms "kube-system". Très probablement, vous ne l'avez pas lié à un rôle suffisant.

Revenons maintenant au problème.
Comment le suivons-nous :

  • vérifiez si vous avez un compte spécifique pour la barre. Habituellement, il a le même nom - "tiller":
    kubectl [--namespace kube-system] get serviceaccount
    créer sinon :
    kubectl [--namespace kube-system] create serviceaccount tiller
  • vérifiez si vous avez un rôle ou un rôle de cluster (le rôle de cluster est "meilleur" pour les débutants - il est à l'échelle du cluster contrairement au rôle à l'échelle de l'espace de noms). S'il ne s'agit pas d'une production, vous pouvez utiliser le rôle hautement privilégié "cluster-admin":
    kubectl [--namespace kube-system] get clusterrole
    vous pouvez vérifier le contenu du rôle via :
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • vérifiez si le compte "tiller" dans la première clause a une liaison au clusterrole "cluster-admin" que vous jugez suffisante :
    kubectl [--namespace kube-system] get clusterrolebinding
    s'il est difficile de comprendre en fonction des noms, vous pouvez simplement créer de nouveaux :
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • enfin, lorsque vous avez le compte, le rôle et le lien entre eux, vous pouvez vérifier si vous agissez vraiment en tant que compte :
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Je soupçonne que votre sortie n'aura pas les paramètres "serviceAccount" et "serviceAccountName":

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

si oui, ajoutez un compte que vous souhaitez que le tiller utilise :
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(si vous utilisez PowerShell, vérifiez ci-dessous la publication de @snpdev)
Maintenant, vous répétez la commande de vérification précédente et voyez la différence :

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

Oui. Quelque chose comme ca.

La solution @m-abramovich a fonctionné pour moi.

Remarque : si vous utilisez Powershell, la commande est :

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

et 2 mois et 1/2 votre explication est toujours utile merci beaucoup d'avoir pris le temps de votre emploi du temps chargé pour être détaillé et utile. @m-abramovich contrairement à @bacongobbler

et 2 mois et 1/2 votre explication est toujours utile merci beaucoup d'avoir pris le temps de votre emploi du temps chargé pour être détaillé et utile. @m-abramovich contrairement à @bacongobbler

La personne qui a fermé ce sujet est la personne qui l'a ouvert. De toute évidence, ils estimaient que le problème était résolu.

De plus, la description originale demandait le lien approprié vers la documentation sur le contrôle d'accès basé sur les rôles, qui a été fournie sans fermer le problème.

Enfin, @bacongobbler a pris le temps de fournir les informations demandées le 25 décembre, qui pour beaucoup est une fête importante. Je suis désolé @iamaverrick mais je trouve votre commentaire tout à fait inapproprié.

Wow. Je ne me souviens même pas d'avoir répondu à ce fil... Ça fait un moment.

L'hypothèse de @marckhouzam ici est correcte : le numéro a été ouvert le jour de Noël. Il se trouve que j'étais avec ma famille ce jour-là, mais j'ai vu cette question rapide du PO :

peut-être lié, j'essaie également d'accéder à Tiller et au contrôle d'accès basé sur les rôles , mais j'obtiens 404.

J'ai donc pensé que je tirerais une réponse rapide avec le bon lien et que je reviendrais à la fête de Noël. Le lendemain, le PO a clos le problème, j'ai donc supposé qu'aucun suivi supplémentaire n'était nécessaire.

Cela me dérange vraiment de penser que mon commentaire a été considéré comme laconique ou inutile. Je n'essayais pas de résoudre le problème; Je fournissais simplement un contexte pendant que le PO essayait de trouver lui-même la solution pendant la période des fêtes.

Merci @m-abramovich et @snpdev d'avoir suivi et fourni des réponses au problème d'OP.

@iamaverrick Fournir un lien vers la documentation n'est pas rare pour répondre à un problème. Ce n'est pas inutile, mais une croyance en notre documentation sur laquelle nous, en tant que communauté, investissons beaucoup de temps. si la documentation est inadéquate, la personne répond généralement, ce qui donne à l'intervenant l'occasion de fournir plus de contexte. Cela nous fait également prendre conscience que la doc doit être améliorée. Sans interaction ou commentaires comme celui-ci de la part des utilisateurs, les documents ne s'amélioreront pas.

À long terme, une meilleure documentation aide les gens plus que d'avoir à soulever des problèmes pour des bogues ou des fonctionnalités non liés.

À un autre niveau, pour @bacongobbler , répondre pendant la période des fêtes est assez impressionnant. Rappelez-vous que nous sommes tous des gens qui essayons de faire de notre mieux.

Les gars, s'il vous plaît, allez-y doucement.
Nous sommes tous des développeurs de logiciels, partageons les mêmes valeurs dans la vie. Nous avons bien plus en commun que vous ne pouvez même l'imaginer. Respectons-nous s'il vous plait.

@marckhouzam inapproprié ? En aucun cas je n'ai manqué de respect à qui que ce soit avec mon commentaire. J'ai simplement exposé les faits de mon point de vue. Ce commentaire a été directement mentionné @bacongobbler pas tous les autres qui y ont mis 2 cents. J'apprécie @bacongobbler d'avoir collé le lien un jour férié. La question initiale indique qu'il avait des problèmes et avait besoin de conseils et non d'un lien. Les gars, si vous ne pouvez pas accepter les critiques constructives, ne postez rien sur ces discussions. Nous sommes tous des développeurs de logiciels essayant de devenir meilleurs et de fournir de meilleures informations.

Je m'excuse de ne pas avoir prouvé ma réponse avec plus de détails car j'ai en quelque sorte laissé entendre la réponse dans ma question, puis @bacongobbler a confirmé ma réponse, suivie d'un excellent commentaire de @m-abramovich

J'apprécie vraiment l'aide et/ou la contribution de chacun et j'essaierai de faire mieux la prochaine fois, je le promets !

et encore une fois, je suis désolé d'avoir causé ça (je ne pensais vraiment pas que ça arriverait à ça...

Mes deux cents: en suivant https://helm.sh/docs/intro/quickstart/ , il n'y a aucune mention de RBAC et les instructions y conduisent à une installation non fonctionnelle de la barre. Une recherche Google conduit alors à ce problème ici.

Peut-être peut-il être rouvert en tant que "guide de démarrage rapide amélioré afin qu'il avertisse les débutants de ce piège" ?

Il y a "Décider des configurations de sécurité à appliquer à votre installation, le cas échéant" sous les prérequis, mais comme je l'essayais juste sur un cluster jetable, le "le cas échéant" impliquait pour moi que comme je m'en fiche, je ne pas besoin de faire quoi que ce soit.

Même si j'avais remarqué que je dois faire quelque chose, il n'y a pas de lien vers les instructions.

Mes deux cents: en suivant https://helm.sh/docs/intro/quickstart/ , il n'y a aucune mention de RBAC et les instructions y conduisent à une installation non fonctionnelle de la barre. Une recherche Google conduit alors à ce problème ici.

Peut-être peut-il être rouvert en tant que "guide de démarrage rapide amélioré afin qu'il avertisse les débutants de ce piège" ?

@pohly
Patrick, je crois que ce n'est plus pertinent.
Helm v3 n'utilise pas Tiller. Alors, peut-être que tout cela ne vaut plus rien maintenant.

@m-abramovich Merci ! Votre visite détaillée m'a aidé à résoudre ce problème. J'apprécie beaucoup le temps que vous avez pris pour rédiger votre réponse.

Super cette explication ! Merci!

Cette page vous a été utile?
0 / 5 - 0 notes