10 commentaires
hello. problème classique ça peut venir de plusieurs choses
déjà est-ce que les service accounts de tes pods ont bien les droits pour s'authentifier ? vérifie tes roles vault, surtout bound_service_account_names et bound_service_account_namespaces. le token k8s est passé au rôle, si c'est pas le bon nom ou namespace ça match pas
les roles sont ok j'ai revérifié. les pods utilisent tous un service account spécifique pour chaque app et c bien mappé dans vault
par contre on a des ttl et max_ttl sur les roles vault. ttl à 1h max_ttl à 2h. est-ce que ça peut être lié à ça si les pods ne renouvellent pas leur token à temps ?
oui totalement. si un pod rate son renouvellement (genre le client vault est pas configuré pour le faire auto ou si le pod est trop occupé) le token expire. et si le max_ttl est atteint il doit se ré-authentifier complètement avec le token JWT de k8s
vérifie le clock skew entre tes nœuds k8s et ton serveur vault. si les horloges sont pas synchronisées ça peut foirer la validation du JWT. un décalage de quelques secondes suffit parfois
le clock skew j'y avais pas pensé. mais on a ntp sur tous les serveurs normalement je vais vérifier
j'ai aussi des erreurs connection refused de temps en temps quand un pod essaie de contacter vault. ça ça sent la config réseau k8s non ?
connection refused c'est bizarre si ça marche par intermittence. t'as un load balancer devant vault ? c'est peut-être lui qui a des soucis ou une saturation des connexions sur vault
regarde les logs de vault en mode debug vault server -log-level=debug pendant une période où ça déconne pour voir les erreurs exactes lors de l'authentification des pods
ok j'ai mis vault en debug. je vois des erreurs jwt validation failed: expiration dans les logs de vault quand les pods ont des soucis
et on a un lb oui mais c'est un classic elb donc normalement robuste
expiration jwt c'est clair c'est un problème de temps. soit le token k8s est expiré quand vault le reçoit soit y'a un décalage d'horloge qui fait que vault pense que c'est expiré alors que ça l'est pas vraiment
re-re-vérifie ntp sur tout ton cluster k8s et sur la vm ou conteneur qui héberge vault. même quelques secondes c'est critique pour les JWT
j'ai fait un tour sur tous les noeuds k8s et sur la vm vault. certains noeuds k8s avaient un offset de 5-10 secondes avec ntp qui galérait à se sync. et la vm vault avait 2 secondes de décalage
j'ai forcé la resync et relancé les pods incriminés. on va voir mais ça a l'air plus stable
bien vu ! le temps c'est la clé pour les systèmes distribués et la sécurité. les JWT sont très sensibles aux horloges
pour les connection refused si ça persiste après le ntp, ça pourrait être les limites de connexion sur vault ou le LB qui déconne de temps en temps
clairement c'était le ntp de merde. depuis la resync plus une seule erreur jwt validation. les connection refused ont disparu aussi c ptete juste une conséquence indirecte des échecs d'auth qui spammaient vault
merci pour l'aide ça m'a sauvé
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la compagnie
on utilise vault pour gérer les secrets sur k8s. on a l'auth method kubernetes configurée nos pods récupèrent bien les tokens vault et les secrets. mais régulièrement certains pods ont des soucis d'auth. ils essaient de se ré-authentifier mais ça foire le token est invalide ou expiré prématurément
ça nous met la pagaille des idées d'où ça peut venir ?