Cette série d’articles a pour but d’identifier les meilleures pratiques à mettre en place pour sécuriser votre processus de livraison et vos pipelines CI/CD :
0. DevSecOp : Sécuriser les pipelines CI/CD, comprendre les fondements
1. La sécurité du système de gestion des versions
2. Sécuriser les pipelines d’intégration continue (CI)
3. Sécuriser les pipelines de déploiement continu (CD)
4. Gestion des secrets dans les pipelines CI/CD
Par Gologic, en collaboration avec Alexandre Couëdelo.
Bienvenue dans la série sur la sécurité des pipelines CI/CD de Gologic, où nous continuons à démêler les complexités et les subtilités de la sécurisation des pipelines d’intégration continue et de livraison continue. Jusqu’à présent, nous avons exploré divers principes fondamentaux de la sécurité CI/CD, alors à partir de maintenant, nous aborderons des concepts plus approfondis.
Dans cet article, nous nous plongeons dans l’un des aspects les plus cruciaux de la sécurité CI/CD : la gestion des secrets. La manipulation de données sensibles telles que les mots de passe, les jetons et les clés est un pilier des bonnes pratiques de développement de logiciels sécurisés.
Nous allons explorer la gestion des secrets en trois étapes : en commençant par une solution simple pour le chiffrement des secrets et le dépôt de code, puis nous verrons les coffres-forts de secrets, pour finir par la mise en œuvre de secrets à durée de vie limitée et de protocoles d’authentification modernes tels que OpenID Connect. Nous vous guiderons à travers les subtilités de chaque approche, leurs défis et leurs avantages.
Règles d’or
Avant de plonger dans la comparaison des trois solutions de gestion des secrets, établissons d’abord les trois règles d’or en matière de gestion des secrets.
- Principe du moindre accès : chaque composant (utilisateur, application, service) de votre système ne devrait avoir accès qu’aux secrets nécessaires à son fonctionnement. Cela réduit l’impact d’un attaquant en cas de fuite d’un secret.
- Court cycle de vie des secrets : les secrets doivent être changés régulièrement et automatiquement. Cela empêche les attaquants d’exploiter les secrets volés.
- Ne jamais partager les secrets : traitez tous les secrets comme des informations strictement confidentielles qui ne doivent jamais être partagées entre les composants (utilisateurs, applications, services). Cela garantit que si un secret fuit, l’impact est limité et la rotation du secret en question est facile et n’affecte pas les autres systèmes.
La gestion idéale des secrets respecte ces trois règles d’or, voyons comment chacune des solutions respecte ou non ces règles.
Niveau 1 : secrets encryptés/secrets scellés
Parmi d’autres, Ansible Vault, K8s Sealed Secrets et Spring Cloud Config Ciphers ont popularisé ces approches dans les premiers jours de la gestion de la configuration et du GitOps. Le problème qu’ils ont essayé de résoudre est que « nous pouvons gérer les configurations dans Git, sauf les secrets ». Ainsi, pour atteindre un flot GitOps complet, ils ont suggéré une manière de gérer les secrets « as code ».
Avec cette approche, les secrets sont chiffrés à l’aide d’un algorithme de chiffrement et d’une clé avant d’être stockés dans les dépôts de code. Seuls les utilisateurs ou les systèmes disposant de la clé de déchiffrement peuvent accéder aux données originales en clair.
Par exemple, vous pouvez chiffrer un mot de passe de base de données avant de le publier (push) dans votre dépôt Git. Pendant le processus CI/CD, votre pipeline a accès à la clé de déchiffrement et peut déchiffrer le mot de passe pour l’utiliser ou le transmettre à l’application lors d’un déploiement.
La principale considération de sécurité ici est la gestion des clés de chiffrement et déchiffrement. La sécurité des secrets chiffrés dépend fortement de la manière dont les clés sont stockées. Si les clés sont compromises, tous les secrets le sont également. De plus, cela signifie que les développeurs ont souvent un accès direct au secret et peuvent avoir stocké de manière non sécurisée la clé de chiffrement localement sur leur ordinateur.
Niveau 2 : voûte de secrets
Une voûte de secrets est un outil ou un service dédié conçu pour stocker des secrets de manière sécurisée, offrant des fonctionnalités de sécurité robustes telles que la gestion centralisée des secrets, les contrôles d’accès et les journaux d’audit.
Avec cette approche, pendant le processus de CI/CD, le pipeline interagit avec la voûte de secrets pour récupérer les secrets nécessaires. Les secrets peut soit être interpolés automatiquement, ou accédés via des API ou des CLI fournis par la voûte de secrets.
Nous pouvons distinguer plusieurs options de secrets Vault :
- CI Provider Vaults : de nos jours, toutes les plateformes CI/CD proposent des outils de gestion de secrets intégrés. Ces outils sont étroitement intégrés aux processus CI/CD, garantissant une facilité d’utilisation et une configuration minimale.
- Avec ce type de voûte, les secrets sont souvent automatiquement injectés dans les pipelines (sous forme de variable d’environnement) et obscurcis dans les logs.
- Cloud Provider Vaults: les services cloud tels que AWS Secrets Manager, Azure Key Vault ou Google Cloud Secret Manager proposent la gestion des secrets dans le cadre de leurs offres cloud.
- Ceux-ci sont parfaits pour les déploiements (CD), car l’application peut récupérer les secrets depuis la voûte . Cela élimine le besoin d’insérer des secrets dans les fichiers de configuration.
- Dedicated Solutions (e.g., HashiCorp Vault): outils tiers dédiés à la gestion des secrets, sans lien avec un fournisseur Cloud ou solution CI spécifique. Elles offrent une solution centrale pour gérer tous vos secrets.
La meilleure option est d’utiliser les CI Provider Vaults, cependant vous pouvez choisir de synchroniser les secrets d’un autre type de voûte avec les coffres-forts du fournisseur CI si vous souhaitez centraliser les secrets.
L’essentiel ici, en matière de sécurité, ce sont les secrets eux-mêmes. Le coffre-fort ne vous oblige pas à remplacer fréquemment les secrets ni ne vous empêche de partager le même secret entre plusieurs pipelines ou applications.
Niveau 3 : protocoles d’authentification et d’accréditations temporaires
Les accréditations à durée de vie limitée sont des jetons d’accès temporaires valides pendant une période limitée. Elles sont générées de manière dynamique et expirent une fois leur objectif accompli.
Par exemple, votre pipeline doit pousser des artefacts vers le référentiel d’artefacts (comme Nexus ou Docker Registry). Lorsque le pipeline est lancé, un jeton d’accès à durée limitée est créé. Le pipeline peut utiliser ce jeton pour s’authentifier auprès de votre registre d’artefacts et effectuer des actions autorisées. Une fois le pipeline terminé, le jeton expire et ne peut plus être utilisé.
De cette manière, nous éliminons complètement le besoin de secrets. La seule exigence est de valider l’identité du pipeline. OpenID Connect (OIDC) est un protocole d’authentification populaire utilisé à cette fin. Il permet aux ressources de vérifier l’identité de l’utilisateur final et d’obtenir des autorisations de contrôle d’accès de base pour chaque requête.
Azure DevOps, Gitlab et Github Action offrent cette option. Lorsqu’un pipeline démarre, il obtient un token OpenID contenant des métadonnées du pipeline (projet, référentiel, courriel de l’auteur du commit, etc.) et le jeton est signé par le fournisseur CI/CD. Ensuite, vous pouvez utiliser ce jeton et vous authentifier auprès de divers systèmes.
De plus en plus de systèmes supportent ce protocole et même si un système ne le prend pas encore en charge, vous avez toujours la possibilité d’utiliser un proxy d’authentification devant cette ressource pour gérer le flux d’authentification.
Conclusion
En conclusion, sécuriser les secrets dans les pipelines CI/CD est un aspect crucial pour maintenir un cycle de développement de logiciel sécurisé. Nous avons exploré différentes approches pour gérer les secrets, en commençant par les secrets chiffrés et les secrets scellés, en passant par les coffres-forts de secrets dédiés, et enfin en discutant de la mise en œuvre des identifiants à durée de vie limitée.
- Les secrets chiffrés/scellés sont une solution simple qui était populaire il y a quelques années, mais la gestion de la clé de chiffrement/déchiffrement la rend plutôt vulnérable.
- La voûte de secrets est la norme de l’industrie pour la gestion des secrets. Elle est spécifiquement conçue pour stocker et accéder aux secrets, mais elle n’impose pas les meilleures pratiques de sécurité telles que le principe du moindre privilège et la réutilisation des secrets.
- Les identifiants à durée de vie limitée sont le futur. Ils garantissent que seuls les pipelines autorisés peuvent effectuer des actions sur les ressources, au lieu de compter sur des mots de passe qui pourraient fuiter.
Cet article est le cinquième de notre série : « DevSecOps : Pipelines CI/CD sécurisés » où nous avons cartographié les différentes failles de sécurité et couvert la plupart des flux CI/CD. Cela comprend :
- comprendre les fondements de la sécurité des pipelines CI/CD
- les systèmes de gestion des versions
- les pipelines d’intégration continue
- les pipelines de déploiement continu
- la gestion des secrets
Dans notre prochain article, nous aborderons la gestion des artefacts, l’observabilité et la gestion des incidents de sécurité.
Ne manquez pas cette occasion d’approfondir vos connaissances en DevSecOps. Restez à jour, améliorez vos compétences et sécurisez vos pipelines CI/CD avec nos guides pratiques. Contactez-nous pour une consultation personnalisée.
Par Gologic, en collaboration avec Alexandre Couëdelo.
