Google Kubernetes Engine: Identity Service for GKE is not supported from GKE 1.37, move to Workforce Identity Federation before upgrading

Google Kubernetes Engine: Identity Service for GKE is not supported from GKE 1.37, move to Workforce Identity Federation before upgrading

5 October 2026 — Google's Kubernetes Engine release notes for 5 October 2026 set out the end of Identity Service for GKE, the add-on that lets people sign in to clusters with an external identity provider such as an OIDC or LDAP directory. The service is deprecated in GKE 1.36 and earlier, is not available to Google Cloud organisations created on or after 1 July 2025, and is not supported at all from GKE 1.37. Google's instruction is to disable it and migrate to Workforce Identity Federation before upgrading a cluster to 1.37 or later.

Not yet independently verified. Single source: Google's own GKE release notes. No independent report had been found on 6 October 2026. The release-notes page was read on that day; the deprecation itself dates from 1 July 2026 according to Google. We will update this when it can be confirmed, and remove this note.

What changed

Identity Service for GKE has been the route for organisations that wanted engineers to authenticate to Kubernetes with their corporate identity provider rather than Google accounts. Google is now pointing everyone to Workforce Identity Federation, its general mechanism for letting users from an external identity provider access Google Cloud resources. The release note makes the version boundary explicit: the add-on works on 1.36 and earlier, and a 1.37 cluster cannot use it.

Who is affected

Teams that run GKE clusters with Identity Service enabled, typically those using Okta, Microsoft Entra ID, Ping or an LDAP directory for kubectl access. The practical risk is an upgrade: GKE upgrades minor versions automatically on release channels, so a cluster can reach 1.37 on Google's schedule rather than the team's. If Identity Service is still the sign-in route at that point, engineers and automation that depend on it lose access.

What to do

1. Find every cluster with Identity Service for GKE enabled, across all projects.
2. Read Google's migration guidance and set up Workforce Identity Federation with your identity provider, including the group mappings your role-based access control relies on.
3. Test sign-in and role bindings on a non-production cluster before switching production.
4. Disable Identity Service once users and CI pipelines authenticate through the new route.
5. Until the migration is done, check each cluster's release channel and maintenance exclusions so that an automatic upgrade to 1.37 does not arrive first.

Why it matters

Access to Kubernetes is often wired up once and forgotten. A deprecation tied to a version number, rather than a calendar date, is easy to miss because nothing changes until the upgrade happens. Platform teams that review their identity set-up now control the timing; teams that do not will find out during an upgrade.

Company profile on TrustList: Google Cloud

Sources

• Google Kubernetes Engine release notes (5 October 2026) — 5 October 2026