Comment fonctionnent les secrets Docker et où les développeurs les utilisent à mauvais escient
Les secrets Docker ont été introduits pour gérer en toute sécurité les données sensibles telles que les clés d'API, les mots de passe de bases de données et les jetons. Ils fonctionnent en montant les secrets sous forme de fichiers dans /run/secrets À l'intérieur d'un conteneur, accessible uniquement au service conteneurisé. Ce mécanisme permet d'exclure les secrets des variables d'environnement et des journaux, du moins en théorie. Le problème survient lorsque les développeurs contournent ce mécanisme. Au lieu d'utiliser les secrets Docker Compose fonctionnent correctement, les secrets sont souvent codés en dur dans Dockerfile, commitTransférés vers Git ou injectés via des variables d'environnement, ces raccourcis rendent les secrets vulnérables à une exposition accidentelle via les journaux, les couches de conteneurs ou l'historique des versions.
# Risky
ENV DB_PASSWORD=mysecretpassword
⚠️ Exemple non sécurisé, ne pas utiliser en production
Une fois cette ligne ajoutée, elle est intégrée à l'image. Toute personne ayant accès à l'image (cache de build, registre ou CI/CD journaux) peuvent l'extraire. Pire encore, ce schéma passe souvent inaperçu lors des vérifications, car il « fonctionne tout seul ».
Secrets de Docker Compose et risques cachés dans les configurations partagées
Docker Compose simplifie les applications multi-conteneurs, mais Secrets de Docker Compose comportent des risques cachés. Les développeurs partagent souvent Docker Compose.yml or .env fichiers entre équipes et environnements, via Git, Slack ou des lecteurs partagés.
services:
app:
image: myapp
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt
⚠️ Exemple démonstratif, n'incluez pas de vrais secrets dans les fichiers versionnés
Le problème ? Ces Docker Compose secrets Les références supposent des fichiers locaux, mais en pratique, ces fichiers sont versionnés ou distribués de manière non sécurisée. Des secrets s'infiltrent dans les dépôts Git et apparaissent dans pull requests, ou être copiés dans d'autres dossiers. L'hypothèse selon laquelle « nous savons tous qu'il ne faut pas commit « secrets » n’est pas une politique de sécurité.
Pire encore, des environnements comme la mise en scène et la production peuvent réutiliser les mêmes docker-compose.yml, créant un faux sentiment de séparation. Un mal configuré .env fichier et les secrets de production sont injectés dans un environnement de test.
CI/CD Pipelines : Où la gestion des secrets Docker échoue
In CI/CD, Secrets Docker s'effondrer s'il n'est pas isolé. Les secrets sont souvent divulgués à trois endroits : journaux, couches d’images et coureurs partagés.
Journaux:Impression des étapes CI écho $SECRET_KEY pour déboguer les problèmes. Mais ces journaux sont stockés, parfois publiquement. Des outils comme Actions GitHub or gitlab ce stocker les journaux pendant des jours ou des semaines.
Calques d'images:Si un Dockerfile ajoute un secret pendant la construction :
RUN echo "$SECRET_KEY" > /app/config.txt
⚠️ Exemple non sécurisé, cela expose des secrets dans les calques d'image
Ceci Secret de Docker fait désormais partie d'un calque d'image. Même si vous supprimez le fichier ultérieurement, le calque précédent reste dans l'historique de l'image.
Coureurs partagés: De nombreux CI/CD Les plateformes utilisent des exécuteurs partagés. Si les secrets ne sont pas correctement définis ou nettoyés, d'autres builds peuvent y accéder. Pire encore, les secrets sont parfois transmis par défaut comme variables d'environnement à toutes les étapes.
Sécurisation de Docker dans le code, Pipelines, et registres
Pour verrouiller Secrets Docker, les équipes de développement ont besoin de défenses multicouches :
- Utiliser des gestionnaires de secrets Comme AWS Secrets Manager, HashiCorp Vault ou Doppler, ces outils alternent et injectent des secrets de manière sécurisée dans vos conteneurs lors de l'exécution.
- Limiter les portéesNe divulguez jamais les secrets de production dans les environnements de développement/test. Utilisez le contrôle d'accès basé sur les rôles (RBAC) pour restreindre l'accès aux secrets.
- Évitez les variables ENV pour les secrets. utilisation Secret de Docker volumes ou monter des secrets sous forme de fichiers explicitement.
- Nettoyer les builds: Assurez-vous que les secrets ne sont pas intégrés aux images ou laissés dans des fichiers intermédiaires.
- Scanner les conteneurs et les dépôts:Utilisez des outils qui inspectent les images, l'historique git et CI/CD configurations pour les secrets divulgués.
Meilleures pratiques pour éviter l'exposition des secrets Docker
- Secrets éphémèresGénérer des secrets à usage unique lors des exécutions d'intégration continue. Ceux-ci expirent et ne peuvent pas être réutilisés en cas de vol.
- Secrets scellésUtilisez les secrets scellés Kubernetes (SOPS) pour chiffrer les secrets dans Git. Cela garantit une gestion sécurisée des versions des secrets.
- CI/CD politiques: Appliquer des politiques telles que aucun secret dans Dockerfile, les blocs s'appuient sur la détection secrète et enregistrent l'utilisation de Secrets Docker / pipeline.
- Pre-commit hooks: Bloquer commits avec des secrets en utilisant des outils comme git-secrets or détecter-les-secrets.
- Infrastructure immuable: Ne modifiez pas les secrets des conteneurs. Reconstruisez et redéployez avec de nouveaux Secrets Docker à la place.
Conclusion
En cas d'utilisation abusive, Secrets Docker devenir un handicap plutôt qu'un élément de sécurité. Secrets de Docker Compose fuite à travers les fichiers YAML vers CI/CD pipelineEn exposant des secrets dans des journaux ou des couches, les risques sont réels et évitables.
Utiliser des outils comme Xygéni, les équipes peuvent détecter les personnes exposées secrets tôt, appliquez les politiques de gestion des secrets et recherchez les dérives de sécurité dans le code, les conteneurs et pipelines. Traitez votre Dsecret d'Ocker Stratégie en tant qu'infrastructure critique. Sécurisez-la comme vous le pensez.
