Meilleures pratiques pour gérer les secrets avec la faille HashiCorp dans IC/CD

La gestion sécuritaire des secrets est un aspect essentiel des pipelines de CI/CD modernes. Toute fuite de clés API, d'identificateurs de base de données ou de jetons peut entraîner des violations catastrophiques des données, des violations de la conformité et des dommages de réputation. HashiCorp Vault fournit une solution robuste et de qualité d'entreprise pour la gestion secrète, permettant aux organisations de protéger les données sensibles tout au long du cycle de développement et de déploiement.

Ce guide décrit les stratégies éprouvées pour utiliser la Vault HashiCorp dans les environnements CI/CD. Vous apprendrez à tirer parti des secrets dynamiques, à mettre en œuvre des politiques à grain fin, à chiffrer les données en transit et au repos, à faire pivoter les identifiants en continu et à surveiller tous les accès secrets.

L'adhésion à ces pratiques renforcera non seulement votre posture de sécurité, mais aussi la rationalisation des workflows opérationnels, réduira les frais généraux manuels et aidera à satisfaire les exigences réglementaires comme le SOC 2, PCI DSS et HIPAA.

Comprendre la faille HashiCorp dans CI/CD

HashiCorp Vault est un outil conçu pour stocker et contrôler l'accès aux jetons, mots de passe, certificats et autres secrets de manière sécurisée. Dans les flux de travail CI/CD, Vault peut générer dynamiquement des secrets, gérer le cycle de vie secret et appliquer des politiques d'accès.

Vault s'intègre aux systèmes CI/CD grâce à son API REST, à son CLI et à ses plugins d'authentification native. Le modèle typique comprend :

  • Authentification: Le pipeline CI/CD s'authentifie à Vault en utilisant une méthode sécurisée comme AppRole, Kubernetes auth, ou un jeton à courte durée injecté par l'outil CI.
  • Secret Retrieval:[ Pendant une étape de construction ou de déploiement, le pipeline demande des secrets de Vault — soit des secrets statiques d'un magasin KV, soit des secrets dynamiques d'une base de données, d'un cloud ou d'un moteur PKI.
  • Usage: Les secrets sont injectés temporairement dans des variables d'environnement, des fichiers de configuration ou des arguments de commande, puis utilisés pour des tâches comme la connexion à une base de données, la signature d'objets ou le déploiement dans un fournisseur de cloud.
  • Cleanup:[ Après utilisation, le pipeline annule les identificateurs temporaires ou les variables d'environnement non définies pour réduire la fenêtre d'exposition.

Cette approche élimine la nécessité de stocker des secrets dans les dépôts Git, les fichiers de configuration CI/CD ou les registres d'objets, réduisant considérablement la surface d'attaque.

Principes fondamentaux de la gestion secrète avec la faute

1. Utiliser des secrets dynamiques

Les secrets statiques, comme un mot de passe unique utilisé depuis des années, sont une responsabilité en matière de sécurité. S'ils sont compromis, ils accordent un accès persistant jusqu'à ce qu'ils soient tournés manuellement. Les moteurs secrets dynamiques de Vault créent des identifiants à la volée avec des valeurs TTL (de temps à temps).

Les secrets dynamiques offrent plusieurs avantages :

  • Période de vie courte:[ Les secrets expirent automatiquement, souvent en quelques minutes ou en quelques heures.
  • Chaque pipeline est exécuté avec des identifiants distincts, ce qui rend impossible la réutilisation d'un secret compromis d'une construction antérieure.
  • Révocation automatique : La faille peut révoquer les secrets dynamiques immédiatement après la fin du pipeline, ou à l'expiration du TTL.

Pour implémenter des secrets dynamiques, configurez un moteur secret (par exemple, base de données, AWS, Azure) avec un rôle défini et par défaut TTL. Votre pipeline demande alors un bail pour ce rôle et utilise les identifiants retournés uniquement pour la durée de l'emploi.

2. Mettre en œuvre le contrôle d'accès par gradation fine

Les politiques de la Vault sont rédigées dans HCL (HashiCorp Configuration Language) et suivent un modèle de permissions basées sur le chemin. Chaque politique accorde ou refuse l'accès à des chemins et des capacités secrets spécifiques (lire, créer, mettre à jour, supprimer, liste, sudo).

Considérez ces lignes directrices :

  • Créer des politiques distinctes pour le développement, la mise en scène et les pipelines de production.Un IC qui construit une branche de fonctions ne devrait jamais avoir accès aux secrets de production.
  • Restrictions de la patte:[ Limiter l'accès aux seuls chemins secrets exacts nécessaires. Par exemple, une politique de base de données pourrait permettre sur mais nier tout le reste.
  • Accès lié au temps:[ Combiner les politiques avec les limites de renouvellement et de jeton TTL. Même si le jeton d'un pipeline est volé, sa fenêtre de validité est limitée.
  • Utiliser les identités :[ Tirer parti des entités et des groupes d'identité de la faille pour joindre des politiques à des outils, des emplois ou des comptes de services particuliers de l'IC/DC.

Exemple de politique minimale pour un pipeline d'IC :

path "database/creds/ci-app" {
 capabilities = ["read", "list"]
}

path "secret/data/ci/*" {
 capabilities = ["read", "list"]
}

path "auth/token/lookup-self" {
 capabilities = ["read"]
}

3. Chiffrer les secrets au repos et en transit

Vault chiffre automatiquement toutes les données stockées dans son moteur de recherche à l'aide d'une clé maître. Cette clé est elle-même chiffrée et peut être gérée avec un service externe de gestion des clés (KMS) ou un module de sécurité matérielle (HSM).

Meilleures pratiques:

  • Activer TLS:[ Configurer le serveur Vault avec un certificat valide d'une CA de confiance ou d'un ICP interne.
  • Vérifier les certificats: Les clients de CI/CD doivent vérifier la chaîne de certificats Vault Server. Fournir le certificat CA dans le magasin de fiducie tool.
  • Utilisez des SLT mutuels lorsque c'est possible :[ Pour une sécurité supplémentaire, demandez des certificats clients des systèmes CI/CD.
  • Éviter le texte clair sur le réseau: Ne jamais récupérer de secrets sur les connexions HTTP ou non cryptées. La plupart des agents CI/CD supportent les variables d'environnement qui peuvent injecter l'adresse Vault et jetonner en toute sécurité.

4. Automatiser la rotation secrète

La rotation régulière réduit les dommages causés par un secret divulgué. Les secrets dynamiques Vault sont automatiquement tournés avec chaque demande de location, mais les secrets statiques dans les magasins KV ont également besoin de rotation. HashiCorp recommande d'utiliser les mécanismes Vault-S rotation[ et lease[ ainsi que les politiques périodiques pour faire respecter la rotation au niveau de l'application.

Pour automatiser la rotation des secrets statiques :

  • Entreposez des secrets statiques dans le moteur Vault-S KV v2, qui prend en charge les opérations de mise en version et de vérification et de réglage.
  • Écrire un travail programmé (cron, lot périodique Nomad, ou pipeline CI) qui génère de nouvelles valeurs et les écrit à Vault.
  • Mettre à jour tout système dépendant (bases de données, passerelles API) avec le nouveau secret via Vault , l'écosystème de plugin ou les scripts externes.
  • Utilisez le paramètre Vault="s pour faire tourner la clé de chiffrement racine à intervalles réguliers.

5. Vérification et suivi de l'accès

Vault enregistre chaque demande authentifiée sur ses appareils d'audit. Vous pouvez envoyer des journaux d'audit à des fichiers, à un syslog ou à des services externes comme Elasticsearch, Splunk ou Datadog. Les journaux d'audit contiennent l'IP client, la méthode d'authentification, le chemin de requête, les données de réponse (si autorisé) et toutes erreurs.

Principales pratiques de surveillance :

  • Activer l'enregistrement de vérification:[ Configurer au moins un appareil de vérification. Utilisez une destination sécurisée et en appendice seulement pour empêcher toute manipulation.
  • Set up alerts:[ Créer des alertes pour les tentatives d'authentification échouées, l'accès aux chemins sensibles (p. ex., identifiants de base de données de production), ou les révocations de bail.
  • Revoir régulièrement:[ Vérifier périodiquement l'utilisation des politiques et les modèles d'accès.
  • Utilisez Vault="s adpoint: Pour la diffusion en temps réel des entrées de journal, utile pour le débogage pendant les essais CI/CD.

Intégration de la voie de communication dans les pipelines CI/CD

Méthodes d'authentification pour IC/CD

Le choix de la bonne méthode d'authentification est crucial pour la sécurité et la facilité d'utilisation.

  • AppRole: Recommandé pour l'authentification machine-to-machine. Un service CI/CD crée un rôle de Vault avec un et . Le pipeline s'authentifie en présentant les deux, en recevant un jeton client de courte durée.
  • Kubernetes Auth: Idéal pour les pipelines fonctionnant à Kubernetes. Vault valide le jeton de compte de service Kubernetes via le serveur API Kubernetes et émet un jeton de Vault basé sur les politiques liées du compte de service.
  • AWS/GPC/Azure Auth: Pour les pipelines fonctionnant sur des fournisseurs de cloud, Vault peut vérifier les métadonnées d'instance ou le rôle IAM pour émettre des jetons sans clés codées en dur.
  • Basé sur les jetons :[ Pour les configurations simples, un outil CI/CD tel que Jenkins peut injecter un jeton Vault comme variable secrète. Cette approche est moins sécurisée et ne devrait être utilisée que pour des jetons à vie très courtes.

Toujours préférer l'authentification dynamique et liée aux jetons statiques. Configurer les jetons TTL pour correspondre à la durée maximale de fonctionnement du pipeline (p. ex. 30 minutes) et définir un nombre raisonnable d'utilisations (le cas échéant).

Intégration avec des outils spécifiques de CI/CD

Jenkins: Utilisez le plugin Vault de HashiCorp. Configurez une adresse de serveur Vault, une méthode d'authentification (AppRole ou jeton) et définissez des pipelines qui récupèrent des secrets par l'intermédiaire des étapes . Le plugin prend en charge l'encodage de base64, l'injection de fichier et l'assignation de variables d'environnement.

GitLab CI: GitLab CI supporte nativement Vault via le jeton . Configurer Vault pour accepter l'authentification JWT de l'émetteur JWT de GitLab. Dans , utiliser le bloc pour demander un jeton Vault et récupérer ensuite des secrets en utilisant le CLI ou l'API de Vault.

GitHub Actions:[ Utilisez l'action GitHub. Elle prend en charge l'authentification OIDC (recommandée), jeton ou AppRole. Ajoutez une étape qui map les secrets aux variables d'environnement ou les écrit dans les fichiers. Pour OIDC, configurez Vault avec une méthode d'authentification JWT fiable à l'émetteur et liée à des dépôts ou des succursales spécifiques.

CircleCI: Utilisez l'orbe de la faille ou les appels d'API directs. La fonction contexte CircleCI= peut stocker un jeton de faille, mais AppRole ou OIDC est préféré.

Flux de travail avec AppRole en Jenkins

Considérez un pipeline Jenkins qui construit une image Docker et la déploie dans un cluster Kubernetes. Au lieu de stocker la configuration Kubernetes et le mot de passe de registre dans Jenkins, il les récupère de Vault à l'exécution.

  1. Préconfigurer la faille:[ Créer une politique permettant l'accès en lecture à et . Créer un rôle AppRole avec cette politique, un TTL de 10 minutes, et un stocké dans Jenkins comme un titre de créance.
  2. Pipeline Step: Utilisez le plugin Vault HashiCorp avec l'ID de rôle AppRole (également un titre) et le SecretID. Le plugin authentifie et obtient un jeton Vault.
  3. Fetch Secrets: Lisez le mot de passe du registre Docker et le jeton Kubernetes de Vault. Le plugin les écrit à des variables d'environnement temporaires ou des fichiers.
  4. Usage: Exécutez avec les identifiants. Puis exécutez avec la configuration. Après l'étape, le pipeline se termine et le jeton Vault expire.
  5. Nettoyage:[ Renoncez éventuellement le SecretID AppRole=s si la réutilisation n'est pas souhaitée.

Considérations avancées

Moteurs secrets et leurs cas d'utilisation

Vault prend en charge de nombreux moteurs secrets. Pour CI/CD, les plus pertinents sont :

  • KV v2 (Key-Value):[ Entreposez des secrets statiques comme les clés API, les certificats ou les paramètres spécifiques à l'environnement.
  • Base de données: Générer des utilisateurs temporaires de bases de données avec des identifiants dynamiques pour MySQL, PostgreSQL, MongoDB, et d'autres.
  • Fournisseurs de cloud (AWS, Azure, GCP): Générer des rôles temporaires de MAI, des directeurs de service ou des clés de compte de stockage.
  • PKI: Délivrer des certificats TLS à courte durée de vie pour mTLS entre microservices ou pour les registres de conteneurs.
  • Transit:[ Chiffrer/décrypter les données sans les stocker — utile pour le chiffrement des artefacts avant de les stocker dans un dépôt.

Conception des politiques Pratiques exemplaires

Concevoir des politiques avec une convention de désignation claire et une structure hiérarchique.

  • – pour des secrets spécifiques à l'IC.
  • – pour mettre en scène des secrets environnementaux.
  • – pour les secrets de production (avec un accès très restreint).

Évitez d'utiliser des chemins de caractères génériques trop largement. Au lieu de cela, accordez l'accès à des chemins secrets spécifiques. Utilisez deny[ règles particulièrement; le refus par défaut de Vault est suffisant. Les combinaisons de et doivent être testées avant de se déployer à la production. La commande Vault CLI est utile pour la validation.

Soutien et reprise après sinistre

Si vous utilisez le stockage intégré (Raft), activez les sauvegardes instantanées. Pour les pipelines CI/CD qui dépendent de Vault pour tous les secrets, une panne de Vault va casser les déploiements. Mitigate ceci par:

  • Courir la faille dans une configuration très disponible (HA) avec au moins trois nœuds.
  • Stocker un ensemble de secrets de repli dans un magasin crypté alternatif (p. ex., AWS Secrets Manager) avec un court TTL — mais traiter cela comme un dernier recours.
  • Tester régulièrement les procédures de reprise après sinistre, y compris la restauration à partir d'un instantané.

Pièges fréquents à éviter

  • Hardcoding a Vault Token in CI/CD Variables: Même si le jeton est stocké comme une variable secrète, il peut être divulgué par des journaux de construction ou des artefacts. Utilisez l'authentification dynamique (AppRole, OIDC) afin que le jeton soit généré pour chaque exécution et ne persiste jamais.
  • Utiliser le jeton racine dans les pipelines:[ Le jeton racine ne doit être utilisé que pour l'initialisation et les urgences.
  • Un pipeline d'IC fonctionne généralement pendant des minutes, et non des heures. Réglez les TTL à la durée de travail prévue, plus un petit tampon.
  • Ignorer les journaux d'audit:[ Sans surveillance d'audit, vous manquez les indicateurs de compromis ou les politiques mal configurées.
  • Servoir les secrets dans les sorties de pipelines:[ N'imprimez jamais les secrets pour consoler, enregistrer des fichiers ou construire des artefacts. Utilisez une injection basée sur des fichiers ou retirez le secret des variables d'environnement immédiatement après l'utilisation.
  • Oublier les baux :[ Les secrets dynamiques demeurent valides jusqu'à l'expiration ou à la révocation du bail. Révoquez explicitement les baux dans votre pipeline.

Conclusion

L'intégration de la faille HashiCorp dans vos pipelines CI/CD élimine la source la plus dangereuse de fuites secrètes : les identifiants statiques codés en dur ou stockés en environnement. En suivant les meilleures pratiques décrites ici – secrets dynamiques, contrôle d'accès à grain fin, chiffrement, rotation automatisée et audit complet – vous pouvez réaliser un flux de travail solide et prêt à la production.

Commencez petit : adoptez l'authentification AppRole pour un pipeline, récupérez un justificatif dynamique de base de données et surveillez les journaux d'audit. Développez progressivement pour couvrir tous les pipelines et les types secrets. Avec Vault, la sécurité et la vitesse vont de pair, assurant que vos sorties CI/CD sont à la fois sûres et fiables.

Ressources supplémentaires: