Configure Impersonated GKE Cluster Access For kubectl

Normally you use the gcloud container clusters get-credentials-command to configure GKE cluster access. Including the –impersonate-service-account flag, however, doesn’t persist the service account impersonation to the GKE cluster credentials. Here’s why.

GKE Cluster Access Configuration

Cluster access configuration is stored in your kubeconfig-file. And – as you might have guessed – gcloud container clusters get-credentials updates this file with GKE cluster access details:

- name: gke_[project-id]_[location]_[cluster-name]
  user:
    auth-provider:
      config:
        access-token: ya29.....
        cmd-args: config config-helper --format=json
        cmd-path: gcloud
        expiry: "2021-02-12T13:47:53Z"
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

The access token is used to authenticate and access the GKE cluster. Once expired, the token is refreshed using the command gcloud config config-helper –format=json.

Configuring Impersonated GKE Cluster Access

Interestingly gcloud container clusters get-credentials --impersonate-service-acount xxx@...gserviceaccount.com doesn’t change the token refresh command. Thus, when the access token is refreshed, the command gcloud config config-helper is executed without the --impersonate-service-account-flag. To persist the impersonation flag, it has to be configured as a default gcloud argument using gcloud config set auth/impersonate_service_account.

gcloud config set auth/impersonate_service_account xxx@...gserviceaccount.com
gcloud container clusters get-credentials my-cluster
kubectl get pods

Tip Use a separate gcloud configuration for service account impersonation. gcloud config configurations create impersonated

Conclusion

The GKE cluster access token is requested using a different gcloud command. Therefore, persist the --impersonate-service-account-flag to your gcloud configuration to configure impersonated GKE cluster access.