Introduction

Using kubectl against a GKE cluster with a service account is really an authentication-and-authorization problem with two identity layers. First, kubectl must authenticate to GKE using Google Cloud credentials, and then that authenticated identity must be authorized to perform Kubernetes actions through IAM and often RBAC.

Do Not Confuse Google Cloud and Kubernetes Service Accounts

The first important distinction is between:

• a Google Cloud service account, used to authenticate to Google Cloud and GKE
• a Kubernetes service account, used by workloads running inside the cluster

When people ask about using service account credentials with kubectl, they usually mean a Google Cloud service account, not a Kubernetes service account. kubectl runs outside the cluster, so it needs Google Cloud identity first.

Install the GKE Auth Plugin

Current GKE access for kubectl depends on the gke-gcloud-auth-plugin. Without it, kubectl can fail even if your Google Cloud credentials are otherwise correct.

Check whether it is installed:

gke-gcloud-auth-plugin --version

If needed, install it through the Google Cloud CLI component flow:

gcloud components install gke-gcloud-auth-plugin

This plugin is what lets kubectl obtain the credentials needed to talk to the GKE API server.

Authenticate with a Google Cloud Service Account

If you are using a JSON key, activate the service account in gcloud first:

gcloud auth activate-service-account [email protected] \
  --key-file=/secure/path/key.json

Then fetch cluster credentials into your kubeconfig:

gcloud container clusters get-credentials my-cluster \
  --location=us-central1 \
  --project=my-project

After that, ordinary kubectl commands use the credentials configured by the GKE auth plugin:

kubectl get namespaces
kubectl get pods -A

For automation, this is the standard pattern when a key-based service account is the chosen credential source.

Prefer Impersonation or Attached Identity When Possible

JSON keys work, but they are not the most secure long-term option. If your environment supports it, service account impersonation or a workload-attached identity is usually better because you avoid distributing long-lived keys.

A simple impersonation flow looks like this:

1gcloud config set auth/impersonate_service_account \
2  [email protected]
3
4gcloud container clusters get-credentials my-cluster \
5  --location=us-central1 \
6  --project=my-project

That way, gcloud uses short-lived credentials derived from the service account instead of relying on a raw key file sitting on disk.

Authentication Is Not Authorization

Successfully running get-credentials does not guarantee the service account can do anything useful in the cluster. The identity still needs permission.

At the Google Cloud level, the account needs enough IAM permission to retrieve cluster credentials and access the cluster endpoint. At the Kubernetes level, it may also need RBAC bindings for the operations you want to run.

A minimal RBAC example might look like this:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: ci-bot-view
5subjects:
6  - kind: User
7    name: ci-bot@my-project.iam.gserviceaccount.com
8roleRef:
9  apiGroup: rbac.authorization.k8s.io
10  kind: ClusterRole
11  name: view

Then apply it with:

kubectl apply -f ci-bot-view.yaml

The important detail is that the subject name is the Google identity email seen by the cluster.

Verify Which Identity kubectl Is Using

When debugging access issues, inspect the current kubeconfig context and test a read-only command first:

kubectl config current-context
kubectl auth can-i get pods --all-namespaces

If authentication works but can-i returns no, the problem is authorization, not credentials.

Common Pitfalls

One common mistake is confusing Google Cloud service accounts with Kubernetes service accounts. They solve different identity problems and are not interchangeable in kubectl setup.

Another is forgetting the gke-gcloud-auth-plugin. Modern GKE client access depends on it, so old kubeconfig assumptions can break unexpectedly.

Developers also sometimes authenticate successfully with gcloud but forget that the service account still needs IAM and possibly Kubernetes RBAC permissions to do anything meaningful.

Finally, avoid spreading raw JSON keys unless you truly need them. Service account impersonation or attached service-account identity is usually a cleaner and safer automation path.

Summary

• 'kubectl access to GKE uses Google Cloud identity, not an in-cluster Kubernetes service account.'
• Install and use the gke-gcloud-auth-plugin for current GKE client authentication.
• Authenticate with a Google Cloud service account, then run gcloud container clusters get-credentials.
• Grant both cloud-side access and cluster-side authorization where needed.
• Prefer impersonation or attached identity over long-lived JSON keys when possible.