Я работаю с несколькими сервисами Google Cloud. Некоторые из контейнеров Cloud Storage, где я работаю, находятся в проекте A, доступ к которому возможен из моей учетной записи, а некоторые — в проекте B, доступ к которому возможен только с помощью учетной записи службы. Я активировал соответствующую учетную запись службы с помощью
gcloud auth activate-service-account --key-file mykey.json
При последующих входах я просто использовал
gcloud config set account service_account
Мне также нужно было переключить мой активный проект, для чего я использовал команду
gcloud config set project project-B
Сервисная учетная запись работала отлично, позволяя мне получить доступ к определенному битбакету, хранящемуся в Google Cloud Storage, но после этого мне нужно было использовать Argo для отправки рабочего процесса Kubernetes, поэтому я переключился обратно на свою учетную запись и проект с помощью команд
gcloud config set account my_account
gcloud config set project project-A
Используя «gcloud auth list» я вижу, что my_account активен
ACTIVE ACCOUNT
service_account.iam.gserviceaccount.com
* my_account
Но при попытке отправить команду «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.
Я получаю ту же ошибку, когда использую my_namespace вместо default. Я немного сбит с толку, потому что команды gcloud, такие как "gsutil ls", работают так, как будто я нахожусь в правильной учетной записи и проекте. Почему kubernetes все еще думает, что я использую учетную запись службы, и как мне заставить его прекратить ее использовать, чтобы я мог снова делать то, что мне нужно, с помощью kubernetes? Команды и конвейеры, которые я пытаюсь запустить, работали отлично до активации учетной записи службы.
решение1
Оказывается, мне просто нужно было бежать.
gcloud container clusters get-credentials mycluster
Сначала я думал, что мне также придется исправить это, удалив файл kubeconfig, а
~/.kube/config
затем выполнив команду get-credentials, но, как указано в комментариях, оказалось, что команды get-credentials было достаточно.
Проблема, по-видимому, возникает при запуске команд argo, когда учетная запись службы gcloud активна: команда сначала не выполняется, затем все последующие команды kubectl возвращают эту ошибку разрешений. Если я переключусь на учетную запись службы, запущу команды gcloud, а затем вернусь обратно на свою учетную запись, это не повлияет на поведение kubectl.