9 commentaires
hello le ttl et max_ttl sur le role définissent la durée de vie maximale que tu peux demander. mais le token que tu obtiens a aussi sa propre durée de vie définie par l'auth method elle-même ou la policy du token. tu as checké la policy attachée au token ?
y'a aussi le lease duration par défaut de vault lui-même qui peut override tout ça. check le vault read sys/config/lease. et assure-toi que tes pipelines demandent bien un token avec un ttl spécifique lors de l'authentification si c'est supporté par github actions et ton auth method
et ton jwt_exp_leeway est comment ? si t'as une grosse asymétrie d'horloge entre ton github runner et vault ça peut jouer sur la validité du token
si c'est un token issu d'une auth method, la durée de vie finale c'est le MIN entre le ttl du role, le ttl de la policy, la ttl de l'auth method mount, et le system default lease. c'est souvent le system default lease qui surprend. regarde aussi si t'as pas des renewable = false quelque part sur la policy ou le role
vault read sys/mounts/auth/jwt/tune ça te donnera les default_lease_ttl et max_lease_ttl pour cette mount spécifique. c souvent là qu'est le coupable quand le role ttl ne semble pas fonctionner
top ! content que ça aide. les ttls dans vault c'est un peu un labyrinthe au début haha
Laisser une réponse
Vous devez être connecté pour poster un message !
salut tout le monde ! on utilise vault pour récupérer des secrets dans nos pipelines ci/cd. le problème c'est que nos tokens vault expirent trop vite (genre 5 min) et nos jobs qui durent plus longtemps se retrouvent sans accès aux secrets. j'ai bien mis une ttl plus longue sur le role mais ça ne semble pas prendre. c'est pour un role jwt/oidc configuré avec github actions
une idée de ce que je loupe ? c'est mega relou de relancer les jobs