Ich arbeite mit einer Reihe von Google Cloud Services. Einige der Cloud Storage-Buckets, in denen ich arbeite, befinden sich in Projekt-A, auf das ich von meinem eigenen Konto aus zugreifen kann, und einige befinden sich in Projekt-B, auf das ich nur mit einem Dienstkonto zugreifen kann. Ich habe das entsprechende Dienstkonto aktiviert mit
gcloud auth activate-service-account --key-file mykey.json
Bei den darauffolgenden Logins habe ich einfach
gcloud config set account service_account
Ich musste auch mein aktives Projekt wechseln, wofür ich den Befehl verwendete
gcloud config set project project-B
Das Servicekonto funktionierte einwandfrei und ermöglichte mir den Zugriff auf einen bestimmten Bitbucket, der in Google Cloud Storage gespeichert war. Danach musste ich jedoch Argo verwenden, um einen Kubernetes-Workflow zu übermitteln. Daher wechselte ich mit den Befehlen zurück zu meinem Konto und Projekt
gcloud config set account my_account
gcloud config set project project-A
Mit "gcloud auth list" kann ich sehen, dass my_account aktiv ist
ACTIVE ACCOUNT
service_account.iam.gserviceaccount.com
* my_account
Beim Versuch, „kubectl -n default get services“ auszuführen, erhielt ich jedoch die folgende Fehlermeldung:
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.
Ich erhalte denselben Fehler, wenn ich my_namespace anstelle von default verwende. Das verwirrt mich ziemlich, weil gcloud-Befehle wie „gsutil ls“ so funktionieren, als ob ich mich im richtigen Konto und Projekt befände. Warum denkt Kubernetes immer noch, dass ich ein Dienstkonto verwende, und wie kann ich es davon abhalten, es zu verwenden, damit ich wieder mit Kubernetes tun kann, was ich tun muss? Die Befehle und Pipelines, die ich ausführen möchte, funktionierten einwandfrei, bevor ich das Dienstkonto aktivierte.
Antwort1
Es stellte sich heraus, dass ich einfach nur weglaufen musste
gcloud container clusters get-credentials mycluster
Zunächst dachte ich, dass ich dies auch beheben müsste, indem ich meine Kubeconfig-Datei lösche und
~/.kube/config
dann den Befehl „get-credentials“ ausführe, aber wie in den Kommentaren erwähnt, stellte sich heraus, dass der Befehl „get-credentials“ alles war, was nötig war.
Das Problem scheint insbesondere dann aufzutreten, wenn Argo-Befehle ausgeführt werden, während das gcloud-Dienstkonto aktiv ist: Der Befehl schlägt zunächst fehl, und dann geben alle nachfolgenden kubectl-Befehle diesen Berechtigungsfehler zurück. Wenn ich zum Dienstkonto wechsle, die gcloud-Befehle ausführe und dann wieder zu meinem Konto zurückwechsele, hat dies keine Auswirkungen auf das Verhalten von kubectl.