Vault agent auto-auth mTLS plante à la reconnexion

salut. déjà tu utilises tls_client_certificate. c'est pour l'auth mutualisée entre l'agent et vault server. es-tu sûr que tes certificats client ne sont pas expirés ou révoqués ?

non les certs sont valides. on utilise une CA interne. j'ai checké les dates d'expiration. ils sont bons pour plusieurs mois

et le mount_path auth/kubernetes ça c'est l'auth kube. le mTLS c'est plutot sur listener.tcp.tls_client_certificate_required. ton config snippet c'est plus pour l'auth du pod. tu confonds ptete le mTLS sur la connexion à Vault et l'auth du pod avec un cert

ah oui c'est possible que je mélange les deux. on veut bien que le pod s'authentifie auprès de vault avec son identité k8s ET que la connexion entre le pod et vault soit sécurisée avec mTLS.

ok si tu veux mTLS sur la connexion elle-même il faut que ton listener vault soit configuré avec tls_client_certificate_required = true et que l'agent présente un cert valide pour ça. le tls_client_certificate dans la config d'auto_auth.method.config est pour l'auth k8s avec un cert comme preuve d'identité du pod, pas pour la connexion TLS

je vois la nuance. le listener vault a bien tls_client_certificate_required = true. l'agent présente bien le cert. le problème c'est que ça marche au début et ça échoue après un temps

ça sent la désynchronisation d'horloge. est-ce que tes pods et ton serveur vault ont leur horloge synchronisée avec un ntp ? même un léger décalage peut faire rater les handshakes mtls

ouais j'ai déjà eu ça avec kubernetes. on utilise chrony partout. je vais revérifier les logs ntp

check aussi les logs du serveur vault au moment où l'agent rate son renouvellement. tu devrais voir des erreurs liées au TLS ou au certificat client. x509: certificate has expired or is not yet valid ou client certificate required but not provided

j'ai des logs vault qui disent permission denied mais rien sur le TLS ou le cert. c'est après le handshake.

si c'est permission denied après le handshake, c'est que le mTLS lui-même est ok. le problème est ailleurs. l'agent ne parvient pas à obtenir un nouveau JWT pour la méthode k8s ou son rôle n'est plus autorisé

le jwt c'est le token service account du pod. il est injecté par k8s. le rôle my-app est censé être ok

t'as pas de mutation de pods via un webhook qui pourrait modifier le service account token ou le monter sur un path différent après le déploiement initial ?

non rien de ça. les tokens sont stables. je regarde côté kubernetes logs pour voir si l'api server voit des erreurs quand vault demande le token review

le service account token k8s a une durée de vie limitée. si l'agent vault n'est pas configuré pour recharger le JWT ou si le pod n'a pas les droits pour re-fetch un nouveau token service account, ça peut foirer

le jwt n'est pas sensé être rechargé automatiquement si il est monté depuis le path standard /var/run/secrets/kubernetes.io/serviceaccount/token ?

l'agent vault peut le faire oui si tu lui donnes le bon chemin. mais si ton jwt dans la config est un string statique au lieu d'un path vers le fichier du service account, ça marchera pas. il faut jwt_path: "/var/run/secrets/kubernetes.io/serviceaccount/token" pas jwt: "..."

HOLY SHIT ! c'était ça ! j'avais copié-collé un exemple où le JWT était mis en dur pour le test et j'ai pas mis le path après. du coup l'agent utilisait toujours un vieux JWT expiré pour le renouvellement. je viens de changer en jwt_path et ça refonctionne. j'ai l'impression d'être con.

pas de souci c'est un piège classique avec la config vault agent. surtout avec le mix kubernetes et mTLS. bien joué d'avoir trouvé

ouais merci à vous deux ! ça m'a sauvé un week-end de débug intensif. thx pour les pistes c'était super utile