GitLab CI\/CD est devenu la colonne vert\u00e9brale du DevSecOps moderne : il offre une plateforme int\u00e9gr\u00e9e o\u00f9 le code, les pipelines, l’analyse de s\u00e9curit\u00e9 et les d\u00e9ploiements convergent dans une seule interface. Mais cette int\u00e9gration profonde est une arme \u00e0 double tranchant : un pipeline mal configur\u00e9 peut exposer des secrets, autoriser des d\u00e9ploiements non autoris\u00e9s ou donner \u00e0 des attaquants un point d’ancrage dans votre infrastructure.<\/p>\n\n
Ce guide d\u00e9finitif couvre toutes les surfaces pertinentes pour la s\u00e9curit\u00e9 de GitLab CI\/CD \u2014 des variables prot\u00e9g\u00e9es et du p\u00e9rim\u00e8tre des runners \u00e0 la f\u00e9d\u00e9ration OIDC et \u00e0 la s\u00fbret\u00e9 des pipelines de merge request. Que vous durcissiez une installation GitLab existante ou que vous construisiez une pratique DevSecOps \u00e0 partir de z\u00e9ro, cet article vous donne les connaissances et les checklists concr\u00e8tes dont vous avez besoin.<\/p>\n\n
GitLab se pr\u00e9sente comme la \u00ab One DevOps Platform \u00bb, et \u00e0 juste titre. Contr\u00f4le de version, suivi des tickets, CI\/CD, container registry, package registry, analyse de s\u00e9curit\u00e9 et gestion des d\u00e9ploiements vivent tous sous le m\u00eame toit. Cette consolidation simplifie l’outillage \u2014 mais elle concentre aussi le risque. Un seul job de pipeline compromis peut potentiellement lire le code source, voler des identifiants, pousser des images malveillantes et d\u00e9clencher des d\u00e9ploiements en production.<\/p>\n\n
Les r\u00e9centes attaques de la cha\u00eene d’approvisionnement ont d\u00e9montr\u00e9 que les pipelines CI\/CD sont des cibles de grande valeur. Les attaquants qui parviennent \u00e0 injecter des \u00e9tapes dans un pipeline \u2014 que ce soit via une d\u00e9pendance empoisonn\u00e9e, un runner partag\u00e9 compromis ou une merge request malveillante \u2014 peuvent exfiltrer des secrets, alt\u00e9rer des artifacts de build ou se d\u00e9placer lat\u00e9ralement vers des environnements cloud. GitLab fournit un riche ensemble de contr\u00f4les pour pr\u00e9venir ces sc\u00e9narios, mais uniquement si vous les comprenez et les activez.<\/p>\n\n
Avant de plonger dans les contr\u00f4les individuels, il est utile de comprendre les quatre piliers du mod\u00e8le de s\u00e9curit\u00e9 de GitLab CI :<\/p>\n\n
CI_JOB_TOKEN<\/code>, OIDC id_tokens<\/code>) qui authentifient les jobs aupr\u00e8s d’autres services. Le p\u00e9rim\u00e8tre limite leur rayon d’impact.<\/li>\n<\/ol>\n\nChaque mesure de durcissement de ce guide se rattache \u00e0 un ou plusieurs de ces piliers. Ma\u00eetrisez les quatre, et vous obtiendrez une posture de d\u00e9fense en profondeur capable de r\u00e9sister aussi bien aux erreurs internes qu’aux attaques externes.<\/p>\n\n
Variables prot\u00e9g\u00e9es et masqu\u00e9es<\/h2>\n\n
Les variables CI\/CD sont le principal m\u00e9canisme d’injection de secrets \u2014 cl\u00e9s API, identifiants cloud, mots de passe de bases de donn\u00e9es \u2014 dans les jobs de pipeline. GitLab propose deux protections orthogonales : la protection<\/strong> et le masquage<\/strong>.<\/p>\n\nVariables prot\u00e9g\u00e9es<\/h3>\n\n
Lorsqu’une variable est marqu\u00e9e comme prot\u00e9g\u00e9e<\/em>, GitLab ne l’expose qu’aux jobs s’ex\u00e9cutant sur des branches prot\u00e9g\u00e9es<\/strong> ou tags prot\u00e9g\u00e9s<\/strong>. C’est un contr\u00f4le essentiel : cela signifie qu’un d\u00e9veloppeur qui ouvre une merge request depuis une branche de fonctionnalit\u00e9 ne peut pas \u00e9crire une \u00e9tape de pipeline qui affiche vos identifiants AWS de production. La variable n’existe tout simplement pas dans l’environnement du job pour les r\u00e9f\u00e9rences non prot\u00e9g\u00e9es.<\/p>\n\nBonnes pratiques pour les variables prot\u00e9g\u00e9es :<\/strong><\/p>\n\n\n- Marquez chaque secret de production comme prot\u00e9g\u00e9. Il n’existe aucune raison valable pour qu’un job de branche de fonctionnalit\u00e9 acc\u00e8de aux identifiants de production.<\/li>\n
- Limitez qui peut pousser ou fusionner dans les branches prot\u00e9g\u00e9es (r\u00f4le Maintainer ou sup\u00e9rieur). Cela cr\u00e9e une porte humaine avant que les secrets ne soient accessibles.<\/li>\n
- Utilisez des variables \u00e0 port\u00e9e d’environnement lorsque le m\u00eame nom de secret diff\u00e8re entre staging et production. GitLab injectera la valeur correcte en fonction du mot-cl\u00e9
environment:<\/code> pr\u00e9sent dans la d\u00e9finition du job.<\/li>\n- Renouvelez r\u00e9guli\u00e8rement les variables prot\u00e9g\u00e9es. M\u00eame les variables prot\u00e9g\u00e9es peuvent fuiter via une journalisation mal configur\u00e9e ou des runners compromis.<\/li>\n<\/ul>\n\n
Variables masqu\u00e9es<\/h3>\n\n
Le masquage emp\u00eache la valeur d’une variable d’appara\u00eetre dans les logs des jobs. GitLab remplace toute occurrence de la valeur par [MASKED]<\/code>. Le masquage est un filet de s\u00e9curit\u00e9, pas une fronti\u00e8re de s\u00e9curit\u00e9 \u2014 il prot\u00e8ge contre une exposition accidentelle (par exemple, une commande curl<\/code> verbeuse qui journalise les en-t\u00eates) mais n’emp\u00eache pas une \u00e9tape de job malveillante d’encoder la valeur en Base64 ou de l’\u00e9crire dans un artifact.<\/p>\n\nCombinez protection et masquage.<\/strong> Une variable \u00e0 la fois prot\u00e9g\u00e9e et<\/em> masqu\u00e9e vous offre la meilleure d\u00e9fense int\u00e9gr\u00e9e : un p\u00e9rim\u00e8tre de branche limit\u00e9 plus une expurgation au niveau des logs.<\/p>\n\nTypes de runners et p\u00e9rim\u00e8tre<\/h2>\n\n
Les runners sont l’endroit o\u00f9 votre code s’ex\u00e9cute r\u00e9ellement. Comprendre les types de runners et leurs implications de s\u00e9curit\u00e9 est essentiel pour un environnement GitLab CI durci.<\/p>\n\n
Runners partag\u00e9s, de groupe et de projet<\/h3>\n\n
GitLab prend en charge trois p\u00e9rim\u00e8tres pour les runners :<\/p>\n\n
\n- Runners partag\u00e9s<\/strong> \u2014 disponibles pour tous les projets de l’instance. Pratiques mais les plus risqu\u00e9s : un projet malveillant peut potentiellement laisser des artifacts, des caches ou des processus qui affectent le job suivant d’un projet sans lien.<\/li>\n
- Runners de groupe<\/strong> \u2014 disponibles pour tous les projets d’un groupe donn\u00e9. Un compromis raisonnable qui limite l’exposition inter-projets tout en r\u00e9duisant la charge de gestion des runners.<\/li>\n
- Runners de projet<\/strong> \u2014 d\u00e9di\u00e9s \u00e0 un seul projet. Isolation maximale, mais co\u00fbt op\u00e9rationnel plus \u00e9lev\u00e9. Recommand\u00e9s pour les d\u00e9p\u00f4ts \u00e0 forte exigence de s\u00e9curit\u00e9 qui manipulent des secrets de production ou des donn\u00e9es clients sensibles.<\/li>\n<\/ul>\n\n
Runners prot\u00e9g\u00e9s<\/h3>\n\n
N’importe quel runner peut \u00eatre marqu\u00e9 comme prot\u00e9g\u00e9<\/strong>. Un runner prot\u00e9g\u00e9 ne prend que les jobs des branches prot\u00e9g\u00e9es ou des tags prot\u00e9g\u00e9s. Cela se marie naturellement avec les variables prot\u00e9g\u00e9es : votre runner de d\u00e9ploiement en production ne s’ex\u00e9cute que sur main<\/code>, et seuls les jobs sur main<\/code> ont acc\u00e8s aux secrets de production.<\/p>\n\nChecklist de durcissement des runners :<\/strong><\/p>\n\n\n- Utilisez des runners \u00e9ph\u00e9m\u00e8res (mis \u00e0 l’\u00e9chelle automatiquement, d\u00e9truits apr\u00e8s chaque job) pour \u00e9liminer la persistance des donn\u00e9es entre les jobs.<\/li>\n
- N’utilisez Docker-in-Docker avec
--privileged<\/code> que lorsque c’est absolument n\u00e9cessaire, et isolez ces runners dans un groupe de s\u00e9curit\u00e9 d\u00e9di\u00e9.<\/li>\n- D\u00e9sactivez l’ex\u00e9cuteur shell sur les runners partag\u00e9s. Utilisez les ex\u00e9cuteurs Docker ou Kubernetes avec des contextes de s\u00e9curit\u00e9 restrictifs.<\/li>\n
- Taguez les runners de d\u00e9ploiement en production et verrouillez-les \u00e0 des projets et des branches prot\u00e9g\u00e9es sp\u00e9cifiques.<\/li>\n
- Auditez les tokens d’enregistrement des runners \u2014 renouvelez-les r\u00e9guli\u00e8rement et r\u00e9voquez imm\u00e9diatement tout token divulgu\u00e9.<\/li>\n<\/ul>\n\n
Environnements prot\u00e9g\u00e9s et approbations de d\u00e9ploiement<\/h2>\n\n
Les environnements GitLab repr\u00e9sentent des cibles de d\u00e9ploiement telles que staging<\/code>, production<\/code>, ou canary<\/code>. Prot\u00e9ger un environnement ajoute une couche d’autorisation qui va au-del\u00e0 de la protection de branche.<\/p>\n\nComment fonctionnent les environnements prot\u00e9g\u00e9s<\/h3>\n\n
Lorsque vous prot\u00e9gez un environnement, vous pr\u00e9cisez quels utilisateurs ou groupes sont autoris\u00e9s \u00e0 y d\u00e9ployer. M\u00eame si un pipeline s’ex\u00e9cute sur une branche prot\u00e9g\u00e9e, le job de d\u00e9ploiement ne s’ex\u00e9cutera pas si l’utilisateur d\u00e9clencheur n’a pas la permission requise. Cela cr\u00e9e une s\u00e9paration des responsabilit\u00e9s : les d\u00e9veloppeurs peuvent fusionner du code, mais seuls les d\u00e9ployeurs d\u00e9sign\u00e9s peuvent le pousser en production.<\/p>\n\n
Approbations de d\u00e9ploiement (Premium\/Ultimate)<\/h3>\n\n
Les \u00e9ditions GitLab Premium et Ultimate proposent les approbations de d\u00e9ploiement<\/strong> \u2014 un m\u00e9canisme qui met en pause un job de d\u00e9ploiement et attend qu’un ou plusieurs approbateurs d\u00e9sign\u00e9s donnent leur feu vert. C’est pr\u00e9cieux pour les environnements r\u00e9glement\u00e9s o\u00f9 les processus de gestion des changements exigent une validation humaine avant que les changements n’atteignent la production.<\/p>\n\nConseils de configuration :<\/strong><\/p>\n\n\n- Exigez au moins deux approbateurs pour les d\u00e9ploiements en production afin d’\u00e9viter une compromission par une seule personne.<\/li>\n
- D\u00e9finissez les r\u00e8gles d’approbation au niveau du groupe pour qu’elles s’appliquent de mani\u00e8re coh\u00e9rente \u00e0 tous les projets d’une m\u00eame unit\u00e9 op\u00e9rationnelle.<\/li>\n
- Combinez les approbations de d\u00e9ploiement avec des runners prot\u00e9g\u00e9s et des variables prot\u00e9g\u00e9es pour une d\u00e9fense en couches.<\/li>\n
- Utilisez le mot-cl\u00e9
environment: deployment_tier<\/code> pour classer les environnements (production, staging, testing, development) et appliquer les politiques appropri\u00e9es \u00e0 chaque niveau.<\/li>\n<\/ul>\n\nP\u00e9rim\u00e8tre du CI_JOB_TOKEN<\/h2>\n\n
Chaque job GitLab CI re\u00e7oit un CI_JOB_TOKEN<\/code> g\u00e9n\u00e9r\u00e9 automatiquement \u2014 un identifiant de courte dur\u00e9e qui authentifie le job aupr\u00e8s de l’API GitLab, du container registry et du package registry. Par d\u00e9faut, ce token peut acc\u00e9der \u00e0 des ressources dans plusieurs projets, ce qui cr\u00e9e un risque de mouvement lat\u00e9ral.<\/p>\n\nLimiter l’acc\u00e8s du CI_JOB_TOKEN<\/h3>\n\n
GitLab 15.9+ a introduit les contr\u00f4les de p\u00e9rim\u00e8tre du token de job CI\/CD<\/strong> . Vous pouvez d\u00e9sormais configurer une liste d’autorisation des projets auxquels le CI_JOB_TOKEN<\/code> d’un projet donn\u00e9 peut acc\u00e9der. C’est un r\u00e9glage indispensable \u00e0 activer pour toute organisation soucieuse de sa s\u00e9curit\u00e9.<\/p>\n\n\u00c9tapes pour durcir le CI_JOB_TOKEN :<\/strong><\/p>\n\n\n- Acc\u00e9dez \u00e0 Settings > CI\/CD > Token Access<\/strong> dans votre projet.<\/li>\n
- Activez Limit CI_JOB_TOKEN access<\/strong> (cela restreint le token au projet courant par d\u00e9faut).<\/li>\n
- Ajoutez uniquement les projets sp\u00e9cifiques auxquels les jobs de ce projet ont l\u00e9gitimement besoin d’acc\u00e9der.<\/li>\n
- R\u00e9visez la liste d’autorisation chaque trimestre et supprimez les entr\u00e9es obsol\u00e8tes.<\/li>\n<\/ol>\n\n
Avec des tokens \u00e0 p\u00e9rim\u00e8tre restreint, m\u00eame si un attaquant compromet un job de pipeline, le rayon d’impact se limite aux projets explicitement autoris\u00e9s plut\u00f4t qu’\u00e0 l’ensemble de l’instance GitLab.<\/p>\n\n
F\u00e9d\u00e9ration OIDC avec id_tokens<\/h2>\n\n
Les identifiants cloud cod\u00e9s en dur dans les variables CI sont un risque de s\u00e9curit\u00e9 persistant. La prise en charge d’ OIDC (OpenID Connect)<\/strong> par GitLab \u00e9limine enti\u00e8rement ce risque en permettant aux jobs de pipeline de s’authentifier aupr\u00e8s des fournisseurs cloud \u00e0 l’aide de tokens de courte dur\u00e9e, sign\u00e9s cryptographiquement.<\/p>\n\nComment \u00e7a fonctionne<\/h3>\n\n
Lorsque vous d\u00e9finissez un bloc id_tokens<\/code> dans votre .gitlab-ci.yml<\/code>, GitLab g\u00e9n\u00e8re un JWT sign\u00e9 pour chaque job. Le JWT contient des claims sur le job \u2014 chemin du projet, nom de la r\u00e9f\u00e9rence, environnement, source du pipeline \u2014 que le fournisseur cloud peut \u00e9valuer par rapport \u00e0 sa politique de confiance.<\/p>\n\ndeploy_production:\n id_tokens:\n GITLAB_OIDC_TOKEN:\n aud: https:\/\/aws.example.com\n script:\n - |\n export AWS_WEB_IDENTITY_TOKEN_FILE=$(mktemp)\n echo \"$GITLAB_OIDC_TOKEN\" > $AWS_WEB_IDENTITY_TOKEN_FILE\n aws sts assume-role-with-web-identity \\\n --role-arn arn:aws:iam::123456789012:role\/gitlab-deploy \\\n --web-identity-token file:\/\/$AWS_WEB_IDENTITY_TOKEN_FILE\n<\/code><\/pre>\n\nDu c\u00f4t\u00e9 cloud (AWS, GCP, Azure), vous configurez une politique de confiance qui n’accepte que les tokens provenant de projets, de branches et d’environnements sp\u00e9cifiques. Cela signifie :<\/p>\n\n
\n- Aucun identifiant statique<\/strong> \u00e0 renouveler ou \u00e0 divulguer.<\/li>\n
- Acc\u00e8s \u00e0 grain fin<\/strong> \u2014 un token provenant d’une branche de fonctionnalit\u00e9 peut \u00eatre rejet\u00e9 par le fournisseur cloud, m\u00eame si le pipeline est par ailleurs valide.<\/li>\n
- Auditabilit\u00e9<\/strong> \u2014 chaque \u00e9v\u00e9nement d’authentification est journalis\u00e9 avec l’ensemble des claims du JWT.<\/li>\n<\/ul>\n\n
Pour une exploration approfondie des sch\u00e9mas de f\u00e9d\u00e9ration OIDC sur AWS, GCP et Azure, consultez notre guide d\u00e9di\u00e9 : Identifiants de courte dur\u00e9e et f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail pour la CI\/CD<\/a>.<\/p>\n\nS\u00e9curit\u00e9 des pipelines de merge request<\/h2>\n\n
Les merge requests sont le vecteur le plus courant d’injection de code malveillant dans les pipelines. Un contributeur externe (ou un compte compromis) peut soumettre une merge request qui modifie .gitlab-ci.yml<\/code> pour exfiltrer des secrets ou \u00e9tablir une persistance.<\/p>\n\nProtections essentielles<\/h3>\n\n\n- Utilisez
rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event'<\/code><\/strong> pour cr\u00e9er des pipelines de MR d\u00e9di\u00e9s qui s’ex\u00e9cutent avec des privil\u00e8ges r\u00e9duits. Les pipelines de MR provenant de forks n’ont pas acc\u00e8s aux variables prot\u00e9g\u00e9es par d\u00e9faut.<\/li>\n- Exigez la r\u00e9ussite du pipeline avant la fusion.<\/strong> Cela garantit que les analyses de s\u00e9curit\u00e9 (SAST, analyse des d\u00e9pendances, d\u00e9tection de secrets) s’ex\u00e9cutent sur chaque MR.<\/li>\n
- Limitez les
include:<\/code> aux sources de confiance.<\/strong> Des MR malveillantes peuvent ajouter des directives include: remote:<\/code> qui importent du YAML contr\u00f4l\u00e9 par l’attaquant. Utilisez une liste d’autorisation des domaines d’include permis ou \u00e9pinglez \u00e0 des r\u00e9f\u00e9rences pr\u00e9cises.<\/li>\n- Activez \u00ab Pipelines must succeed \u00bb et \u00ab All threads must be resolved \u00bb<\/strong> dans les param\u00e8tres de merge request de votre projet.<\/li>\n
- Examinez les modifications de
.gitlab-ci.yml<\/code> avec soin.<\/strong> Toute MR qui modifie la configuration du pipeline devrait exiger l’approbation d’un r\u00e9viseur sensibilis\u00e9 \u00e0 la s\u00e9curit\u00e9.<\/li>\n<\/ul>\n\nRestrictions des pipelines de fork<\/h3>\n\n
Pour les projets publics ou open source, les pipelines de fork pr\u00e9sentent des risques suppl\u00e9mentaires. GitLab vous permet de :<\/p>\n\n
\n- Ex\u00e9cuter les pipelines de fork dans un mode restreint, sans acc\u00e8s aux variables CI du projet.<\/li>\n
- Exiger une approbation manuelle avant d’ex\u00e9cuter des pipelines provenant de forks (disponible dans Premium\/Ultimate).<\/li>\n
- Utiliser des runners s\u00e9par\u00e9s et non privil\u00e9gi\u00e9s pour les pipelines de fork.<\/li>\n<\/ul>\n\n
D\u00e9tection de secrets avec les templates SAST int\u00e9gr\u00e9s<\/h2>\n\n
GitLab est livr\u00e9 avec des templates SAST (Static Application Security Testing) int\u00e9gr\u00e9s qui incluent la d\u00e9tection de secrets. Les activer est simple :<\/p>\n\n
include:\n - template: Jobs\/Secret-Detection.gitlab-ci.yml\n - template: Jobs\/SAST.gitlab-ci.yml\n<\/code><\/pre>\n\nLe scanner de d\u00e9tection de secrets utilise la correspondance de motifs et l’analyse d’entropie pour identifier les identifiants divulgu\u00e9s, les cl\u00e9s API, les cl\u00e9s priv\u00e9es et les tokens dans votre base de code. Les r\u00e9sultats apparaissent dans le widget de s\u00e9curit\u00e9 de la merge request, ce qui permet aux r\u00e9viseurs de rep\u00e9rer facilement les fuites avant qu’elles n’atteignent la branche par d\u00e9faut.<\/p>\n\n
Maximiser l’efficacit\u00e9 de la d\u00e9tection de secrets :<\/strong><\/p>\n\n\n- Activez la d\u00e9tection de secrets au niveau du pipeline<\/strong> (pas seulement l’analyse historique) afin que chaque commit soit v\u00e9rifi\u00e9.<\/li>\n
- Configurez des push rules<\/strong> pour rejeter les commits contenant des motifs de secrets connus (par exemple,
AKIA<\/code> pour les cl\u00e9s d’acc\u00e8s AWS).<\/li>\n- Int\u00e9grez avec la gestion des vuln\u00e9rabilit\u00e9s de GitLab<\/strong> pour suivre, trier et r\u00e9soudre les secrets d\u00e9tect\u00e9s.<\/li>\n
- Ajoutez des motifs personnalis\u00e9s pour les formats de secrets propres \u00e0 votre organisation (cl\u00e9s API internes, tokens de comptes de service).<\/li>\n
- Ex\u00e9cutez la d\u00e9tection de secrets \u00e0 la fois sur la branche source et sur le r\u00e9sultat de la fusion pour d\u00e9tecter les secrets introduits par des conflits de fusion.<\/li>\n<\/ul>\n\n
Workflows de d\u00e9ploiement s\u00e9curis\u00e9s<\/h2>\n\n
Amener du code d’un pipeline vers un environnement de production en toute s\u00e9curit\u00e9 demande plus que simplement ex\u00e9cuter kubectl apply<\/code>. GitLab prend en charge plusieurs strat\u00e9gies de d\u00e9ploiement qui \u00e9quilibrent rapidit\u00e9 et s\u00fbret\u00e9.<\/p>\n\nPortes manuelles<\/h3>\n\n
Utilisez le mot-cl\u00e9 when: manual<\/code> pour cr\u00e9er des points d’approbation explicites dans votre pipeline. Un sch\u00e9ma courant consiste \u00e0 d\u00e9ployer automatiquement en staging mais \u00e0 exiger un clic manuel pour la production. Combin\u00e9 aux environnements prot\u00e9g\u00e9s et aux approbations de d\u00e9ploiement, cela cr\u00e9e un workflow de gestion des changements robuste.<\/p>\n\ndeploy_production:\n stage: deploy\n environment:\n name: production\n deployment_tier: production\n when: manual\n only:\n - main\n<\/code><\/pre>\n\nD\u00e9ploiements canary<\/h3>\n\n
GitLab s’int\u00e8gre \u00e0 Kubernetes pour prendre en charge nativement les d\u00e9ploiements canary. En d\u00e9ployant d’abord sur un petit pourcentage de pods et en surveillant les taux d’erreur, vous pouvez d\u00e9tecter les probl\u00e8mes avant qu’ils n’affectent tous les utilisateurs. C’est un contr\u00f4le de s\u00e9curit\u00e9 autant que de fiabilit\u00e9 \u2014 un build compromis qui atteint le canary peut \u00eatre d\u00e9tect\u00e9 et annul\u00e9 avant de se propager largement.<\/p>\n\n
GitOps avec le GitLab Agent for Kubernetes<\/h3>\n\n
Le GitLab Agent for Kubernetes (anciennement appel\u00e9 KAS) permet un mod\u00e8le GitOps de type pull. Au lieu d’accorder \u00e0 votre pipeline CI un acc\u00e8s direct \u00e0 l’API Kubernetes, l’agent qui s’ex\u00e9cute dans le cluster r\u00e9cup\u00e8re l’\u00e9tat d\u00e9sir\u00e9 depuis un d\u00e9p\u00f4t Git. Cela \u00e9limine le besoin d’identifiants kubeconfig \u00e0 longue dur\u00e9e de vie dans les variables CI et r\u00e9duit consid\u00e9rablement la surface d’attaque.<\/p>\n\n
Bonnes pratiques de s\u00e9curit\u00e9 des d\u00e9ploiements :<\/strong><\/p>\n\n\n- Ne stockez jamais un kubeconfig ou des identifiants cloud dans des variables CI non prot\u00e9g\u00e9es. Utilisez la f\u00e9d\u00e9ration OIDC ou le GitLab Agent.<\/li>\n
- Mettez en place une automatisation du rollback \u2014 si les health checks \u00e9chouent apr\u00e8s le d\u00e9ploiement, revenez automatiquement au dernier \u00e9tat sain connu.<\/li>\n
- Signez les images de conteneurs et v\u00e9rifiez les signatures avant le d\u00e9ploiement avec Cosign ou Notary.<\/li>\n
- Utilisez des tags immuables ou des r\u00e9f\u00e9rences par digest pour les images de conteneurs afin de pr\u00e9venir les attaques bas\u00e9es sur les tags.<\/li>\n<\/ul>\n\n
Erreurs de configuration courantes<\/h2>\n\n
M\u00eame les \u00e9quipes qui comprennent les concepts de s\u00e9curit\u00e9 de GitLab CI tombent souvent dans ces pi\u00e8ges :<\/p>\n\n
1. Variables non prot\u00e9g\u00e9es contenant des secrets de production<\/h3>\n\n
C’est l’erreur de configuration la plus courante et la plus dangereuse. Si un mot de passe de base de donn\u00e9es de production est stock\u00e9 dans une variable non prot\u00e9g\u00e9e, n’importe quel d\u00e9veloppeur peut cr\u00e9er une branche, ajouter une \u00e9tape echo $DB_PASSWORD<\/code> et le lire depuis le log du job. Prot\u00e9gez et masquez toujours les secrets de production.<\/p>\n\n2. Runners partag\u00e9s trop permissifs<\/h3>\n\n
Les runners partag\u00e9s avec montage du socket Docker (\/var\/run\/docker.sock<\/code>) ou en mode --privileged<\/code> donnent aux jobs le contr\u00f4le total de l’h\u00f4te. Un job malveillant peut s’\u00e9chapper du conteneur, acc\u00e9der aux donn\u00e9es d’autres jobs ou compromettre le runner lui-m\u00eame.<\/p>\n\n3. P\u00e9rim\u00e8tre du CI_JOB_TOKEN non restreint<\/h3>\n\n
Sans p\u00e9rim\u00e8tre de token explicite, un job compromis dans un projet \u00e0 faible valeur peut utiliser son CI_JOB_TOKEN<\/code> pour acc\u00e9der aux API et aux registres de projets \u00e0 forte valeur. Activez les restrictions de p\u00e9rim\u00e8tre de token sur chaque projet.<\/p>\n\n4. Absence de validation de pipeline sur les merge requests<\/h3>\n\n
Si la r\u00e9ussite des pipelines n’est pas exig\u00e9e avant la fusion, les attaquants peuvent pousser du code qui contourne les analyses de s\u00e9curit\u00e9. Activez le param\u00e8tre \u00ab Pipelines must succeed \u00bb.<\/p>\n\n
5. Secrets cod\u00e9s en dur dans .gitlab-ci.yml<\/h3>\n\n
Cela para\u00eet \u00e9vident, mais des identifiants apparaissent encore dans les fichiers YAML de pipeline avec une fr\u00e9quence alarmante. Utilisez des variables CI, des gestionnaires de secrets externes ou OIDC \u2014 n’ins\u00e9rez jamais un secret en clair.<\/p>\n\n
6. Aucune journalisation d’audit ni surveillance<\/h3>\n\n
GitLab g\u00e9n\u00e8re des \u00e9v\u00e9nements d’audit pour les modifications de configuration CI\/CD, mais de nombreuses organisations n’envoient pas ces logs vers un SIEM et ne configurent pas d’alertes. Sans surveillance, des compromissions peuvent passer inaper\u00e7ues pendant des semaines.<\/p>\n\n
7. Enregistrements de runners obsol\u00e8tes<\/h3>\n\n
Des runners enregistr\u00e9s il y a des mois puis oubli\u00e9s peuvent avoir des configurations obsol\u00e8tes, des syst\u00e8mes d’exploitation non corrig\u00e9s ou un acc\u00e8s aux projets trop large. Auditez et nettoyez r\u00e9guli\u00e8rement les runners obsol\u00e8tes.<\/p>\n\n
Checklist de mise en \u0153uvre<\/h2>\n\n
Utilisez cette checklist pour durcir syst\u00e9matiquement votre environnement GitLab CI\/CD. Priorisez les \u00e9l\u00e9ments en fonction de votre mod\u00e8le de menace et de vos exigences de conformit\u00e9.<\/p>\n\n
Variables et secrets<\/h3>\n\n\n- \u2610 Tous les secrets de production sont marqu\u00e9s comme prot\u00e9g\u00e9s et masqu\u00e9s.<\/li>\n
- \u2610 Des variables \u00e0 port\u00e9e d’environnement sont utilis\u00e9es pour s\u00e9parer les identifiants de staging et de production.<\/li>\n
- \u2610 Aucun secret n’est cod\u00e9 en dur dans
.gitlab-ci.yml<\/code> ou dans les fichiers du d\u00e9p\u00f4t.<\/li>\n- \u2610 Le calendrier de rotation des secrets est document\u00e9 et appliqu\u00e9.<\/li>\n
- \u2610 Un gestionnaire de secrets externe (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) est int\u00e9gr\u00e9 pour les identifiants les plus sensibles.<\/li>\n<\/ul>\n\n
Runners<\/h3>\n\n\n- \u2610 Les runners de d\u00e9ploiement en production sont \u00e0 port\u00e9e de projet et prot\u00e9g\u00e9s.<\/li>\n
- \u2610 Les runners partag\u00e9s utilisent des ex\u00e9cuteurs \u00e9ph\u00e9m\u00e8res et conteneuris\u00e9s.<\/li>\n
- \u2610 Le mode privil\u00e9gi\u00e9 est d\u00e9sactiv\u00e9 ou restreint \u00e0 des groupes de runners d\u00e9di\u00e9s.<\/li>\n
- \u2610 Les tokens d’enregistrement des runners sont renouvel\u00e9s r\u00e9guli\u00e8rement.<\/li>\n
- \u2610 Les enregistrements de runners obsol\u00e8tes sont audit\u00e9s et supprim\u00e9s chaque trimestre.<\/li>\n<\/ul>\n\n
Environnements et d\u00e9ploiements<\/h3>\n\n\n- \u2610 Les environnements de production et de staging sont prot\u00e9g\u00e9s.<\/li>\n
- \u2610 Les approbations de d\u00e9ploiement sont activ\u00e9es pour la production (Premium\/Ultimate).<\/li>\n
- \u2610 Des portes manuelles sont configur\u00e9es pour les d\u00e9ploiements en production.<\/li>\n
- \u2610 Les proc\u00e9dures de rollback sont document\u00e9es et test\u00e9es.<\/li>\n
- \u2610 Les images de conteneurs sont sign\u00e9es et v\u00e9rifi\u00e9es avant le d\u00e9ploiement.<\/li>\n<\/ul>\n\n
Tokens et authentification<\/h3>\n\n\n- \u2610
CI_JOB_TOKEN<\/code> a un p\u00e9rim\u00e8tre restreint sur chaque projet.<\/li>\n- \u2610 OIDC
id_tokens<\/code> sont utilis\u00e9s \u00e0 la place des identifiants cloud statiques.<\/li>\n- \u2610 Les politiques de confiance IAM du cloud valident le chemin du projet, la r\u00e9f\u00e9rence et les claims d’environnement.<\/li>\n
- \u2610 Les personal access tokens ayant la port\u00e9e CI\/CD sont r\u00e9duits au minimum et audit\u00e9s.<\/li>\n<\/ul>\n\n
Param\u00e8tres des pipelines et des merge requests<\/h3>\n\n\n- \u2610 \u00ab Pipelines must succeed \u00bb est activ\u00e9 pour toutes les branches prot\u00e9g\u00e9es.<\/li>\n
- \u2610 Les templates de d\u00e9tection de secrets et SAST sont inclus dans le pipeline par d\u00e9faut.<\/li>\n
- \u2610 Les push rules rejettent les commits contenant des motifs de secrets connus.<\/li>\n
- \u2610
.gitlab-ci.yml<\/code> \u2014 toute modification n\u00e9cessite l’approbation de r\u00e9viseurs s\u00e9curit\u00e9.<\/li>\n- \u2610 Les pipelines de fork sont mis en bac \u00e0 sable ou n\u00e9cessitent une approbation manuelle.<\/li>\n<\/ul>\n\n
Surveillance et conformit\u00e9<\/h3>\n\n\n- \u2610 Les \u00e9v\u00e9nements d’audit des modifications de configuration CI\/CD sont envoy\u00e9s vers un SIEM.<\/li>\n
- \u2610 Des alertes sont configur\u00e9es pour les activit\u00e9s suspectes (par exemple, nouveaux enregistrements de runners, modifications de variables, d\u00e9ploiements inattendus).<\/li>\n
- \u2610 Les pipelines de conformit\u00e9 (Ultimate) imposent des jobs de s\u00e9curit\u00e9 obligatoires dans tous les projets.<\/li>\n
- \u2610 Des revues d’acc\u00e8s r\u00e9guli\u00e8res couvrent les permissions des runners, l’acc\u00e8s aux variables et les d\u00e9ploiements d’environnements.<\/li>\n<\/ul>\n\n
Pour une version imprimable et synth\u00e9tique de ces recommandations, consultez notre cheat sheet de s\u00e9curit\u00e9 GitLab CI<\/a>.<\/p>\n\nLab pratique<\/h2>\n\n
Lire des articles sur la s\u00e9curit\u00e9 est important, mais c’est la pratique qui ancre les connaissances. Notre lab interactif vous guide pas \u00e0 pas dans la s\u00e9curisation d’un vrai pipeline GitLab CI \u2014 configuration des variables prot\u00e9g\u00e9es, p\u00e9rim\u00e8tre des runners, mise en place des approbations d’environnement, et plus encore.<\/p>\n\n
\ud83d\udc49 Lab : s\u00e9curiser les pipelines GitLab CI \u2014 variables prot\u00e9g\u00e9es, runners et environnements<\/a><\/p>\n\nOutils et ressources<\/h2>\n\n
Les outils et ressources suivants peuvent vous aider \u00e0 \u00e9valuer et \u00e0 am\u00e9liorer la posture de s\u00e9curit\u00e9 de votre GitLab CI\/CD :<\/p>\n\n
Fonctionnalit\u00e9s de s\u00e9curit\u00e9 natives de GitLab<\/h3>\n\n\n- Security Dashboard<\/strong> \u2014 vue centralis\u00e9e des vuln\u00e9rabilit\u00e9s de tous les projets d’un groupe ou d’une instance.<\/li>\n
- Compliance Pipelines (Ultimate)<\/strong> \u2014 imposent des jobs CI obligatoires (comme la d\u00e9tection de secrets) que les mainteneurs de projet ne peuvent ni ignorer ni modifier.<\/li>\n
- Audit Events API<\/strong> \u2014 acc\u00e8s programmatique aux logs de modifications de configuration CI\/CD pour l’int\u00e9gration avec des plateformes SIEM externes.<\/li>\n
- Dependency Scanning<\/strong> \u2014 identifie les vuln\u00e9rabilit\u00e9s connues dans les d\u00e9pendances du projet. \u00c0 combiner avec la d\u00e9tection de secrets pour une couverture compl\u00e8te de la cha\u00eene d’approvisionnement.<\/li>\n
- Container Scanning<\/strong> \u2014 analyse les images Docker \u00e0 la recherche de vuln\u00e9rabilit\u00e9s au niveau du syst\u00e8me d’exploitation et du langage avant qu’elles n’atteignent un registre.<\/li>\n<\/ul>\n\n
Outils tiers et open source<\/h3>\n\n\n- Cimon<\/a><\/strong> \u2014 agent de s\u00e9curit\u00e9 runtime pour la CI\/CD qui surveille et restreint les acc\u00e8s r\u00e9seau et fichiers pendant l’ex\u00e9cution du pipeline.<\/li>\n
- StepSecurity Harden-Runner<\/a><\/strong> \u2014 con\u00e7u \u00e0 l’origine pour GitHub Actions, mais les concepts (filtrage des sorties r\u00e9seau, surveillance des processus) s’appliquent aussi aux runners GitLab.<\/li>\n
- HashiCorp Vault<\/a><\/strong> \u2014 gestionnaire de secrets standard du secteur, avec une int\u00e9gration GitLab native via le mot-cl\u00e9
vault<\/code> dans .gitlab-ci.yml<\/code>.<\/li>\n- Cosign<\/a><\/strong> \u2014 signature et v\u00e9rification d’images de conteneurs. Int\u00e9grez-le \u00e0 votre pipeline pour signer les images apr\u00e8s le build et les v\u00e9rifier avant le d\u00e9ploiement.<\/li>\n
- Trivy<\/a><\/strong> \u2014 scanner de vuln\u00e9rabilit\u00e9s complet pour les conteneurs, les syst\u00e8mes de fichiers et les d\u00e9p\u00f4ts Git. L\u00e9ger et facile \u00e0 int\u00e9grer dans GitLab CI.<\/li>\n<\/ul>\n\n
Documentation et r\u00e9f\u00e9rences<\/h3>\n\n\n- Documentation sur la s\u00e9curit\u00e9 des pipelines GitLab CI\/CD<\/a><\/li>\n
- Documentation de GitLab Runner<\/a><\/li>\n
- OIDC GitLab pour les services cloud<\/a><\/li>\n
- OWASP Top 10 des risques de s\u00e9curit\u00e9 CI\/CD<\/a><\/li>\n<\/ul>\n\n
Conclusion<\/h2>\n\n
GitLab CI\/CD est une plateforme DevSecOps puissante et int\u00e9gr\u00e9e \u2014 mais sa s\u00e9curit\u00e9 ne vaut que ce que vaut votre configuration. Les contr\u00f4les existent : variables prot\u00e9g\u00e9es, p\u00e9rim\u00e8tre des runners, approbations d’environnement, f\u00e9d\u00e9ration OIDC, restrictions du CI_JOB_TOKEN, d\u00e9tection de secrets et portes de d\u00e9ploiement. Le d\u00e9fi est de les activer de mani\u00e8re coh\u00e9rente et de les surveiller en continu.<\/p>\n\n
Commencez par les \u00e9l\u00e9ments \u00e0 plus fort impact : prot\u00e9gez et masquez tous les secrets de production, d\u00e9finissez le p\u00e9rim\u00e8tre de vos runners, restreignez l’acc\u00e8s du CI_JOB_TOKEN et activez la d\u00e9tection de secrets dans chaque pipeline. Ajoutez ensuite OIDC pour l’authentification cloud, les approbations de d\u00e9ploiement pour les environnements de production et les pipelines de conformit\u00e9 pour une application \u00e0 l’\u00e9chelle de l’organisation.<\/p>\n\n
La s\u00e9curit\u00e9 n’est pas une configuration ponctuelle \u2014 c’est une discipline continue. Passez en revue la posture de s\u00e9curit\u00e9 de vos pipelines chaque trimestre, auditez les contr\u00f4les d’acc\u00e8s, renouvelez les identifiants et restez \u00e0 jour avec les fonctionnalit\u00e9s de s\u00e9curit\u00e9 en constante \u00e9volution de GitLab. Avec les pratiques de ce guide, vous obtiendrez un environnement GitLab CI\/CD non seulement rapide et productif, mais v\u00e9ritablement s\u00e9curis\u00e9.<\/p>\n\n
Pr\u00eat \u00e0 mettre ces concepts en pratique ? Commencez par notre cheat sheet de s\u00e9curit\u00e9 GitLab CI<\/a> pour une r\u00e9f\u00e9rence rapide, puis parcourez le lab pratique<\/a> pour acqu\u00e9rir des automatismes. Et pour le contexte plus large de la gestion des identifiants sur toutes les plateformes CI\/CD, explorez notre guide sur les identifiants de courte dur\u00e9e et la f\u00e9d\u00e9ration d’identit\u00e9 de charge de travail<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"GitLab CI\/CD est devenu la colonne vert\u00e9brale du DevSecOps moderne : il offre une plateforme int\u00e9gr\u00e9e o\u00f9 le code, les pipelines, l’analyse de s\u00e9curit\u00e9 et les d\u00e9ploiements convergent dans une seule interface. Mais cette int\u00e9gration profonde est une arme \u00e0 double tranchant : un pipeline mal configur\u00e9 peut exposer des secrets, autoriser des d\u00e9ploiements non … Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":1188,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,53],"tags":[],"post_folder":[],"class_list":["post-443","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd-security","category-gitlab-ci"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/443","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=443"}],"version-history":[{"count":4,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/443\/revisions"}],"predecessor-version":[{"id":1189,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/443\/revisions\/1189"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media\/1188"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=443"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}