Problème d'accès Vault avec Kubernetes via Service Account

Question

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.

# Exemple de config du rôle Vault
path "auth/kubernetes/role/my-app" {
  bound_service_account_names = "my-service-account"
  bound_service_account_namespaces = "my-namespace"
  policies = ["my-app-policy"]
  ttl = "1h"
}

thibault-dominique · Answer

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

william-perrier · Answer

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`

ldumont · Answer

ok alors le chemin est bon. t'as vérifié les logs d'audit de Vault ? ça te donnera l'info exacte sur quel chemin et quelle capabilité a été refusée. c'est super utile pour debugger les policies

chevallier-paulette · Answer

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

william-perrier · Answer

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

thibault-dominique · Answer

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

ldumont · Answer

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.

chevallier-paulette · Answer

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

thibault-dominique · Answer

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

ldumont · Answer

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

Problème d'accès Vault avec Kubernetes via Service Account

Commentaires

Laisser une réponse

Comprendre et utiliser Packetbeat dans la stack ELK

Les variables Input et Output

Les variables d'environnement dans Kubernetes

Rejoindre la communauté