← Back to posts
certifications 9 Nov 2026

GCP ACE: Managing Identity in GKE — GKE Identity Service and Fleet Workload Identity

gcpacecertificationkubernetesgkefleetsidentity

The RBAC/Workload Identity article covered identity inside a single cluster, and the Fleets and Teams article showed team members reaching fleet clusters through the Connect gateway as Google Cloud identities. This article covers authenticating to a fleet of clusters as your organization’s own users, not necessarily Google ones, plus the fleet-scale version of Workload Identity.

Read this first: Identity Service for GKE is being retired on Google Cloud

The feature described in the next section is on its way out for GKE clusters running on Google Cloud:

DateWhat happens
July 1, 2025Not available in Google Cloud organizations created on or after this date
July 1, 2026Deprecated in GKE 1.36 and earlier (usable until that minor version’s end of support)
GKE 1.37+Not supported. GKE blocks upgrades to 1.37 for clusters that still use it; if a cluster is force-upgraded at end of support with it still enabled, authentication fails

Google’s replacement for authenticating with a third-party IdP is Workforce Identity Federation, which is integrated with IAM, supports multiple protocols, and installs nothing in the cluster. Principals change format too: instead of a plain [email protected], you reference principal://iam.googleapis.com/locations/global/workforcePools/... identifiers. The deprecation only covers GKE on Google Cloud; the GKE Identity Service used with the Connect gateway and Google Distributed Cloud (software only) isn’t deprecated.

For the exam, recognize Identity Service for GKE as the historical answer to “bring your own IdP”, and Workforce Identity Federation as the current one.

GKE Identity Service — bringing your own identity provider

Many organizations already run an identity provider (Okta, Active Directory via LDAP, any OIDC-compliant IdP) and don’t want a second, separate identity system just for Kubernetes access. GKE Identity Service lets users authenticate to GKE clusters using that existing provider instead of (or alongside) a Google identity.

The fleet-level version of this feature runs a controller that manages authentication configuration across every cluster in the fleet from one place — you configure the identity provider once, and GKE Identity Service’s controller reconciles every fleet member to match. If someone changes a cluster’s auth config locally, the controller resets it back to the fleet-level configuration — this is centrally managed, not a per-cluster setting you can quietly drift away from.

Setting it up

gcloud config set project FLEET_HOST_PROJECT_ID
# Enable gkehub.googleapis.com and container.googleapis.com first
# Requires roles/gkehub.admin on the fleet host project

gcloud container fleet identity-service enable

Provider details go into a ClientConfig custom resource. For OIDC:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      issuerURI: ISSUER_URI
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: SCOPES
      userClaim: USER_CLAIM

(LDAP uses the same ClientConfig shape, with an ldap block instead — server, user, group, and serviceAccount sections.)

gcloud container fleet identity-service apply \
    --membership=CLUSTER_NAME \
    --config=auth-config.yaml

gcloud container fleet identity-service describe

Multiple providers can be configured, and they’re tried in order — authentication stops at the first one that succeeds. This is useful during a migration between identity providers, or for supporting both an internal corporate IdP and an external partner IdP without maintaining two separate cluster configs.

Fleet-default configuration — so new clusters get this automatically on registration:

gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME   # for existing clusters

Before applying any of this: any existing cluster-level OIDC configuration gets overwritten by the fleet config, and an existing configuration for an unsupported provider makes setup fail outright until it’s removed — this isn’t additive by default.

Once configured, authenticated users can reach clusters through the Connect gateway (introduced in the Fleets and Teams article) — GKE Identity Service controls who can authenticate; the Connect gateway is how the resulting session reaches the cluster.

Fleet Workload Identity Federation

The regular Workload Identity Federation article earlier in this series covered a single cluster’s workload pool (PROJECT_ID.svc.id.goog), letting a Pod’s Kubernetes service account impersonate a Google Cloud IAM service account. Fleet Workload Identity is the same mechanism, generalized across every cluster in the fleet.

The practical difference: instead of each cluster having its own separate workload identity pool tied to its own project, a fleet-wide workload identity pool lets a workload’s identity be recognized consistently no matter which cluster in the fleet it’s actually running on. This matters because of identity sameness (from the Fleets introduction article): the same (namespace, service account) pair on different clusters is treated as one identity, so a GSA binding set up once applies to that workload wherever in the fleet it’s scheduled — you don’t re-bind it per cluster.

This is also what underlies cross-cluster authorization in Cloud Service Mesh — a workload’s identity staying consistent across clusters is a prerequisite for the mesh’s service-to-service AuthorizationPolicy rules (from the Service Mesh Security article) to mean the same thing fleet-wide, not just within one cluster.

Exam Takeaways

Sources

↗ LinkedIn