Helm: Erro: configmaps é proibido: o usuário "system:serviceaccount:kube-system:default" não pode listar o recurso "configmaps" no grupo de API "" no namespace "kube-system"

Criado em 26 dez. 2018  ·  16Comentários  ·  Fonte: helm/helm

Estou tentando seguir INSTALLING TILLER , mas estou com o seguinte erro:

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

Saída 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"}
$ 

Saída 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"}
$ 

Provedor/plataforma de nuvem (AKS, GKE, Minikube etc.):

metal nu, linux

possivelmente relacionado, também estou tentando acessar o Tiller e o controle de acesso baseado em função , mas obtendo 404.

Comentários muito úteis

Não é bom fechar um problema sem explicar a maneira de corrigir :-)
Deixe-me fazê-lo em vez disso.

Erro: configmaps é proibido: Usuário " system:serviceaccount :kube- system:default " não pode listar

Primeiro, algumas informações para iniciantes.
No Kubernetes existem:

  • Conta - algo como seu ID. Exemplo: joão
  • Função - algum grupo no projeto tem permissão para fazer alguma coisa. Exemplos: cluster-admin, it-support, ...
  • Vinculação - juntando conta à função. "John in it-support" - é uma ligação.

Assim, em nossa mensagem acima, vemos que nosso Tiller atua como conta "default" registrada no namespace "kube-system". Muito provavelmente você não o vinculou a um papel suficiente.

Agora de volta ao problema.
Como podemos rastreá-lo:

  • verifique se você tem conta específica para leme. Geralmente tem o mesmo nome - "tiller":
    kubectl [--namespace kube-system] get serviceaccount
    crie se não:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • verifique se você tem função ou clusterrole (a função do cluster é "melhor" para iniciantes - é em todo o cluster, ao contrário da função em todo o namespace). Se isso não for uma produção, você pode usar a função altamente privilegiada "cluster-admin":
    kubectl [--namespace kube-system] get clusterrole
    você pode verificar o conteúdo da função por meio de:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • verifique se a conta "tiller" na primeira cláusula tem uma ligação ao clusterrole "cluster-admin" que você considera suficiente:
    kubectl [--namespace kube-system] get clusterrolebinding
    se for difícil descobrir com base em nomes, você pode simplesmente criar um novo:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • finalmente, quando você tiver a conta, o papel e a vinculação entre eles, poderá verificar se realmente atua como esta conta:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Eu suspeito que sua saída não terá as configurações "serviceAccount" e "serviceAccountName":

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

se sim, adicione uma conta que você deseja que o Tiller use:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(se você usa o PowerShell, verifique abaixo a postagem de @snpdev)
Agora você repete o comando de verificação anterior e vê a diferença:

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

sim. Algo parecido.

Todos 16 comentários

Nova URL para quem procura: https://helm.sh/docs/rbac/#role -based-access-control

Não é bom fechar um problema sem explicar a maneira de corrigir :-)
Deixe-me fazê-lo em vez disso.

Erro: configmaps é proibido: Usuário " system:serviceaccount :kube- system:default " não pode listar

Primeiro, algumas informações para iniciantes.
No Kubernetes existem:

  • Conta - algo como seu ID. Exemplo: joão
  • Função - algum grupo no projeto tem permissão para fazer alguma coisa. Exemplos: cluster-admin, it-support, ...
  • Vinculação - juntando conta à função. "John in it-support" - é uma ligação.

Assim, em nossa mensagem acima, vemos que nosso Tiller atua como conta "default" registrada no namespace "kube-system". Muito provavelmente você não o vinculou a um papel suficiente.

Agora de volta ao problema.
Como podemos rastreá-lo:

  • verifique se você tem conta específica para leme. Geralmente tem o mesmo nome - "tiller":
    kubectl [--namespace kube-system] get serviceaccount
    crie se não:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • verifique se você tem função ou clusterrole (a função do cluster é "melhor" para iniciantes - é em todo o cluster, ao contrário da função em todo o namespace). Se isso não for uma produção, você pode usar a função altamente privilegiada "cluster-admin":
    kubectl [--namespace kube-system] get clusterrole
    você pode verificar o conteúdo da função por meio de:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • verifique se a conta "tiller" na primeira cláusula tem uma ligação ao clusterrole "cluster-admin" que você considera suficiente:
    kubectl [--namespace kube-system] get clusterrolebinding
    se for difícil descobrir com base em nomes, você pode simplesmente criar um novo:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • finalmente, quando você tiver a conta, o papel e a vinculação entre eles, poderá verificar se realmente atua como esta conta:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

Eu suspeito que sua saída não terá as configurações "serviceAccount" e "serviceAccountName":

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

se sim, adicione uma conta que você deseja que o Tiller use:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(se você usa o PowerShell, verifique abaixo a postagem de @snpdev)
Agora você repete o comando de verificação anterior e vê a diferença:

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

sim. Algo parecido.

A solução @m-abramovich funcionou para mim.

Nota: se estiver usando o Powershell, o comando é:

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

e 2 meses e 1/2 sua explicação ainda está sendo útil, muito obrigado por tirar um tempo de sua agenda lotada para ser detalhada e útil. @m-abramovich diferente de @bacongobbler

e 2 meses e 1/2 sua explicação ainda está sendo útil, muito obrigado por tirar um tempo de sua agenda lotada para ser detalhada e útil. @m-abramovich diferente de @bacongobbler

A pessoa que fechou este problema foi a pessoa que o abriu. Claramente eles sentiram que o problema foi resolvido.

Além disso, a descrição original solicitava o link adequado para a documentação de controle de acesso baseado em função, que foi fornecida sem encerrar o problema.

Por fim, @bacongobbler aproveitou para fornecer as informações solicitadas no dia 25 de dezembro, que para muitos é um feriado importante. Desculpe @iamaverrick , mas acho seu comentário bastante inapropriado.

Uau. Eu nem me lembro de responder a este tópico... Já faz um tempo.

A suposição de @marckhouzam aqui está correta: a questão foi aberta no dia de Natal. Eu estava com minha família naquele dia, mas vi esta pergunta rápida do OP:

possivelmente relacionado, também estou tentando acessar o Tiller e o controle de acesso baseado em função , mas obtendo 404.

Então pensei em dar uma resposta rápida com o link correto e voltar a comemorar o Natal. No dia seguinte, o OP encerrou o problema, então presumi que não era necessário mais acompanhamento.

Realmente me incomoda pensar que meu comentário foi assumido como conciso ou inútil. Eu não estava tentando resolver o problema; Eu estava apenas fornecendo contexto enquanto o OP tenta encontrar a solução durante a temporada de férias.

Obrigado @m-abramovich e @snpdev por acompanhar e fornecer respostas ao problema do OP.

@iamaverrick Fornecer um link para a documentação não é incomum ao responder a um problema. Isso não é inútil, mas uma crença em nossa documentação na qual nós, como comunidade, investimos muito tempo. se a documentação for inadequada, a pessoa geralmente responde e isso dá ao respondente a oportunidade de fornecer mais contexto. Também nos conscientiza de que o documento precisa ser melhorado. Sem interação ou feedback como este dos usuários, os documentos não melhorarão.

A longo prazo, uma melhor documentação ajuda as pessoas mais do que ter que levantar problemas para bugs ou recursos não relacionados.

Em outro nível, para @bacongobbler responder durante a temporada de férias é bastante impressionante. Lembre-se que somos todos pessoas tentando fazer o nosso melhor.

Pessoal, por favor, tenham calma.
Somos todos desenvolvedores de software, compartilhamos os mesmos valores na vida. Temos muito mais em comum do que você pode imaginar. Vamos respeitar uns aos outros por favor.

@marckhouzam inapropriado? De forma alguma desrespeitei ninguém com meu comentário. Eu simplesmente expus os fatos da minha perspectiva. Este comentário foi mencionado diretamente @bacongobbler nem todo mundo que colocou lá 2 centavos. Agradeço @bacongobbler por colar o link em um feriado. A pergunta original afirma que ele estava tendo problemas e precisava de orientação, não de um link. Pessoal, se você não pode aceitar críticas construtivas, então não poste nada nesses tópicos. Somos todos desenvolvedores de software tentando nos tornar melhores e fornecer melhores informações.

Peço desculpas por não provar minha resposta com mais detalhes, pois meio que insinuei a resposta na minha pergunta e, em seguida, @bacongobbler confirmou minha resposta, seguida por um ótimo comentário de @m-abramovich

Eu realmente aprecio a ajuda e/ou contribuição de todos e tentarei fazer um trabalho melhor da próxima vez, prometo!

e novamente, me desculpe por causar isso (eu realmente não achei que chegaria a isso...

Meus dois centavos: ao seguir https://helm.sh/docs/intro/quickstart/ , não há menção ao RBAC e as instruções levam a uma instalação não funcional do leme. Uma pesquisa no google leva a esse problema aqui.

Talvez possa ser reaberto como "guia de início rápido aprimorado para alertar os novatos sobre essa armadilha"?

Há "Decidindo quais configurações de segurança aplicar à sua instalação, se houver" nos pré-requisitos, mas como eu estava apenas testando em um cluster descartável, o "se houver" implicava para mim que, como não me importo, não não precisa fazer nada.

Mesmo se eu tivesse notado que preciso fazer alguma coisa, não há link para instruções.

Meus dois centavos: ao seguir https://helm.sh/docs/intro/quickstart/ , não há menção ao RBAC e as instruções levam a uma instalação não funcional do leme. Uma pesquisa no google leva a esse problema aqui.

Talvez possa ser reaberto como "guia de início rápido aprimorado para alertar os novatos sobre essa armadilha"?

@pohly
Patrick, acredito que isso não seja mais relevante.
O Helm v3 não usa o Tiller. Então, talvez, tudo o que é inútil agora.

@m-abramovich Obrigado! Sua explicação detalhada me ajudou a superar esse problema. Eu aprecio muito o tempo que você levou para escrever sua resposta.

Essa explicação é ótima! Obrigado!

Esta página foi útil?
0 / 5 - 0 avaliações