Un listener avec tls_disable = 1 sur 0.0.0.0 envoie chaque jeton et chaque secret en HTTP simple, une politique "break-glass" avec le chemin "*" et sudo n'est rien d'autre que la politique root sous un autre nom, et un fichier vault-init.txt enregistré livre vos clés de descellement et votre jeton root à toute personne ayant accès au dépôt. Ce skill détecte ces erreurs et les autres erreurs Vault ci-dessous avant votre déploiement, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur les configurations de serveur, d'Agent et de Proxy Vault (HCL et JSON, y compris dans les values de vault-helm, les ConfigMaps et VAULT_LOCAL_CONFIG), sur les politiques ACL (HCL, JSON, heredocs Terraform vault_policy, règles vault_policy_document, heredocs vault policy write dans les scripts et la CI), ainsi que sur les fichiers qui exécutent Vault ou s'y connectent : docker-compose, manifestes Kubernetes et annotations de l'injecteur, values de vault-helm, unités systemd, Dockerfiles, jobs Nomad, fichiers .env, scripts shell, GitHub Actions avec vault-action et sorties enregistrées de vault operator init. Il lit le HCL avec un numéro de ligne pour chaque clé (y compris les blocs écrits sur une seule ligne), connaît les valeurs par défaut de Vault (un listener sans adresse se lie à 127.0.0.1), la correspondance des chemins de politique avec + et *, l'ancienne syntaxe policy = "write" et les références env:// et file://, et ne contacte jamais Vault ni n'exécute quoi que ce soit. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• V01 : un listener tcp avec tls_disable activé alors qu'il écoute au-delà de la boucle locale (0.0.0.0, [::], un nom d'hôte, une IP privée), dans une configuration de déploiement (dans un fichier compose local, un script docker run ou un chemin dev/test, c'est V19 à la place)
• V02 : un serveur de développement (vault server -dev, l'image hashicorp/vault sans commande, server.dev.enabled) dans une unité systemd, une charge de travail Kubernetes, des values Helm, un job Nomad, ou un fichier compose ou Dockerfile dont le nom évoque la production ; les mots de production dans le chemin l'emportent sur les mots locaux
• V03 : un chemin de politique qui correspond à tous les chemins (* ou +/*) avec sudo ou une capacité d'écriture
• V04 : jetons Vault (hvs., hvb., hvr. et les anciens s., b., r.), clés de descellement et de récupération, sorties d'init enregistrées, valeurs littérales de VAULT_TOKEN, mots de passe saisis après vault login, et identifiants de seal ou de stockage écrits dans une configuration (les espaces réservés et le jeton root de développement ne sont pas signalés ; les fichiers .env.example uniquement pour les vrais formats de jetons)

REVIEW (à vérifier avant la publication)

• V11 : disable_mlock = true avec un backend de stockage autre que le stockage intégré (vérifiez que le swap est désactivé ou chiffré)
• V12 : http:// simple vers Vault sur un autre hôte, ou vérifications de certificat désactivées (tls_skip_verify, VAULT_SKIP_VERIFY, skip_tls_verify, tlsSkipVerify, l'annotation tls-skip-verify)
• V13 : écriture ou sudo sur un joker qui couvre un montage entier (secret/*, kv/data/*, auth/*), ou lecture sur tous les chemins
• V14 : droits qui élèvent les privilèges : la majeure partie de sys/, l'écriture de n'importe quelle politique ACL (y compris celles à portée limitée comme app-*), sys/raw, les périphériques d'audit, les montages d'authentification, generate-root, rekey, seal, le catalogue de plugins, sudo sur auth/token/create, l'écriture d'entités et de groupes d'identité
• V15 : tls_min_version ou tls_max_version réglé sur tls10 ou tls11
• V16 : raw_storage_endpoint, enable_unauthenticated_access, ou métriques ou pprof non authentifiés sur un listener hors boucle locale
• V17 : réglages que Vault rejette ou ignore : capacités inconnues comme write, clés de chemin inconnues, arguments définis deux fois (Vault 2.1), un * avant la fin d'un chemin, stockage intégré sans disable_mlock (Vault 1.20), un listener TLS sans certificat
• V18 : l'ancienne image Docker officielle vault (dernière version 1.13.3) ou hashicorp/vault sans tag ou avec latest
• V19 : réglages réservés au développement dans une installation locale : TLS désactivé sur toutes les interfaces dans un fichier compose ou un chemin dev/test, ou le jeton root de développement utilisé alors que VAULT_ADDR pointe vers une autre machine

Contenu fourni

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et un lien vers la documentation officielle HashiCorp pour chaque règle
• Un exemple de projet risqué et un exemple sûr (configurations du serveur et de raft, politiques, une configuration d'Agent, une unité systemd, un fichier env, un fichier compose et une sortie d'init enregistrée), ainsi que le vrai rapport produit par le scanner sur l'exemple risqué

Limites

Il lit les fichiers tels qu'ils sont écrits. Les périphériques d'audit, les méthodes d'authentification et les politiques qu'un jeton reçoit réellement résident dans le stockage de Vault et ne sont pas visibles. Chaque chemin de politique est évalué isolément, les chemins avec modèles sont traités comme du texte fixe, et les politiques Sentinel ne sont pas lues. La configuration par défaut du chart vault-helm fonctionne sans TLS sur toutes les interfaces, donc V01 se déclenche volontairement dessus (l'exemple compose de Docker Hub reçoit V19) ; un service mesh qui chiffre le trafic n'est pas visible. Le fait qu'un fichier relève d'un déploiement ou d'une installation locale est déterminé d'après le type de fichier et les mots de son chemin dans le dépôt. NOT FLAGGED n'est pas une garantie.

Contenu de l'archive

Un fichier ZIP de 27 fichiers : SKILL.md, le scanner dans scripts/ (7 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (17 fichiers d'exemple plus report.md, la vraie sortie du scanner sur l'exemple risqué).

Utilisation : Il s'agit d'un skill d'agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.