5 commentaires
ouais j'ai regardé les logs vault. y'a un permission denied on "auth/approle/login" sur le rôle. pourtant le rôle existe et le secret_id est bon
attends "permission denied on auth/approle/login" ça c'est pas une policy de secret ça. ça veut dire que le client (ton runner) n'a pas le droit de faire le login lui-même avec son role_id et secret_id. la policy attachée au role_id doit avoir un chemin genre
path "auth/approle/login" {
capabilities = ["create", "read", "update"]
}
précisément. et vérifie aussi que ton rôle approle a bien le
bound_cidrs configuré si tu l'utilises des fois ça bloque des ips non autorisées ou des token_bound_cidrs si ton token généré a aussi une restriction ip
vous aviez raison ! la policy de mon AppRole n'avait pas les capabilities de create/read/update sur "auth/approle/login". j'avais mis que les permissions pour les secrets. après ajout c'est passé nickel. merci pour l'aide précieuse
Laisser une réponse
Vous devez être connecté pour poster un message !
hello j'ai un pb avec vault nos runners gitlab sur k8s essaient de récupérer des secrets avec AppRole mais ça foire tout le temps avec permission denied. j'ai bien configuré le AppRole le role_id et le secret_id sont générés et le runner les utilise mais ça passe pas. les politiques vault sont censées donner accès