Vault : policies et contrôle d'accès (ACL)

Une fois authentifié, Vault détermine les permissions via les policies. Chaque policy définit des capabilities (read, write, delete…) sur des paths (secret/data/*, auth/token/…).

Deny by default et modèle d’évaluation

Vault applique un modèle deny by default : sans policy explicite, tout accès est refusé. Quand plusieurs règles peuvent correspondre à un path :

1. Vault choisit d’abord la règle la plus spécifique (priority matching)
2. Si exactement le même pattern est défini dans plusieurs policies attachées au token, les capabilities se cumulent
3. La capability deny reste toujours prioritaire

Ce n'est pas purement additif

Contrairement à une idée reçue, les permissions ne s’additionnent pas aveuglément entre tous les patterns. Vault évalue d’abord quel pattern s’applique (le plus spécifique gagne), puis fait l’union des capabilities uniquement si ce même pattern existe dans plusieurs policies.

Prérequis

Authentification Configurer userpass ou AppRole

Secrets KV Stocker des secrets pour tester les policies

• Vault installé et démarré
• Accès root ou admin pour créer des policies

Policies intégrées

Vault inclut deux policies intégrées :

root

La policy root donne un accès total à Vault. Le token root doit être réservé à l’initialisation ou aux situations d’urgence.

Ne pas utiliser root en production

Le token root ne sert qu’à l’initialisation. Créez des admins avec des policies dédiées, puis révoquez le token root.

default

La policy default est attachée à la plupart des tokens par défaut. Elle fournit généralement un socle minimal pour que le token puisse se consulter et gérer certaines opérations de base (cubbyhole, renouvellement…).

Contenu modifiable

Le contenu exact de la policy default peut être adapté sur votre instance. Ce n’est pas une constante immuable.

Anatomie d’une policy

Une policy est écrite en HCL (HashiCorp Configuration Language) ou JSON :

# Policy pour l'équipe développement
path "secret/data/dev/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "secret/data/shared/config" {
  capabilities = ["read"]
}

path "secret/metadata/dev/*" {
  capabilities = ["list", "read", "delete"]
}

Capabilities disponibles

Capability	Description	Verbes HTTP
create	Créer une nouvelle entrée	POST/PUT
read	Lire une entrée	GET
update	Modifier une entrée existante	POST/PUT
delete	Supprimer une entrée	DELETE
list	Lister les entrées	LIST
patch	Modification partielle (si l’endpoint le supporte)	PATCH
sudo	Accès aux paths protégés (root-protected)	-
deny	Refuser explicitement (prioritaire sur tout)	-

Glissez pour voir

patch et recover

patch permet des modifications partielles sur les endpoints qui le supportent (ex: KV v2 metadata). Certains endpoints supportent aussi recover pour la récupération de données supprimées.

create vs update

Avec KV v2, utilisez les deux pour écrire : create pour la première version, update pour les suivantes. En pratique, mettez les deux.

Paths pour KV v2

Avec le moteur KV v2, les paths sont structurés ainsi :

Path	Usage
secret/data/*	Lecture/écriture des secrets
secret/metadata/*	Métadonnées, versions, suppression soft
secret/delete/*	Suppression soft de versions
secret/undelete/*	Restauration de versions
secret/destroy/*	Suppression définitive

Glissez pour voir

Priority matching : comment Vault choisit la règle

Quand plusieurs patterns peuvent correspondre à un path, Vault applique une logique de priorité pour déterminer lequel utiliser.

Règles de priorité

1. Si le premier wildcard (+ ou *) apparaît plus tôt dans le path, la règle est moins prioritaire
2. Une règle finissant par * est moins prioritaire qu’une sans wildcard
3. Plus il y a de segments +, plus la priorité baisse
4. Une règle plus courte est moins prioritaire
5. En dernier recours : comparaison lexicographique

Exemple de priority matching

# Règle générale : lecture sur tout secret/*
path "secret/*" {
  capabilities = ["read"]
}

# Règle spécifique : deny sur prod
path "secret/data/prod/*" {
  capabilities = ["deny"]
}

Pour le path secret/data/prod/app :

• Les deux patterns matchent
• secret/data/prod/* est plus spécifique (wildcard plus tard)
• Vault applique deny → accès refusé

Tester avec vault token capabilities

vault token capabilities secret/data/prod/app
# deny

Union des capabilities (même pattern)

L’union ne se produit que si le même pattern exact existe dans plusieurs policies attachées au token :

# Policy A
path "secret/data/shared/*" {
  capabilities = ["read"]
}

# Policy B
path "secret/data/shared/*" {
  capabilities = ["list"]
}

Si un token a les deux policies, il obtient ["read", "list"] sur ce path.

Wildcards et globs

Syntaxe

Pattern	Signification
*	Glob de suffixe — matche tout le reste du path
+	Matche un seul segment de chemin

Glissez pour voir

* n'est pas une regex

Le glob * n’est supporté qu’en fin de path. C’est un suffixe, pas une expression régulière. Vous ne pouvez pas écrire secret/*/config.

Exemples

Pattern	Correspond à	Ne correspond pas à
secret/data/dev/*	secret/data/dev/a, secret/data/dev/a/b/c	secret/data/dev
secret/data/apps/+	secret/data/apps/a, secret/data/apps/b	secret/data/apps/a/b
secret/data/+/config	secret/data/prod/config	secret/data/a/b/config

Glissez pour voir

Créer une policy

Méthode fichier

1. Créer le fichier HCL

   cat > dev-policy.hcl << 'EOF'
   # Accès complet à secret/dev/*
   path "secret/data/dev/*" {
     capabilities = ["create", "read", "update", "delete", "list"]
   }
   
   path "secret/metadata/dev/*" {
     capabilities = ["list", "read", "delete"]
   }
   
   # Lecture seule sur shared
   path "secret/data/shared/*" {
     capabilities = ["read", "list"]
   }
   EOF

2. Charger la policy dans Vault

   vault policy write dev-policy dev-policy.hcl

   Sortie :

   Success! Uploaded policy: dev-policy

3. Vérifier

   vault policy read dev-policy

Méthode inline

Pour les policies simples :

vault policy write staging-readonly - << 'EOF'
path "secret/data/staging/*" {
  capabilities = ["read", "list"]
}
EOF

Lister et gérer les policies

# Lister toutes les policies
vault policy list

# Lire une policy
vault policy read dev-policy

# Supprimer une policy
vault policy delete dev-policy

Assigner une policy

À un utilisateur userpass

vault write auth/userpass/users/alice policies="dev-policy,staging-readonly"

À un rôle AppRole

vault write auth/approle/role/ci-app \
    policies="ci-deploy-policy" \
    secret_id_ttl=10m \
    token_ttl=20m

À un token

vault token create -policy="dev-policy" -policy="staging-readonly"

Tester une policy

Méthode 1 : créer un token et tester

# Créer un token avec la policy
vault token create -policy="dev-policy" -field=token

Puis testez avec ce token :

export VAULT_TOKEN="<token>"

# Doit réussir (dev/*)
vault kv put secret/dev/myapp password="test"

# Doit échouer (pas de permission)
vault kv put secret/prod/myapp password="test"

Sortie attendue pour l’échec :

Error writing data to secret/data/prod/myapp: Error making API request.
Code: 403. Errors:
* 1 error occurred:
    * permission denied

Méthode 2 : vault token capabilities

Vérifiez les capabilities d’un token sur un path :

# Avec le token actuel
vault token capabilities secret/data/dev/myapp

# Avec un token spécifique
vault token capabilities <token> secret/data/dev/myapp

Sortie :

create, delete, list, read, update

Méthode 3 : -output-policy

Certaines commandes CLI supportent -output-policy pour afficher les permissions nécessaires à une opération :

vault kv get -output-policy secret/apps/webapp

Sortie :

path "secret/data/apps/webapp" {
  capabilities = ["read"]
}

Utile pour construire vos policies de manière incrémentale.

Templates avec identité

Vault peut utiliser l’identité de l’utilisateur dans les paths grâce aux templated policies :

# Chaque utilisateur accède à son propre espace
path "secret/data/users/{{identity.entity.name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

L’utilisateur alice pourra accéder à secret/data/users/alice/* mais pas à secret/data/users/bob/*.

Variables disponibles

Variable	Description
{{identity.entity.id}}	ID unique de l’entité
{{identity.entity.name}}	Nom de l’entité
{{identity.entity.aliases.<mount>.id}}	ID d’alias pour un auth method
{{identity.groups.ids.<group_id>.name}}	Nom d’un groupe par ID
{{identity.groups.names.<group_name>.id}}	ID d’un groupe par nom

Glissez pour voir

Préférez les IDs aux noms

En production, utilisez les IDs d’entité ou de groupe plutôt que les noms lisibles. Les noms peuvent changer ou être réutilisés, pas les IDs.

Contrôle fin des paramètres

Les policies peuvent restreindre quels paramètres peuvent être envoyés à un endpoint.

allowed_parameters

Autorise uniquement certains paramètres :

path "secret/data/limited/*" {
  capabilities = ["create", "update"]

  # Seuls ces champs peuvent être écrits
  allowed_parameters = {
    "data" = {
      "username" = []
      "password" = []
    }
  }
}

denied_parameters

Interdit certains paramètres (prioritaire sur allowed_parameters) :

path "secret/data/apps/*" {
  capabilities = ["create", "update"]

  # Tout est autorisé sauf ces champs
  denied_parameters = {
    "data" = {
      "admin_token" = []
    }
  }
}

required_parameters

Exige la présence de certains paramètres :

path "pki/issue/my-role" {
  capabilities = ["create", "update"]

  # Le common_name est obligatoire
  required_parameters = ["common_name"]
}

Limitations

Ces contraintes ont des subtilités :

• denied_parameters prend le pas sur allowed_parameters
• Le joker "*" dans ces blocs a des règles spécifiques
• L’évaluation ne tient pas compte des valeurs par défaut des paramètres

Consultez la documentation officielle pour les cas limites.

Exemples de policies par rôle

Policy développeur

# dev-policy.hcl - Développeur
# Accès complet à l'environnement de dev
path "secret/data/dev/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

path "secret/metadata/dev/*" {
  capabilities = ["list", "read"]
}

# Lecture seule sur staging
path "secret/data/staging/*" {
  capabilities = ["read", "list"]
}

# Pas d'accès à prod (deny by default)

Policy CI/CD (build)

Un pipeline de build n’a généralement besoin que de chiffrer :

# ci-build-policy.hcl - Pipeline de build
# Chiffrement uniquement (pas de déchiffrement)
path "transit/encrypt/ci-key" {
  capabilities = ["update"]
}

# Lecture des configs non sensibles
path "secret/data/build/config" {
  capabilities = ["read"]
}

Policy CI/CD (deploy)

Un pipeline de déploiement a besoin de déchiffrer et lire les secrets :

# ci-deploy-policy.hcl - Pipeline de déploiement
# Lecture des secrets de déploiement
path "secret/data/deploy/*" {
  capabilities = ["read"]
}

# Déchiffrement (pas de chiffrement)
path "transit/decrypt/ci-key" {
  capabilities = ["update"]
}

# Accès aux certificats PKI
path "pki/issue/deploy-role" {
  capabilities = ["create", "update"]
}

Moindre privilège

Séparez les rôles : un pipeline de build ne devrait pas pouvoir déchiffrer, un pipeline de deploy ne devrait pas pouvoir chiffrer de nouvelles données.

Policy admin (non-root)

# admin-policy.hcl - Admin sans être root

# Gestion des policies
path "sys/policies/acl/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Gestion des auth methods (activer/désactiver)
path "sys/auth/*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

# Configuration des auth methods
path "auth/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Gestion des secrets engines
path "sys/mounts/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Accès à tous les secrets
path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

sys/auth vs auth

• sys/auth/* : activer/désactiver des méthodes d’authentification (sudo requis)
• auth/* : configurer les objets internes d’une méthode (users, roles…)

Les deux paths ont des usages distincts.

Organisation recommandée

Par équipe

policies/
├── team-backend.hcl
├── team-frontend.hcl
├── team-devops.hcl
└── team-security.hcl

Par environnement

policies/
├── env-dev.hcl
├── env-staging.hcl
└── env-prod.hcl

Combinaison

Un utilisateur peut avoir plusieurs policies :

vault write auth/userpass/users/alice \
    password="..." \
    policies="team-backend,env-dev,env-staging"

Les capabilities se cumulent pour les mêmes patterns.

Dépannage

Symptôme	Cause probable	Solution
permission denied	Policy manquante ou pattern non couvert	vault token capabilities <path>
invalid policy	Erreur de syntaxe HCL	Valider avec vault policy write
Capabilities inattendues	Priority matching → mauvaise règle sélectionnée	Vérifier les wildcards
Wildcard ne marche pas	* pas en fin de path, ou + vs *	Revoir la syntaxe
KV v2 access denied	Path sans /data/	Ajouter /data/ au path
Policy modifiée sans effet	Token émis avant modification	Les tokens gardent leurs policies d’émission

Glissez pour voir

Debug : voir les policies d’un token

# Token actuel
vault token lookup

# Token spécifique
vault token lookup <token>

Debug : générer une policy depuis une commande

vault kv get -output-policy secret/myapp

À retenir

1. Deny by default : sans policy explicite, tout est refusé
2. Priority matching : la règle la plus spécifique s’applique en premier
3. Union conditionnelle : les capabilities se cumulent uniquement sur le même pattern dans plusieurs policies
4. KV v2 paths : secret/data/*, secret/metadata/*, etc.
5. Wildcards : * (suffixe uniquement, fin de path), + (un segment)
6. Templates : {{identity.entity.id}} — préférez les IDs aux noms
7. deny prioritaire : toujours évalué en dernier, gagne toujours
8. Moindre privilège : séparez les rôles (build ≠ deploy, dev ≠ prod)

Prochaines étapes

Authentification Configurer userpass et AppRole

PKI Générer des certificats TLS

Transit Encryption as a Service

×

📖 Voir la documentation →