12 commentaires
check bien que ton service account existe dans le bon namespace et que le nom est exact même la casse. et surtout si ta politique 'my-app-policy' a les bons chemins et les bonnes capabilités pour accéder au secret en question. des fois c'est juste un chemin /data/truc au lieu de /secret/data/truc si c'est un kv v2
oui le service account est là et la casse c bon. pour la policy j'ai mis un chemin générique genre path "secret/data/my-app/*" { capabilities = ["read"] }. le secret est bien sous secret/data/my-app/config
oui les logs d'audit c'est la vie. aussi quand tu crées le rôle k8s dans vault t'as bien spécifié le jwt_verifier_public_keys ou le kubernetes_host et le ca_cert du cluster k8s ? c'est crucial pour que vault puisse valider les tokens service account
j'ai bien mis le kubernetes_host et le ca_cert lors de l'activation de la méthode d'auth. et pour les logs d'audit ouais je vois des permission denied mais juste le policy name et le chemin. pas plus de détails
si le policy name est là ça veut dire que le token est bien authentifié et a reçu la policy. le problème est vraiment dans la policy elle-même. t'es sûr qu'il n'y a pas d'autres policies par défaut qui viennent override ? ou un chemin secret/meta/my-app au lieu de secret/data/my-app si c'est un KV secret v2
très bonne remarque pour KV v2. pour un secret "foo" dans "secret/my-app" via kv v2, le chemin est "secret/data/my-app/foo". ta policy devrait être path "secret/data/my-app/*" { capabilities = ["read"] }. Mais si tu lis "secret/my-app/foo", vault ira chercher "secret/data/my-app/foo" pour la policy.
exact et si tu accèdes au metadata du secret genre vault kv get -metadata secret/my-app/config ça demande des capabilités sur secret/metadata/* et pas secret/data/*. faut pas se tromper de chemin
une autre piste si t'as plusieurs bound_service_account_names ou namespaces dans le rôle, vérifie que la wildcard * est bien gérée ou que les noms sont précis. des fois c'est un mismatch subtil là-dessus
et ton cluster k8s est bien configuré pour permettre à vault de valider les tokens ? y a un champ token_reviewer_jwt dans la config du auth/kubernetes method qui doit être un token d'un service account avec les droits system:auth-delegator pour que vault puisse s'auto-authentifier auprès de k8s et valider les tokens des pods
Ah oui le token_reviewer_jwt c'est critique si t'es pas sur un setup simple. Souvent l'erreur vient de là ou d'un kubernetes_ca_cert qui n'est pas bon ou n'est pas encodé correctement en base64
AH MAIS OUI ! C'est un KV v2 et j'étais persuadé que le chemin pour la policy était juste secret/my-app/config. Quand je faisais un vault read secret/my-app/config ça marchait en local avec mon token admin. En fait il fallait bien le /data/. J'ai corrigé ma policy pour secret/data/my-app/* et ça marche ! Merci énormément pour l'aide
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut ! J'ai un souci avec Vault sur k8s. J'essaye d'authentifier mes pods via le mécanisme Kubernetes Service Account token. J'ai bien configuré le auth method dans Vault, la politique et le rôle. Mon pod arrive à générer un token Vault mais quand il essaye d'accéder à un secret bah c'est permission denied. J'ai l'impression qu'il y a un truc qui cloche avec les policies attachées ou le mapping du role.