Trabalho com vários serviços do Google Cloud. Alguns dos buckets do Cloud Storage em que trabalho estão no projeto A, que pode ser acessado pela minha própria conta, e alguns estão no projeto B, que só posso acessar com uma conta de serviço. Ativei a conta de serviço apropriada com
gcloud auth activate-service-account --key-file mykey.json
Durante os logins subsequentes, acabei de usar
gcloud config set account service_account
Também precisei mudar meu projeto ativo, para o qual usei o comando
gcloud config set project project-B
A conta de serviço funcionou perfeitamente, permitindo-me acessar um bitbucket específico armazenado no Google Cloud Storage, mas depois precisei usar o Argo para enviar um fluxo de trabalho do Kubernetes, então voltei para minha conta e projeto com os comandos
gcloud config set account my_account
gcloud config set project project-A
Usando "gcloud auth list", posso ver que my_account está ativo
ACTIVE ACCOUNT
service_account.iam.gserviceaccount.com
* my_account
Mas recebi o seguinte erro ao tentar enviar "kubectl -n default get services":
Error from server (Forbidden): services is forbidden: User "service_account.iam.gserviceaccount.com" cannot list resource "services" in API group "" in the namespace "default": Required "container.services.list" permission.
Recebo o mesmo erro quando uso my_namespace em vez do padrão. Estou um pouco confuso com isso porque comandos gcloud como "gsutil ls" funcionam como se eu estivesse na conta e no projeto corretos. Por que o Kubernetes ainda pensa que estou usando uma conta de serviço e como faço para que ele pare de usá-la para poder fazer o que preciso com o Kubernetes novamente? Os comandos e pipelines que estou tentando executar funcionaram perfeitamente antes de ativar a conta de serviço.
Responder1
Acontece que eu só precisava correr
gcloud container clusters get-credentials mycluster
Inicialmente, pensei que também precisaria consertar isso excluindo meu arquivo kubeconfig e
~/.kube/config
executando o comando get-credentials, mas como apontado nos comentários, descobri que o comando get-credentials era tudo o que era necessário.
O problema parece surgir especificamente da execução de comandos argo enquanto a conta de serviço gcloud está ativa: o comando falharia primeiro e, em seguida, todos os comandos kubectl subsequentes retornariam esse erro de permissão. Se eu mudasse para a conta de serviço, executasse os comandos gcloud e depois voltasse para minha conta, isso não afetaria o comportamento do kubectl.