Helm: Ошибка: configmaps запрещен: пользователь «system:serviceaccount:kube-system:default» не может перечислить ресурс «configmaps» в группе API «» в пространстве имен «kube-system»

Созданный на 26 дек. 2018  ·  16Комментарии  ·  Источник: helm/helm

Я пытаюсь следовать УСТАНОВКЕ TILLER , но сталкиваюсь со следующей ошибкой:

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

Вывод 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"}
$ 

Вывод 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"}
$ 

Облачный провайдер/платформа (AKS, GKE, Minikube и т. д.):

голое железо, линукс

возможно, связано, я также пытаюсь получить доступ к Tiller и Role-Based Access Control , но получаю 404.

Самый полезный комментарий

Нехорошо закрывать проблему, не объяснив, как исправить :-)
Позвольте мне сделать это вместо этого тогда.

Ошибка: configmaps запрещен: Пользователь " system: serviceaccount :kube- system:default " не может перечислить

Для начала немного информации для новичков.
В Кубернете есть:

  • Аккаунт - что-то вроде вашего ID. Пример: Джон
  • Роль - какой-то группе в проекте разрешено что-то делать. Примеры: кластер-админ, ит-поддержка, ...
  • Привязка - присоединение Аккаунта к Роли. "Иоанн в нем-поддержка" - это обязаловка.

Таким образом, в нашем сообщении выше мы видим, что наш Tiller действует как учетная запись «по умолчанию», зарегистрированная в пространстве имен «kube-system». Скорее всего вы не привязали его к достаточной роли.

Теперь вернемся к проблеме.
Как мы это отслеживаем:

  • проверьте, есть ли у вас конкретная учетная запись для румпеля. Обычно он носит одно и то же название — «румпель»:
    kubectl [--namespace kube-system] get serviceaccount
    создать, если нет:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • проверьте, есть ли у вас роль или кластерная роль (роль кластера "лучше" для новичков - она ​​распространяется на весь кластер, в отличие от роли всего пространства имен). Если это не производство, вы можете использовать высокопривилегированную роль «cluster-admin»:
    kubectl [--namespace kube-system] get clusterrole
    вы можете проверить содержимое роли через:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • проверьте, имеет ли учетная запись « tiller » в первом предложении привязку к роли кластера «cluster-admin», которую вы считаете достаточной:
    kubectl [--namespace kube-system] get clusterrolebinding
    если трудно понять по именам, вы можете просто создать новый:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • наконец, когда у вас есть учетная запись, роль и привязка между ними, вы можете проверить, действительно ли вы действуете как эта учетная запись:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Я подозреваю, что в вашем выводе не будет настроек «serviceAccount» и «serviceAccountName»:

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

если да, то добавьте учетную запись, которую вы хотите использовать на румпеле:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(если вы используете PowerShell, проверьте ниже пост от @snpdev)
Теперь вы повторяете предыдущую команду проверки и видите разницу:

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

да. Что-то такое.

Все 16 Комментарий

Новый URL для всех, кто ищет: https://helm.sh/docs/rbac/#role-based-access-control .

Нехорошо закрывать проблему, не объяснив, как исправить :-)
Позвольте мне сделать это вместо этого тогда.

Ошибка: configmaps запрещен: Пользователь " system: serviceaccount :kube- system:default " не может перечислить

Для начала немного информации для новичков.
В Кубернете есть:

  • Аккаунт - что-то вроде вашего ID. Пример: Джон
  • Роль - какой-то группе в проекте разрешено что-то делать. Примеры: кластер-админ, ит-поддержка, ...
  • Привязка - присоединение Аккаунта к Роли. "Иоанн в нем-поддержка" - это обязаловка.

Таким образом, в нашем сообщении выше мы видим, что наш Tiller действует как учетная запись «по умолчанию», зарегистрированная в пространстве имен «kube-system». Скорее всего вы не привязали его к достаточной роли.

Теперь вернемся к проблеме.
Как мы это отслеживаем:

  • проверьте, есть ли у вас конкретная учетная запись для румпеля. Обычно он носит одно и то же название — «румпель»:
    kubectl [--namespace kube-system] get serviceaccount
    создать, если нет:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • проверьте, есть ли у вас роль или кластерная роль (роль кластера "лучше" для новичков - она ​​распространяется на весь кластер, в отличие от роли всего пространства имен). Если это не производство, вы можете использовать высокопривилегированную роль «cluster-admin»:
    kubectl [--namespace kube-system] get clusterrole
    вы можете проверить содержимое роли через:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • проверьте, имеет ли учетная запись « tiller » в первом предложении привязку к роли кластера «cluster-admin», которую вы считаете достаточной:
    kubectl [--namespace kube-system] get clusterrolebinding
    если трудно понять по именам, вы можете просто создать новый:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • наконец, когда у вас есть учетная запись, роль и привязка между ними, вы можете проверить, действительно ли вы действуете как эта учетная запись:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Я подозреваю, что в вашем выводе не будет настроек «serviceAccount» и «serviceAccountName»:

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

если да, то добавьте учетную запись, которую вы хотите использовать на румпеле:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(если вы используете PowerShell, проверьте ниже пост от @snpdev)
Теперь вы повторяете предыдущую команду проверки и видите разницу:

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

да. Что-то такое.

Решение @m-abramovich сработало для меня.

Примечание: при использовании Powershell команда:

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

и 2 месяца и 1/2 ваше объяснение все еще полезно, большое спасибо за то, что нашли время в своем плотном графике, чтобы быть подробным и полезным. @m-abramovich в отличие от @bacongobbler

и 2 месяца и 1/2 ваше объяснение все еще полезно, большое спасибо за то, что нашли время в своем плотном графике, чтобы быть подробным и полезным. @m-abramovich в отличие от @bacongobbler

Человек, который закрыл этот вопрос, был человеком, который его открыл. Очевидно, они считали, что проблема решена.

Кроме того, в исходном описании запрашивалась правильная ссылка на документацию по управлению доступом на основе ролей, которая была предоставлена ​​без закрытия проблемы.

Наконец, @bacongobbler нашел время предоставить запрошенную информацию 25 декабря, что для многих является важным праздником. Извините , @iamaverrick, но я считаю ваш комментарий совершенно неуместным.

Ух ты. Я даже не помню, чтобы отвечал в этой ветке... Давненько.

Предположение @marckhouzam верно: выпуск был открыт в Рождество. В тот день я был со своей семьей, но я увидел этот быстрый вопрос от ОП:

возможно, связано, я также пытаюсь получить доступ к Tiller и Role-Based Access Control , но получаю 404.

Поэтому я решил, что напишу быстрый ответ с правильной ссылкой и вернусь к празднованию Рождества. На следующий день ОП закрыл проблему, поэтому я предположил, что дальнейших действий не требуется.

Меня действительно расстраивает мысль, что мой комментарий был воспринят как краткий или бесполезный. Я не пытался решить проблему; Я просто предоставлял контекст, пока ОП пытается найти решение самостоятельно в праздничный сезон.

Спасибо @m-abramovich и @snpdev за то, что ответили на вопрос OP.

@iamaverrick Предоставление ссылки на документацию нередко при ответе на проблему. Это не бесполезность, а вера в нашу документацию, на которую мы, как сообщество, тратим много времени. если документация неадекватна, человек обычно отвечает, и это дает отвечающему возможность предоставить больше контекста. Это также дает нам понять, что документ нуждается в улучшении. Без такого взаимодействия или отзывов пользователей документация не улучшится.

В долгосрочной перспективе лучшая документация помогает людям больше, чем необходимость поднимать вопросы о несвязанных ошибках или функциях.

С другой стороны, то, что @bacongobbler вообще отвечает во время курортного сезона, весьма впечатляет. Помните, что все мы люди, пытающиеся сделать все возможное.

Ребята, пожалуйста, успокойтесь.
Мы все разработчики программного обеспечения, разделяем одни и те же жизненные ценности. У нас гораздо больше общего, чем вы даже можете себе представить. Давайте уважать друг друга, пожалуйста.

@marckhouzam неприемлемо ? Ни в какой форме я не проявил неуважение к кому-либо своим комментарием. Я просто констатировал факты со своей точки зрения. Этот комментарий был прямо упомянут @bacongobbler , а не всеми остальными, кто вставил туда 2 цента. Благодарю @bacongobbler за то, что вставил ссылку в праздник. В исходном вопросе говорится, что у него были проблемы, и ему нужно было руководство, а не ссылка. Ребята, если вы не воспринимаете конструктивную критику, то не пишите ничего в этой теме. Мы все разработчики программного обеспечения, пытающиеся стать лучше и предоставлять более качественную информацию.

Я извиняюсь за то, что не представил свой ответ более подробно, поскольку я как бы намекнул на ответ в своем вопросе, а затем @bacongobbler подтвердил мой ответ, за которым последовал отличный комментарий @m-abramovich.

Я действительно ценю помощь каждого и / или вклад, и я постараюсь сделать лучше в следующий раз, я обещаю!

и еще раз, я извиняюсь за это (я действительно не думал, что до этого дойдет...

Мои два цента: при переходе по https://helm.sh/docs/intro/quickstart/ нет упоминания о RBAC, а инструкции там приводят к неработающей установке румпеля. Поиск в Google приводит к этой проблеме здесь.

Возможно, его можно снова открыть как «улучшить краткое руководство, чтобы оно предупреждало новичков об этой ловушке»?

В предварительных условиях есть «Решение о том, какие конфигурации безопасности применить к вашей установке, если таковые имеются», но, поскольку я просто пробовал это на одноразовом кластере, «если есть» подразумевал для меня, что, поскольку меня это не волнует, я не не нужно ничего делать.

Даже если бы я заметил, что мне нужно что-то сделать, ссылки на инструкции нет.

Мои два цента: при переходе по https://helm.sh/docs/intro/quickstart/ нет упоминания о RBAC, а инструкции там приводят к неработающей установке румпеля. Поиск в Google приводит к этой проблеме здесь.

Возможно, его можно снова открыть как «улучшить краткое руководство, чтобы оно предупреждало новичков об этой ловушке»?

@pohly
Патрик, я считаю, что это уже не актуально.
Helm v3 не использует Tiller. Так что, может быть, все это уже ничего не стоит.

@m-abramovich Спасибо! Ваше подробное руководство помогло мне разобраться с этой проблемой. Я очень ценю время, которое вы потратили, чтобы написать свой ответ.

Это объяснение прекрасно! Спасибо!

Была ли эта страница полезной?
0 / 5 - 0 рейтинги