La plupart des pipelines CI\/CD d\u00e9marrent avec un objectif simple : acheminer le code depuis la machine d’un d\u00e9veloppeur vers la production le plus rapidement possible. En cours de route, quelqu’un cr\u00e9e un compte de service, lui accorde des permissions larges, stocke les identifiants comme secret du pipeline, et passe \u00e0 autre chose. Cela fonctionne. Les builds passent, les d\u00e9ploiements r\u00e9ussissent, et personne n’y repense \u2014 jusqu’\u00e0 ce qu’un attaquant compromette ce pipeline et d\u00e9couvre qu’il poss\u00e8de les cl\u00e9s de l’ensemble du royaume.<\/p>\n
Le probl\u00e8me n’est pas que les \u00e9quipes sont n\u00e9gligentes. Le probl\u00e8me est que les outils CI\/CD rendent facile<\/em> l’octroi de privil\u00e8ges excessifs et difficile<\/em> l’application de contr\u00f4les granulaires. Le chemin par d\u00e9faut dans la plupart des plateformes est une identit\u00e9 unique avec un acc\u00e8s large ex\u00e9cutant chaque \u00e9tape du pipeline. Les principes de s\u00e9curit\u00e9 comme la s\u00e9paration des responsabilit\u00e9s<\/strong> (SoD) et le moindre privil\u00e8ge<\/strong> ressemblent \u00e0 des contraintes bureaucratiques quand on essaie de livrer des fonctionnalit\u00e9s.<\/p>\n Ils ne le sont pas. Ce sont des contr\u00f4les d’ing\u00e9nierie qui limitent le rayon d’impact quand \u2014 et non si \u2014 quelque chose tourne mal. Ce guide explique comment appliquer ces deux principes aux pipelines CI\/CD d’une mani\u00e8re qui renforce votre posture de s\u00e9curit\u00e9 sans d\u00e9truire la v\u00e9locit\u00e9 de livraison.<\/p>\n Avant de plonger dans les solutions, il convient de comprendre comment les pipelines se retrouvent avec des permissions excessives. Le sch\u00e9ma est remarquablement constant d’une organisation \u00e0 l’autre.<\/p>\n Tout commence avec un seul compte de service \u2014 souvent nomm\u00e9 quelque chose comme \u00c9troitement li\u00e9 est le \u00ab token omnipotent \u00bb \u2014 un jeton d’acc\u00e8s personnel ou une cl\u00e9 API avec un acc\u00e8s en lecture\/\u00e9criture \u00e0 tout. Ces tokens sont souvent cr\u00e9\u00e9s par un administrateur lors de la mise en place, stock\u00e9s comme variable CI\/CD, et jamais renouvel\u00e9s. Ils survivent g\u00e9n\u00e9ralement \u00e0 la personne qui les a cr\u00e9\u00e9s, et personne ne se souvient exactement des permissions qu’ils portent.<\/p>\n Les organisations utilisent fr\u00e9quemment un pool unique de runners pour tous les environnements. La m\u00eame machine qui ex\u00e9cute les tests unitaires sur des pull requests non fiables provenant de forks a \u00e9galement acc\u00e8s r\u00e9seau \u00e0 l’infrastructure de production. Le raisonnement est simple : maintenir des pools de runners s\u00e9par\u00e9s est op\u00e9rationnellement co\u00fbteux. Mais cette commodit\u00e9 signifie qu’une pull request malveillante pourrait potentiellement acc\u00e9der aux identifiants de production.<\/p>\n La plupart des pipelines ex\u00e9cutent toutes les \u00e9tapes sous la m\u00eame identit\u00e9. L’\u00e9tape de build, l’\u00e9tape de test, l’\u00e9tape de d\u00e9ploiement \u2014 elles partagent toutes le m\u00eame compte de service, les m\u00eames secrets et le m\u00eame acc\u00e8s r\u00e9seau. Il n’y a pas de fronti\u00e8re entre \u00ab compiler du code \u00bb et \u00ab pousser en production \u00bb. Du point de vue de la s\u00e9curit\u00e9, ce sont des niveaux de confiance fondamentalement diff\u00e9rents qui ne devraient jamais partager une identit\u00e9.<\/p>\n La s\u00e9paration des responsabilit\u00e9s est un principe de conception des contr\u00f4les qui garantit qu’aucune entit\u00e9 unique ne dispose d’un acc\u00e8s suffisant pour accomplir seule un processus critique. En CI\/CD, cela signifie diviser d\u00e9lib\u00e9r\u00e9ment les op\u00e9rations du pipeline entre diff\u00e9rentes identit\u00e9s, approbations et fronti\u00e8res de confiance.<\/p>\n Un pipeline bien con\u00e7u associe la s\u00e9paration des responsabilit\u00e9s \u00e0 des \u00e9tapes distinctes, chacune avec sa propre identit\u00e9 et ses propres permissions :<\/p>\n Chaque fronti\u00e8re d’\u00e9tape est une fronti\u00e8re de confiance. Les identifiants ne circulent pas entre les \u00e9tapes sauf s’ils sont explicitement accord\u00e9s.<\/p>\n Le moindre privil\u00e8ge signifie n’accorder que les permissions minimales requises pour une t\u00e2che sp\u00e9cifique, pour la dur\u00e9e la plus courte n\u00e9cessaire. En CI\/CD, cela se traduit par des mod\u00e8les concrets qui varient selon la plateforme.<\/p>\n GitHub Actions fournit un bloc D\u00e9finissez des valeurs par d\u00e9faut restrictives au niveau du workflow et n’accordez des permissions suppl\u00e9mentaires qu’aux jobs sp\u00e9cifiques qui en ont besoin :<\/p>\n Points cl\u00e9s de cette configuration : chaque job d\u00e9clare uniquement les permissions dont il a besoin, les jobs de d\u00e9ploiement utilisent OIDC pour des identifiants \u00e9ph\u00e9m\u00e8res au lieu de secrets statiques, et le staging et la production utilisent des r\u00f4les IAM diff\u00e9rents avec des niveaux d’acc\u00e8s diff\u00e9rents.<\/p>\n GitLab CI offre un ensemble de contr\u00f4les diff\u00e9rent mais tout aussi puissant pour impl\u00e9menter le moindre privil\u00e8ge :<\/p>\n Dans GitLab, utilisez les variables prot\u00e9g\u00e9es<\/strong> afin que les identifiants de production ne soient disponibles que pour les branches et tags prot\u00e9g\u00e9s. Utilisez les runners prot\u00e9g\u00e9s<\/strong> pour garantir que les jobs de d\u00e9ploiement en production ne s’ex\u00e9cutent que sur une infrastructure durcie et isol\u00e9e. Marquez les secrets de production comme masqu\u00e9s<\/strong> pour pr\u00e9venir toute exposition accidentelle dans les logs.<\/p>\n Au-del\u00e0 de la plateforme CI elle-m\u00eame, appliquez le moindre privil\u00e8ge au niveau du fournisseur cloud. Chaque \u00e9tape du pipeline devrait s’authentifier avec un compte de service diff\u00e9rent disposant de permissions strictement d\u00e9limit\u00e9es :<\/p>\n Les identifiants statiques stock\u00e9s comme secrets CI\/CD sont une dette de s\u00e9curit\u00e9. Ils n’expirent pas, sont difficiles \u00e0 renouveler et constituent des cibles attractives pour les attaquants. L’approche moderne consiste \u00e0 utiliser la f\u00e9d\u00e9ration OIDC pour que votre plateforme CI\/CD \u00e9change un token \u00e9ph\u00e9m\u00e8re, sign\u00e9 par la plateforme, contre des identifiants cloud temporaires :<\/p>\n Si vous utilisez encore des cl\u00e9s d’acc\u00e8s statiques dans les secrets de votre pipeline, la migration vers OIDC devrait \u00eatre une initiative hautement prioritaire.<\/p>\n Le pipeline-as-code est puissant, mais il introduit un probl\u00e8me de confiance subtil : si un attaquant peut modifier la d\u00e9finition du pipeline, il contr\u00f4le comment le code est construit, test\u00e9 et d\u00e9ploy\u00e9. Prot\u00e9ger les fichiers de configuration du pipeline est tout aussi important que prot\u00e9ger le code applicatif lui-m\u00eame.<\/p>\n Utilisez un fichier CODEOWNERS pour exiger que des \u00e9quipes sp\u00e9cifiques examinent les modifications apport\u00e9es \u00e0 la configuration CI\/CD :<\/p>\n Cela garantit que personne ne peut modifier les d\u00e9finitions de pipeline sans l’approbation de l’\u00e9quipe responsable de la s\u00e9curit\u00e9 CI\/CD. Combinez cela avec des r\u00e8gles de protection de branches qui exigent l’approbation des CODEOWNERS.<\/p>\n Appliquez des r\u00e8gles de protection de branche qui emp\u00eachent les pushs directs vers les branches contenant les d\u00e9finitions de pipeline. Au minimum :<\/p>\n GitHub Actions et GitLab CI supportent tous deux le r\u00e9f\u00e9rencement de d\u00e9finitions de pipeline depuis des d\u00e9p\u00f4ts externes g\u00e9r\u00e9s de mani\u00e8re centralis\u00e9e :<\/p>\n Workflows r\u00e9utilisables GitHub Actions :<\/strong><\/p>\n Inclusions GitLab CI depuis des d\u00e9p\u00f4ts prot\u00e9g\u00e9s :<\/strong><\/p>\n En \u00e9pinglant des versions sp\u00e9cifiques (tags ou SHA de commits) et en restreignant qui peut modifier le d\u00e9p\u00f4t de templates, vous garantissez que les \u00e9quipes individuelles ne peuvent pas alt\u00e9rer les contr\u00f4les de s\u00e9curit\u00e9 int\u00e9gr\u00e9s au processus de d\u00e9ploiement.<\/p>\n Un pipeline ne devrait jamais pouvoir modifier sa propre d\u00e9finition. Surveillez ces sch\u00e9mas :<\/p>\n Si vous avez besoin d’un comportement dynamique de pipeline, utilisez des templates param\u00e9tr\u00e9s avec un ensemble fixe d’entr\u00e9es autoris\u00e9es plut\u00f4t que de permettre la modification arbitraire de la logique du pipeline.<\/p>\n Les contr\u00f4les de d\u00e9ploiement sont les portes entre les \u00e9tapes du pipeline qui imposent la supervision humaine et la conformit\u00e9 aux politiques. C’est l\u00e0 que la s\u00e9paration des responsabilit\u00e9s devient tangible.<\/p>\n Les d\u00e9ploiements en production devraient exiger une approbation explicite de quelqu’un d’autre que l’auteur du code. Les deux principales plateformes supportent cela nativement :<\/p>\n Les GitHub Environments sont un m\u00e9canisme puissant pour les contr\u00f4les de d\u00e9ploiement. Configurez-les avec :<\/p>\n Impl\u00e9mentez des gels de d\u00e9ploiement pendant les p\u00e9riodes commerciales critiques (par exemple, Black Friday, fin de trimestre) en :<\/p>\n Les strat\u00e9gies de d\u00e9ploiement progressif ne sont pas seulement une pr\u00e9occupation de disponibilit\u00e9 \u2014 elles constituent un contr\u00f4le de s\u00e9curit\u00e9. Si un artefact compromis passe tous les autres contr\u00f4les, un d\u00e9ploiement canary limite le rayon d’impact :<\/p>\n La s\u00e9paration des responsabilit\u00e9s et le moindre privil\u00e8ge ne sont efficaces que si vous pouvez v\u00e9rifier qu’ils sont respect\u00e9s. L’audit et la tra\u00e7abilit\u00e9 bouclent la boucle en fournissant la preuve de qui a fait quoi, quand et pourquoi.<\/p>\n Les plateformes CI\/CD maintiennent des logs d\u00e9taill\u00e9s de chaque ex\u00e9cution de pipeline. Traitez ces logs comme des donn\u00e9es d’audit pertinentes pour la s\u00e9curit\u00e9 :<\/p>\n Chaque d\u00e9ploiement en production devrait \u00eatre tra\u00e7able jusqu’\u00e0 :<\/p>\n Cette cha\u00eene de tra\u00e7abilit\u00e9 devrait \u00eatre automatis\u00e9e. Si quelqu’un demande \u00ab qu’est-ce qui tourne en production et qui l’a approuv\u00e9 \u00bb, la r\u00e9ponse devrait \u00eatre disponible en secondes, pas en heures.<\/p>\n Les actions du pipeline laissent des traces dans les logs d’audit du fournisseur cloud. Corr\u00e9lez-les avec vos logs CI\/CD :<\/p>\n Configurez des alertes pour les \u00e9v\u00e9nements qui indiquent que vos contr\u00f4les sont contourn\u00e9s :<\/p>\n Int\u00e9grez ces alertes dans votre workflow d’op\u00e9rations de s\u00e9curit\u00e9 et traitez-les avec la m\u00eame urgence que les incidents de production.<\/p>\n Savoir quoi \u00e9viter est tout aussi important que savoir quoi impl\u00e9menter. Voici les anti-patterns que nous rencontrons le plus fr\u00e9quemment lors des \u00e9valuations de s\u00e9curit\u00e9 CI\/CD.<\/p>\n Un jeton d’acc\u00e8s personnel avec une port\u00e9e admin, cr\u00e9\u00e9 par un ing\u00e9nieur senior, stock\u00e9 comme secret de d\u00e9p\u00f4t, et utilis\u00e9 par chaque job dans chaque pipeline. Quand cet ing\u00e9nieur quitte l’organisation, personne ne r\u00e9voque le token parce que personne ne sait ce qui cessera de fonctionner. C’est l’anti-pattern le plus courant et le plus dangereux.<\/p>\n Correction :<\/strong> Remplacez par des comptes de service par \u00e9tape utilisant la f\u00e9d\u00e9ration OIDC. Aucun token statique, aucune identit\u00e9 partag\u00e9e.<\/p>\n Un d\u00e9ploiement est bloqu\u00e9 parce qu’une v\u00e9rification requise \u00e9choue. Quelqu’un d\u00e9sactive la protection de branche pour pousser directement sur main, avec l’intention de la r\u00e9activer plus tard. Il oublie, ou il la r\u00e9active mais manque un param\u00e8tre. Entre-temps, la fen\u00eatre non prot\u00e9g\u00e9e a permis un push direct qui a contourn\u00e9 la revue de code.<\/p>\n Correction :<\/strong> Ne d\u00e9sactivez jamais la protection de branche. Si une v\u00e9rification requise \u00e9choue, corrigez la v\u00e9rification ou utilisez un processus d’urgence qui exige plusieurs approbations et cr\u00e9e une piste d’audit.<\/p>\n Les pipelines de pull request provenant de forks s’ex\u00e9cutent sur la m\u00eame infrastructure qui a acc\u00e8s r\u00e9seau aux syst\u00e8mes de production. Une PR malveillante peut exfiltrer des secrets, acc\u00e9der \u00e0 des services internes ou pivoter vers l’infrastructure de production.<\/p>\n Correction :<\/strong> Utilisez des pools de runners s\u00e9par\u00e9s. Les charges de travail non fiables (PR, surtout celles provenant de forks) s’ex\u00e9cutent sur des runners \u00e9ph\u00e9m\u00e8res et isol\u00e9s sans acc\u00e8s aux environnements sensibles. Les runners de d\u00e9ploiement en production sont restreints aux branches prot\u00e9g\u00e9es uniquement.<\/p>\n Lorsqu’un pipeline de d\u00e9ploiement \u00e9choue, un ing\u00e9nieur se connecte en SSH directement \u00e0 un serveur de production et d\u00e9ploie manuellement. Cela contourne chaque contr\u00f4le du pipeline : revue de code, tests automatis\u00e9s, signature d’artefact, approbation de d\u00e9ploiement et journalisation d’audit.<\/p>\n Correction :<\/strong> Investissez dans la fiabilit\u00e9 du pipeline pour que l’intervention manuelle soit rarement n\u00e9cessaire. Quand elle l’est, utilisez une proc\u00e9dure de bris de glace qui exige plusieurs approbations, cr\u00e9e une piste d’audit et d\u00e9clenche une revue post-incident.<\/p>\n La s\u00e9paration des responsabilit\u00e9s et le moindre privil\u00e8ge ne sont pas des contraintes bureaucratiques impos\u00e9es par une \u00e9quipe de conformit\u00e9. Ce sont des contr\u00f4les d’ing\u00e9nierie qui r\u00e9duisent directement le rayon d’impact des incidents de s\u00e9curit\u00e9 dans votre pipeline de livraison logicielle.<\/p>\n Une \u00e9tape de build compromise avec le moindre privil\u00e8ge peut produire un artefact malveillant \u2014 mais elle ne peut pas d\u00e9ployer cet artefact en production. Un identifiant de d\u00e9ploiement compromis limit\u00e9 au staging ne peut pas atteindre la production. Une pull request malveillante trait\u00e9e par un runner isol\u00e9 ne peut pas exfiltrer les secrets de production. Chaque contr\u00f4le limite ce qu’un attaquant peut accomplir \u00e0 chaque \u00e9tape.<\/p>\n Commencez par auditer les permissions actuelles de votre pipeline. Identifiez chaque compte de service, chaque identifiant stock\u00e9 et chaque secret auquel votre pipeline peut acc\u00e9der. Associez chacun \u00e0 l’\u00e9tape et \u00e0 la t\u00e2che sp\u00e9cifique qui en a besoin. Puis commencez \u00e0 r\u00e9duire la port\u00e9e : remplacez les identifiants statiques par OIDC, divisez les comptes de service uniques en identit\u00e9s par \u00e9tape, ajoutez des portes d’approbation pour les d\u00e9ploiements en production et prot\u00e9gez vos d\u00e9finitions de pipeline avec CODEOWNERS et la protection de branche.<\/p>\n Vous n’avez pas besoin de tout faire en une fois. Chaque am\u00e9lioration incr\u00e9mentale r\u00e9duit le risque. Mais commencez \u2014 car votre pipeline CI\/CD est probablement le syst\u00e8me le plus privil\u00e9gi\u00e9 et le moins scrut\u00e9 de toute votre infrastructure.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction La plupart des pipelines CI\/CD d\u00e9marrent avec un objectif simple : acheminer le code depuis la machine d’un d\u00e9veloppeur vers la production le plus rapidement possible. En cours de route, quelqu’un cr\u00e9e un compte de service, lui accorde des permissions larges, stocke les identifiants comme secret du pipeline, et passe \u00e0 autre chose. Cela … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,51],"tags":[],"post_folder":[],"class_list":["post-500","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-pipeline-hardening"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/500","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=500"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/500\/revisions"}],"predecessor-version":[{"id":516,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/500\/revisions\/516"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=500"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=500"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=500"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=500"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Pourquoi les pipelines accumulent les privil\u00e8ges<\/h2>\n
Le probl\u00e8me du compte de service unique<\/h3>\n
ci-deployer<\/code> ou pipeline-bot<\/code> \u2014 cr\u00e9\u00e9 lors de la mise en place initiale du CI\/CD. Ce compte a besoin de r\u00e9cup\u00e9rer le code, donc il obtient l’acc\u00e8s en lecture au d\u00e9p\u00f4t. Puis il a besoin de pousser des images Docker, donc il obtient l’acc\u00e8s en \u00e9criture au registre. Puis il doit d\u00e9ployer en staging, puis en production, puis g\u00e9rer l’infrastructure. En quelques semaines, cette seule identit\u00e9 peut construire, tester, d\u00e9ployer et acc\u00e9der aux donn\u00e9es de production. Elle est devenue un passe-partout.<\/p>\nLes tokens omnipotents<\/h3>\n
La commodit\u00e9 avant la s\u00e9curit\u00e9<\/h3>\n
Absence de fronti\u00e8res d’identit\u00e9 entre les \u00e9tapes<\/h3>\n
S\u00e9paration des responsabilit\u00e9s dans le CI\/CD<\/h2>\n
Principes fondamentaux pour la SoD des pipelines<\/h3>\n
\n
Correspondance entre SoD et \u00e9tapes du pipeline<\/h3>\n
\n
Mod\u00e8les de moindre privil\u00e8ge<\/h2>\n
GitHub Actions : permissions par job<\/h3>\n
permissions<\/code> qui contr\u00f4le les port\u00e9es du GITHUB_TOKEN<\/code> g\u00e9n\u00e9r\u00e9 automatiquement. Par d\u00e9faut, ce token dispose d’un acc\u00e8s large en lecture\/\u00e9criture. Vous devriez toujours le restreindre.<\/p>\n# .github\/workflows\/deploy.yml\nname: Build and Deploy\n\n# Restrict default permissions for ALL jobs in this workflow\npermissions:\n contents: read\n\non:\n push:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n # This job inherits the workflow-level permissions: contents read only\n steps:\n - uses: actions\/checkout@v4\n - run: make build\n - uses: actions\/upload-artifact@v4\n with:\n name: app-binary\n path: dist\/\n\n security-scan:\n needs: build\n runs-on: ubuntu-latest\n permissions:\n security-events: write # Only this job can write security findings\n contents: read\n steps:\n - uses: actions\/checkout@v4\n - uses: github\/codeql-action\/analyze@v3\n\n deploy-staging:\n needs: [build, security-scan]\n runs-on: ubuntu-latest\n environment: staging # Scoped to staging secrets only\n permissions:\n contents: read\n id-token: write # OIDC token for cloud auth \u2014 no static credentials\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789:role\/staging-deployer\n aws-region: us-east-1\n - run: .\/scripts\/deploy.sh staging\n\n deploy-production:\n needs: deploy-staging\n runs-on: ubuntu-latest\n environment: production # Requires manual approval + different secrets\n permissions:\n contents: read\n id-token: write\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789:role\/production-deployer\n aws-region: us-east-1\n - run: .\/scripts\/deploy.sh production<\/code><\/pre>\nGitLab CI : variables prot\u00e9g\u00e9es et runners<\/h3>\n
# .gitlab-ci.yml\nstages:\n - build\n - test\n - deploy-staging\n - deploy-production\n\nbuild:\n stage: build\n tags:\n - shared-runners # Non-privileged runners for build\n script:\n - make build\n artifacts:\n paths:\n - dist\/\n\ntest:\n stage: test\n tags:\n - shared-runners\n script:\n - make test\n dependencies:\n - build\n\ndeploy-staging:\n stage: deploy-staging\n tags:\n - deploy-runners # Dedicated runners with network access to staging\n environment:\n name: staging\n script:\n - .\/scripts\/deploy.sh staging\n # CI_JOB_TOKEN is automatically scoped to this project\n # Staging secrets are only available on protected branches\n rules:\n - if: '$CI_COMMIT_BRANCH == \"main\"'\n\ndeploy-production:\n stage: deploy-production\n tags:\n - production-runners # Isolated runners with production network access\n environment:\n name: production\n script:\n - .\/scripts\/deploy.sh production\n rules:\n - if: '$CI_COMMIT_BRANCH == \"main\"'\n when: manual # Requires manual approval\n allow_failure: false # Block the pipeline if not approved<\/code><\/pre>\nComptes de service par \u00e9tape avec r\u00f4les IAM scop\u00e9s<\/h3>\n
\n
Identifiants \u00e9ph\u00e9m\u00e8res via OIDC<\/h3>\n
\n
id-token: write<\/code> \u2014 aucun secret stock\u00e9 n’est n\u00e9cessaire.<\/li>\nCI_JOB_JWT<\/code> ou le mot-cl\u00e9 id_tokens<\/code>, permettant le m\u00eame mod\u00e8le.<\/li>\nProt\u00e9ger les d\u00e9finitions de pipeline<\/h2>\n
CODEOWNERS pour les fichiers de workflow<\/h3>\n
# .github\/CODEOWNERS\n\/.github\/workflows\/ @your-org\/platform-security\n\/.gitlab-ci.yml @your-org\/platform-security\n\/Jenkinsfile @your-org\/platform-security\n\/terraform\/ @your-org\/infrastructure<\/code><\/pre>\nProtection de branche sur les r\u00e9pertoires de configuration du pipeline<\/h3>\n
\n
Templates de pipeline immuables<\/h3>\n
# In your repository's workflow, reference a centrally managed template\njobs:\n deploy:\n uses: your-org\/shared-workflows\/.github\/workflows\/secure-deploy.yml@v2.1.0\n with:\n environment: production\n artifact-name: app-binary\n secrets: inherit<\/code><\/pre>\n# .gitlab-ci.yml\ninclude:\n - project: 'platform-team\/ci-templates'\n ref: 'v3.0.0'\n file: '\/templates\/secure-deploy.yml'\n\n# Local jobs can use templates but cannot override protected stages\ndeploy-production:\n extends: .secure-deploy-template\n variables:\n TARGET_ENV: production<\/code><\/pre>\nEmp\u00eacher les pipelines auto-modifiants<\/h3>\n
\n
.github\/workflows\/<\/code> ou .gitlab-ci.yml<\/code> et commitent les modifications.<\/li>\nContr\u00f4les de d\u00e9ploiement<\/h2>\n
R\u00e9viseurs requis et approbations manuelles<\/h3>\n
\n
when: manual<\/code>, cela cr\u00e9e une porte d’approbation.<\/li>\n<\/ul>\nGitHub Environments avec r\u00e8gles de protection<\/h3>\n
\n
main<\/code> ou release\/*<\/code>.<\/li>\nGels de d\u00e9ploiement et fen\u00eatres de changement<\/h3>\n
\n
Canary et d\u00e9ploiement progressif comme m\u00e9canisme de contr\u00f4le<\/h3>\n
\n
Audit et tra\u00e7abilit\u00e9<\/h2>\n
Logs d’ex\u00e9cution de pipeline comme pistes d’audit<\/h3>\n
\n
Lier les d\u00e9ploiements aux commits et aux approbateurs<\/h3>\n
\n
Logs d’audit cloud pour les changements initi\u00e9s par le pipeline<\/h3>\n
\n
userIdentity.sessionContext<\/code> de CloudTrail pour lier les changements cloud \u00e0 des ex\u00e9cutions de pipeline sp\u00e9cifiques.<\/li>\nAlertes sur l’escalade de privil\u00e8ges ou le contournement des politiques<\/h3>\n
\n
Anti-patterns courants<\/h2>\n
Un seul token admin pour toutes les op\u00e9rations CI\/CD<\/h3>\n
D\u00e9sactiver la protection de branche \u00ab temporairement \u00bb<\/h3>\n
Runners partag\u00e9s entre production et charges de travail de PR<\/h3>\n
Acc\u00e8s SSH manuel quand les pipelines \u00e9chouent<\/h3>\n
Conclusion<\/h2>\n