GKE : Identity Service disparaît avec la version 1.37

Google a rappelé le 5 octobre dans les notes de version de Google Kubernetes Engine (GKE) que la fonction Identity Service for GKE n'est plus prise en charge à partir de la version 1.37. Les clusters qui s'en servent pour authentifier leurs utilisateurs via un fournisseur d'identité tiers doivent migrer vers Workforce Identity Federation avant de passer à cette version, faute de quoi l'authentification cessera de fonctionner.

Un abandon en plusieurs étapes

Identity Service for GKE permet de connecter un cluster à un fournisseur d'identité externe pour authentifier les utilisateurs qui accèdent à l'API Kubernetes. Selon la documentation de Google, son retrait s'étale sur plusieurs étapes :

• les organisations Google Cloud créées depuis le 1er juillet 2025 n'ont déjà plus accès à la fonction ;
• depuis le 1er juillet 2026, elle est dépréciée dans GKE 1.36 et les versions antérieures, qui peuvent encore l'utiliser jusqu'à la fin de support de chaque version mineure ;
• à partir de GKE 1.37, aucun cluster ne la prend en charge, quelle que soit l'organisation.

Des mises à jour bloquées, pas indéfiniment

Pour éviter une coupure brutale, GKE bloque les mises à jour automatiques et manuelles vers la version 1.37 des clusters qui utilisent encore Identity Service. Ce gel n'est que temporaire : les mises à jour automatiques restent suspendues jusqu'à la fin du support standard de la version en cours, ou jusqu'à la fin du support étendu pour les clusters inscrits au canal Extended. GKE met alors le cluster à jour d'office et, si la fonction est toujours activée, l'authentification échoue.

Google ne donne pas de date butoir unique : elle dépend du calendrier de support de chaque version mineure, publié dans le planning des versions de GKE. Les équipes qui ont repoussé la montée vers Kubernetes 1.37 ont donc intérêt à vérifier leurs clusters dès maintenant.

Comment migrer vers Workforce Identity Federation

Le remplaçant désigné, Workforce Identity Federation, prend en charge plusieurs protocoles et n'installe aucun composant dans le cluster. La procédure décrite par Google comprend six étapes :

1. configurer Workforce Identity Federation pour l'organisation et le fournisseur d'identité externe ;
2. adapter les manifestes RoleBinding et ClusterRoleBinding à la nouvelle syntaxe d'identifiants, à la main ou avec l'outil gke-identity-service-migrator du dépôt GoogleCloudPlatform/gke-utilities ;
3. appliquer ces manifestes ;
4. vérifier que les utilisateurs accèdent aux mêmes ressources via la nouvelle méthode ;
5. supprimer les anciennes liaisons RBAC devenues inutiles ;
6. désactiver la fonction avec gcloud container clusters update CLUSTER_NAME --no-enable-identity-service.

Le principal changement porte sur les règles RBAC : un utilisateur ou un groupe n'est plus désigné par un simple nom, comme une adresse e-mail, mais par un identifiant principal:// ou principalSet:// qui inclut le chemin du pool d'identités.

D'autres changements à surveiller

Les notes de version d'octobre signalent d'autres points d'attention. Depuis GKE 1.36, CoreDNS est le moteur kube-dns par défaut. Il renvoie une erreur NXDOMAIN pour les requêtes DNS sur l'adresse IP d'un Pod qui visent un espace de noms inexistant, ce que l'ancienne implémentation ne vérifiait pas. Google recommande de passer aux enregistrements DNS des services headless.

Depuis le 16 octobre, enfin, GKE peut mettre à jour les nœuds des pools CPU de GKE Standard en conservant la machine virtuelle Compute Engine existante, et donc sa capacité de calcul. Ce mode s'applique aux mises à jour par surge dont le paramètre maxUnavailable est supérieur à zéro, sur toutes les versions de GKE.