Cette rubrique décrit l'impact, les détails et les solutions liés à l'expiration des jetons ServiceAccount dans les clusters Kubernetes 1.22 et versions ultérieures. À partir de Kubernetes 1.22, les jetons ServiceAccount ont une durée de validité d'un an et le composant kubelet les actualise périodiquement. Toutefois, si une application utilise une version de client-go antérieure à la v11.0.0 ou à la v0.15.0, le client ne recharge pas automatiquement le jeton actualisé. Cela peut entraîner des erreurs d'authentification à l'expiration du jeton.
Pour renforcer la sécurité, Kubernetes 1.21 a activé par défaut la fonctionnalité BoundServiceAccountTokenVolume, qui impose une date d'expiration des jetons, met en œuvre un mécanisme d'actualisation automatique et invalide les jetons après la suppression du Pod associé. Lorsqu'une application utilise client-go v11.0.0, v0.15.0 ou une version ultérieure, le kubelet actualise périodiquement le jeton et le client le recharge depuis le volume monté. Pour assurer la rétrocompatibilité, Kubernetes accorde une période de grâce d'un an pendant laquelle les jetons expirés restent utilisables. Cependant, passé ce délai, les clients utilisant une version de client-go antérieure à la v11.0.0 ou à la v0.15.0 ne rechargent pas automatiquement le jeton. Lorsque le jeton expire, les erreurs suivantes apparaissent :
# The component log.
Error listing resources error=Unauthorized
# The access log of the Kubernetes API server of the cluster.
"Unable to authenticate the request" err="[invalid bearer token, Token has expired.]"Redémarrez le Pod du composant pour forcer client-go à lire le nouveau jeton.
Périmètre d'impact
Ce problème concerne les applications qui utilisent une version de client-go antérieure à la v11.0.0 ou à la v0.15.0 dans les clusters Kubernetes 1.22 et versions ultérieures.
Impact de l'expiration
Dans les clusters Kubernetes 1.22 et versions ultérieures, les applications utilisant une version de
client-goantérieure à la v11.0.0 ou à la v0.15.0 rencontrent des échecs d'authentification après l'expiration de la période de grâce d'un an, car elles ne peuvent pas recharger automatiquement le jeton.Lorsque vous mettez à jour un cluster vers Kubernetes 1.22 ou une version ultérieure, les applications existantes dotées de versions de
client-goantérieures à la v11.0.0 ou à la v0.15.0 ne parviennent plus à s'authentifier au bout d'un an sans redémarrage.
Solutions
Pour les applications utilisant des modules complémentaires ACK
Les modules complémentaires Container Service for Kubernetes (ACK) intègrent des versions plus récentes de client-go. Si votre application utilise un module complémentaire ACK, vous pouvez mettre à niveau le module complémentaire pour résoudre ce problème.
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .
Sur la page Add-ons, recherchez le composant que vous souhaitez mettre à jour et cliquez sur Upgrade.
Pour les autres applications
À court terme, redémarrez le Pod de l'application pour rétablir rapidement le service. À long terme, mettez à niveau la bibliothèque client-go de votre application vers la v11.0.0, la v0.15.0 ou une version ultérieure. Cela permet à l'application de recharger automatiquement le jeton ServiceAccount.