Quiero usar la suplantación de identidad de GCP para obtener mis credenciales de clúster de GKE. Y luego quiero ejecutar los comandos de kubectl .
rakib-example-projectroles/owner , por lo que puede hacer cualquier cosa y todo dentro del proyecto GCProles/iam.serviceAccountTokenCreator para todo el proyecto, por lo que puede hacerse pasar por el propietario ServiceAccount en el proyecto de GCPmy-gke-cluster✅ Me he autenticado como ejecutor ServiceAccount:
$ gcloud auth activate-service-account --key-file=my_executor_sa_key.json Activated service account credentials for: [executor@rakib-example-project.iam.gserviceaccount.com]✅ Obtuve las credenciales del clúster de GKE haciéndome pasar por el propietario :
$ gcloud container clusters get-credentials my-gke-cluster \ --zone asia-southeast1-a \ --project rakib-example-project \ --impersonate-service-account=owner@rakib-example-project.iam.gserviceaccount.com WARNING: This command is using service account impersonation. All API calls will be executed as [owner@rakib-example-project.iam.gserviceaccount.com]. WARNING: This command is using service account impersonation. All API calls will be executed as [owner@rakib-example-project.iam.gserviceaccount.com]. Fetching cluster endpoint and auth data. kubeconfig entry generated for my-gke-cluster. ❌ No puedo enumerar los nodos del clúster debido a que falta el permiso container.nodes.list :
$ kubectl get nodes Error from server (Forbidden): nodes is forbidden: User "executor@rakib-example-project.iam.gserviceaccount.com" cannot list resource "nodes" in API group "" at the cluster scope: requires one of ["container.nodes.list"] permission(s).Pero ya me he hecho pasar por la cuenta de servicio del propietario . ¿Por qué todavía le faltan permisos? 😧😧😧
Funciona bien si concedo a mi ejecutor ServiceAccount el roles/container.admin . Sin embargo, no puedo otorgar tales funciones a mi ServiceAccount de albacea debido a los requisitos de cumplimiento. Solo puedo suplantar al propietario de la cuenta de servicio y ENTONCES hacer lo que quiera a través de ella, no directamente.
Si echa un vistazo a su archivo kubeconfig en esta ubicación ~/.kube/config , puede ver la lista de autorización y los secretos, como
- name: gke_gdglyon-cloudrun_us-central1-c_knative user: auth-provider: config: access-token: ya29.<secret>-9XQmaTQodj4kS39w cmd-args: config config-helper --format=json cmd-path: /usr/lib/google-cloud-sdk/bin/gcloud expiry: "2020-08-25T17:48:39Z" expiry-key: '{.credential.token_expiry}' token-key: '{.credential.access_token}' name: gcp Verá referencias externas ( expiry-key y token-key ) y un cmd-path . La ruta del comando es interesante porque cuando se necesita generar un nuevo token, se llamará.
Sin embargo, ve alguna mención de la suplantación. Debe agregarlo en la ruta del comando, para que se use de manera predeterminada. Para esto, agréguelo en su configuración de esta manera:
gcloud config set auth/impersonate_service_account owner@rakib-example-project.iam.gserviceaccount.comAhora, cada uso de gcloud CLI usará la cuenta de servicio de suplantación, y es lo que desea generar un access_token válido para llegar a su clúster de GKE.