HashiCorp veut gérer les secrets de bout en bout

Lors d’HashiConf 2024, HashiCorp a dévoilé plusieurs fonctionnalités pour renforcer les capacités de HCP Vault Secrets. La mission de l’éditeur : offrir une solution de bout en bout qui couvre la génération, la suppression, la découverte et la remédiation de secrets.

Outre Terraform, l’autre gros volet pour HashiCorp, c’est la gestion du cycle de vie de la sécurité (SLM). Chez l’éditeur, il est incarné par Vault, à la fois un système de la gestion du chiffrement et un coffre-fort à secrets (tokens d’API, mots de passe, certificats, accès à une base de données, etc.). L’éditeur entend étoffer la version SaaS de son produit : HCP Vault Secrets.

Orchestrer la rotation automatique des secrets

D’abord, il y a la disponibilité générale de la rotation automatique des secrets et les sets d’accréditations pour les clients de HCP Vault Secrets Plus. Celle-ci est fonction de « schémas », des fichiers de configuration qui incluent des informations sur l’intégration et le provider, c’est-à-dire le fournisseur du service concerné par la rotation.

Par défaut, HashiCorp a mis en place des règles de rotation tous les 30, 60 ou 90 jours.

Mais la rotation n’implique pas la désactivation du précédent secret, en tout cas pas immédiatement.

« Lorsqu’une rotation se produit, une nouvelle accréditation est stockée en tant que dernière version active du secret », précise la documentation de l’éditeur. « Dans le même temps, une version plus ancienne (N – 2) du secret devient inactive. Le jeu d’identifiants précédent reste disponible jusqu’au prochain intervalle de rotation ».

En clair, quand la version 2 d’un secret est changée, elle n’est plus active après la disponibilité de la version 4.  

« Cela garantit à l’utilisateur que le justificatif d’identité peut être utilisé en toute sécurité pendant au moins la fréquence de rotation définie », assure l’éditeur.

Il est également possible de changer la clé immédiatement en cas de fuite ou de soupçon de fuite, après un redémarrage de l’application associée. Dans ce cas-là, la version précédente du secret est supprimée. Cela annule également l’intervalle de rotation qui est réactivé à partir de la date de rotation manuelle. Pour l’instant, cette fonctionnalité a une portée limitée : elle prend en charge AWS, GCP, MongoDB Atlas et Twilio.

Secrets dynamiques

La rotation automatique des secrets ne répond pas à tous les besoins. Ce mécanisme n’est pas adapté à l’exécution de tâches éphémères, comme une session de dépannage ou l’exécution d’un pipeline CI/CD, explique James Bayer, SVP Research & Development chez HashiCorp.

Pour ces usages, l’éditeur entend proposer une fonction de « secrets ou d’accréditation dynamiques ».

« Si vous ne l’utilisez que pour la build de votre CI/CD, dès que cette étape est terminée, le secret peut être supprimé, car il ne sera plus utile », indique-t-il.  

Il s’agit de minimiser la surface d’attaque, de simplifier la gestion des secrets et de les rendre traçables.

Dans sa documentation, HashiCorp précise que dès qu’un flux de travail a une durée de vie préétablie, la fonctionnalité est utile. Il donne l’exemple de l’exécution d’un run Terraform ou l’appel d’un service serverless.

Les secrets dynamiques demandent d’ajouter un paramètre de durée de vie (Time To live ou TTL) dans le fichier de configuration. En bêta, la gestion des secrets dynamiques n’est compatible qu’avec les IAM de GCP et d’AWS.

HashiCorp ne précise pas la durée de vie minimum d’un secret. Il ne fournit pas non plus de SLA. Au moment de présenter la fonctionnalité, Armon Dadgar, cofondateur et CTO d’HashiCorp a évoqué une durée d’expiration de 30 minutes.

Avant que Hashicorp ne lance ce service, l’équipe responsable de la sécurité de Canva a déployé des secrets dynamiques pour des applications tierces – ici les agents de Datadog – s’exécutant au sein de ses clusters Kubernetes à l’aide du Vault Secret Operator.

Dans cette configuration, Anthony Ralston, ingénieur logiciel chez Canva, explique que son équipe pouvait subir des pertes de connectivité avec Vault d’environ 15 minutes qui interrompaient le fonctionnement du système. En prenant en considération cet aspect, l’équipe a allongé de 16 à 24 heures la durée de vie d’un secret.

« Lors de la configuration de vos TTLS pour les cas d’usage de secrets dynamiques, il est très important de faire les calculs et de comprendre la relation entre tous les jetons, la durée de vie configurée dans le fichier de métadonnées “leases” et les indications de fiabilité », souligne Anthony Ralston.

Enfin, la gestion fine des RBAC, apparue avec HCP Vault Secrets, a été étendue aux projets et aux applications afin de définir qui a accès et qui n’a pas accès aux secrets et accréditations.

HCP Vault Radar : HashiCorp muscle son concurrent de GitGuardian

Jusque-là, HashiCorp demeure dans son champ d’action habituel. Toutefois, l’éditeur entend étendre la portée de son offre en proposant HCP Vault Radar. Disponible gratuitement dans sa phase de bêta publique, il s’agit « ni plus ni moins » qu’un outil de scan de secrets, mais il peut aussi détecter les informations personnelles et les éléments de langage « non inclusif ». Il reprend les fondations technologiques de Blubracket, une startup rachetée en 2023.

« Vault Radar doit aider à scanner continuellement les dépôts à la recherche de secrets, ce n’est pas un problème d’un jour », déclare Armon Dadgar.

L’outil prend en charge Azure DevOps, GitHub, BitBucket, GitLab, Gerrit et Confluence. Vault Radar peut scanner jusqu’à 5 000 dépôts. Au-delà, l’outil sélectionne les 100 dépôts avec l’activité la plus récente. HashiCorp a établi sa propre base de données de secrets, comptant un peu moins de 300 références.

Il est déjà possible d’établir des règles après la détection, de bénéficier d’un score de sévérité et d’ignorer certains faux positifs. HashiCorp entend fournir des guides de remédiations. Par ailleurs, il est possible de filtrer les secrets présents dans un coffre-fort Vault.

Pour autant, HCP Vault Radar chevauche les capacités de scanning de GitHub et marche sur les plates-bandes d’outils qui intègrent ces fonctions, dont Datadog, mais aussi d’acteurs spécialisés comme GitGuardian.

« Gitguardian et d’autres proposent de bonnes solutions, mais que faire ensuite ? Ce problème n’est pas résolu », déclare Prakash Linga, responsable produit Vault Radar chez Hashicorp et cofondateur et ex-CEO de Blubracket.

« Ce que nous faisons déjà et ce dont nous sommes particulièrement capables, c’est de fournir une solution de bout en bout, qui couvre le cycle de vie d’un secret », poursuit-il. « Il ne s’agit pas seulement de découvrir, mais aussi de donner un contexte pour hiérarchiser les priorités et fournir des actions pour gouverner les secrets ».

GitGuardian propose déjà ce type de fonctionnalité.

« Comme nous proposons Vault, nous sommes les seuls à pouvoir couvrir l’ensemble des aspects », défend Prakash Linga.

Vault 1.18 : tout pour les grands comptes 

HashiCorp continue d’améliorer Vault pour répondre aux besoins des grandes entreprises avec des nouveautés dans la version 1.18. Cette version introduit plusieurs fonctionnalités, notamment la prise en charge du protocole CPMv2, pour l’enrôlement d’équipements 5G, et une meilleure gestion de la norme IPv6, en réponse aux obligations légales aux États-Unis.

Les équipes DBA et SecOps peuvent désormais effectuer manuellement la rotation des accréditations dans PostgreSQL. Depuis Vault Enterprise 1.15, le système de fédération WIF permet d’utiliser des services cloud sans configurer de secrets.

Vault bénéficie également de gains de performance et de résilience pour des clients grands comptes, tels que les services financiers et les voyagistes. Une nouvelle fonctionnalité, la protection adaptative contre la surcharge, permet de limiter les ralentissements dus à un trop grand nombre d’écritures simultanées dans le WAL de Vault, grâce à un algorithme optimisant le débit et la mise en cache.

Enfin, une révision du protocole RAFT inclut les pré-votes pour éviter les changements de leadership inutiles dans les clusters multinœuds. Cela permet de réduire de 99 % les effets dus à ce phénomène. La stabilité des grands clusters s’en trouverait améliorée.

Pour approfondir sur Gestion d’identités (IGA, PAM, Bastion, PASM, PEDM)

Close