{"id":452,"date":"2026-01-23T23:09:03","date_gmt":"2026-01-23T22:09:03","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=452"},"modified":"2026-03-25T08:38:11","modified_gmt":"2026-03-25T07:38:11","slug":"gitlab-ci-security-cheat-sheet","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/gitlab-ci-security-cheat-sheet\/","title":{"rendered":"Cheat Sheet S\u00e9curit\u00e9 GitLab CI : Variables, Runners, Environnements et OIDC"},"content":{"rendered":"<h2>Pourquoi la s\u00e9curit\u00e9 de GitLab CI est essentielle<\/h2>\n<p>Les pipelines GitLab CI\/CD sont puissants \u2014 mais qui dit puissance dit risque. Une variable mal configur\u00e9e peut exposer des secrets. Un runner non restreint peut ex\u00e9cuter du code malveillant. Un environnement non prot\u00e9g\u00e9 peut permettre \u00e0 un d\u00e9veloppeur junior de d\u00e9ployer directement en production. Ce cheat sheet vous fournit du <strong>YAML pr\u00eat \u00e0 copier-coller<\/strong> pour chaque contr\u00f4le de s\u00e9curit\u00e9 critique de GitLab CI, des variables prot\u00e9g\u00e9es \u00e0 la f\u00e9d\u00e9ration OIDC.<\/p>\n<p>Ajoutez cette page \u00e0 vos favoris. Utilisez-la comme r\u00e9f\u00e9rence \u00e0 chaque fois que vous configurez un nouveau projet ou auditez un projet existant.<\/p>\n<h2>1. Variables prot\u00e9g\u00e9es, masqu\u00e9es et cach\u00e9es<\/h2>\n<p>Les variables CI\/CD de GitLab contr\u00f4lent la mani\u00e8re dont les secrets circulent dans vos pipelines. Une mauvaise configuration est la cause num\u00e9ro un des fuites de credentials en CI\/CD. Chaque valeur sensible devrait \u00eatre <strong>prot\u00e9g\u00e9e<\/strong> (disponible uniquement sur les branches\/tags prot\u00e9g\u00e9s), <strong>masqu\u00e9e<\/strong> (cach\u00e9e des logs de jobs) et, lorsque c&#8217;est possible, <strong>cach\u00e9e<\/strong> (invisible dans l&#8217;interface utilisateur apr\u00e8s cr\u00e9ation).<\/p>\n<h3>D\u00e9finir des variables via l&#8217;API<\/h3>\n<pre><code># Cr\u00e9er une variable prot\u00e9g\u00e9e + masqu\u00e9e via l'API GitLab\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/variables\" \\\n  --form \"key=AWS_SECRET_ACCESS_KEY\" \\\n  --form \"value=$MY_SECRET\" \\\n  --form \"protected=true\" \\\n  --form \"masked=true\" \\\n  --form \"variable_type=env_var\"<\/code><\/pre>\n<h3>Utiliser les variables dans <code>.gitlab-ci.yml<\/code><\/h3>\n<pre><code>variables:\n  # Les variables de groupe ou de projet sont inject\u00e9es automatiquement.\n  # Les variables de type fichier sont \u00e9crites dans un chemin temporaire.\n  DEPLOY_TOKEN:\n    description: \"Token pour le d\u00e9ploiement en production\"\n    value: \"\"  # Intentionnellement vide \u2014 \u00e0 d\u00e9finir dans CI\/CD Settings\n\ndeploy_production:\n  stage: deploy\n  script:\n    - echo \"D\u00e9ploiement avec un token masqu\u00e9...\"\n    - .\/deploy.sh --token \"$DEPLOY_TOKEN\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>R\u00e8gles cl\u00e9s :<\/strong><\/p>\n<ul>\n<li>Ne codez jamais les secrets en dur dans <code>.gitlab-ci.yml<\/code> \u2014 utilisez toujours les param\u00e8tres de variables CI\/CD.<\/li>\n<li>D\u00e9finissez <code>protected=true<\/code> pour que les secrets ne soient disponibles que sur les branches prot\u00e9g\u00e9es.<\/li>\n<li>D\u00e9finissez <code>masked=true<\/code> pour que les valeurs soient masqu\u00e9es dans les logs de jobs.<\/li>\n<li>Utilisez des <strong>variables de groupe<\/strong> pour les secrets partag\u00e9s entre projets (par ex., credentials cloud).<\/li>\n<\/ul>\n<h2>2. Types de runners et restriction de port\u00e9e<\/h2>\n<p>Les runners ex\u00e9cutent vos jobs CI\/CD. Si n&#8217;importe quel runner peut r\u00e9cup\u00e9rer n&#8217;importe quel job, une merge request malveillante pourrait exfiltrer des secrets depuis un runner de production. Une restriction de port\u00e9e ad\u00e9quate est essentielle.<\/p>\n<h3>Enregistrement d&#8217;un runner avec des tags et une protection<\/h3>\n<pre><code># Enregistrer un runner limit\u00e9 aux branches prot\u00e9g\u00e9es uniquement\ngitlab-runner register \\\n  --non-interactive \\\n  --url \"https:\/\/gitlab.example.com\" \\\n  --token \"$RUNNER_REG_TOKEN\" \\\n  --executor docker \\\n  --docker-image alpine:latest \\\n  --tag-list \"production,protected\" \\\n  --access-level ref_protected<\/code><\/pre>\n<h3>Restreindre les jobs \u00e0 des runners sp\u00e9cifiques<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 s'assurer que les jobs de production ne s'ex\u00e9cutent que sur des runners prot\u00e9g\u00e9s\ndeploy_production:\n  stage: deploy\n  tags:\n    - production\n    - protected\n  script:\n    - kubectl apply -f k8s\/production\/\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production\n\n# Les jobs de d\u00e9veloppement utilisent un runner s\u00e9par\u00e9 et non privil\u00e9gi\u00e9\ntest:\n  stage: test\n  tags:\n    - shared\n    - development\n  script:\n    - pytest tests\/<\/code><\/pre>\n<p><strong>Bonnes pratiques :<\/strong><\/p>\n<ul>\n<li>Utilisez <code>--access-level ref_protected<\/code> pour restreindre les runners aux branches et tags prot\u00e9g\u00e9s.<\/li>\n<li>Utilisez des <strong>runners sp\u00e9cifiques au projet<\/strong> pour les charges de travail sensibles \u2014 ne partagez jamais les runners de production entre des projets sans lien.<\/li>\n<li>Pr\u00e9f\u00e9rez les <strong>runners \u00e9ph\u00e9m\u00e8res<\/strong> (ex\u00e9cuteurs Docker, Kubernetes) afin que l&#8217;environnement soit d\u00e9truit apr\u00e8s chaque job.<\/li>\n<li>D\u00e9sactivez les shared runners sur les projets qui g\u00e8rent des d\u00e9ploiements sensibles.<\/li>\n<\/ul>\n<h2>3. Environnements prot\u00e9g\u00e9s avec approbations<\/h2>\n<p>Les environnements prot\u00e9g\u00e9s ajoutent une validation humaine avant les d\u00e9ploiements. C&#8217;est votre derni\u00e8re ligne de d\u00e9fense contre les modifications non autoris\u00e9es en production.<\/p>\n<h3>Configuration des environnements dans <code>.gitlab-ci.yml<\/code><\/h3>\n<pre><code># .gitlab-ci.yml \u2014 d\u00e9ploiement avec protection de l'environnement\ndeploy_staging:\n  stage: deploy\n  script:\n    - .\/deploy.sh staging\n  environment:\n    name: staging\n    url: https:\/\/staging.example.com\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy_production:\n  stage: deploy\n  script:\n    - .\/deploy.sh production\n  environment:\n    name: production\n    url: https:\/\/example.com\n    deployment_tier: production\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n      allow_failure: false<\/code><\/pre>\n<h3>Configurer les r\u00e8gles d&#8217;approbation via l&#8217;API<\/h3>\n<pre><code># Prot\u00e9ger l'environnement de production avec des approbations obligatoires\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/protected_environments\" \\\n  --data '{\"name\": \"production\", \"deploy_access_levels\": [{\"group_id\": 9899826}], \"required_approval_count\": 2, \"approval_rules\": [{\"group_id\": 9899826, \"required_approvals\": 2}]}'<\/code><\/pre>\n<p>Configurez cela dans <strong>Settings &gt; CI\/CD &gt; Protected Environments<\/strong> dans l&#8217;interface GitLab. Exigez au minimum <strong>deux approbations<\/strong> pour les d\u00e9ploiements en production. Restreignez l&#8217;acc\u00e8s au d\u00e9ploiement \u00e0 des groupes ou utilisateurs sp\u00e9cifiques \u2014 jamais &#171; All maintainers &#187;.<\/p>\n<h2>4. Restriction de port\u00e9e du CI_JOB_TOKEN<\/h2>\n<p><code>CI_JOB_TOKEN<\/code> est un token automatique que GitLab injecte dans chaque job. Par d\u00e9faut, il peut acc\u00e9der \u00e0 d&#8217;autres projets de votre groupe \u2014 un risque s\u00e9rieux de mouvement lat\u00e9ral. Depuis GitLab 16.0, vous devez restreindre sa port\u00e9e.<\/p>\n<h3>Restreindre l&#8217;acc\u00e8s du token<\/h3>\n<pre><code># V\u00e9rifier la port\u00e9e d'acc\u00e8s actuelle du CI_JOB_TOKEN\ncurl --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\"\n\n# Limiter le CI_JOB_TOKEN \u00e0 l'acc\u00e8s \u00e0 des projets sp\u00e9cifiques uniquement\ncurl --request PATCH \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\" \\\n  --data '{\"enabled\": true}'\n\n# Ajouter un projet \u00e0 la liste d'autorisation\ncurl --request POST \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/job_token_scope\/allowlist\" \\\n  --data '{\"target_project_id\": 12345}'<\/code><\/pre>\n<h3>Utiliser <code>CI_JOB_TOKEN<\/code> de mani\u00e8re s\u00e9curis\u00e9e dans les pipelines<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 utiliser CI_JOB_TOKEN pour des d\u00e9clenchements cross-project\ntrigger_deploy:\n  stage: deploy\n  trigger:\n    project: my-group\/deploy-project\n    branch: main\n    strategy: depend\n  # CI_JOB_TOKEN est utilis\u00e9 automatiquement pour le d\u00e9clenchement.\n  # Le projet cible doit autoriser le token de ce projet.<\/code><\/pre>\n<p><strong>R\u00e8gles cl\u00e9s :<\/strong> Activez la limitation de port\u00e9e du CI\/CD job token sur chaque projet. N&#8217;autorisez que les projets sp\u00e9cifiques qui ont v\u00e9ritablement besoin d&#8217;un acc\u00e8s cross-project. Auditez les listes d&#8217;autorisation chaque trimestre.<\/p>\n<h2>5. <code>id_tokens<\/code> OIDC pour AWS et GCP<\/h2>\n<p>La f\u00e9d\u00e9ration OIDC \u00e9limine totalement les credentials cloud \u00e0 longue dur\u00e9e de vie de vos variables CI\/CD. GitLab \u00e9met un JWT \u00e0 courte dur\u00e9e de vie, et votre fournisseur cloud l&#8217;\u00e9change contre des credentials temporaires. C&#8217;est le standard de r\u00e9f\u00e9rence pour l&#8217;authentification cloud dans les pipelines.<\/p>\n<h3>F\u00e9d\u00e9ration OIDC avec AWS<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 authentification OIDC avec AWS\ndeploy_aws:\n  stage: deploy\n  image: amazon\/aws-cli:latest\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https:\/\/gitlab.example.com\n  variables:\n    ROLE_ARN: arn:aws:iam::123456789012:role\/gitlab-ci-deploy\n  script:\n    - &gt;\n      export $(printf \"AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s\"\n      $(aws sts assume-role-with-web-identity\n      --role-arn $ROLE_ARN\n      --role-session-name \"GitLabCI-${CI_PROJECT_ID}-${CI_PIPELINE_ID}\"\n      --web-identity-token \"$GITLAB_OIDC_TOKEN\"\n      --duration-seconds 3600\n      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'\n      --output text))\n    - aws s3 sync .\/build s3:\/\/my-production-bucket\/\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<h3>F\u00e9d\u00e9ration d&#8217;identit\u00e9 de charge de travail GCP<\/h3>\n<pre><code># .gitlab-ci.yml \u2014 authentification OIDC avec GCP\ndeploy_gcp:\n  stage: deploy\n  image: google\/cloud-sdk:latest\n  id_tokens:\n    GITLAB_OIDC_TOKEN:\n      aud: https:\/\/gitlab.example.com\n  script:\n    - echo \"$GITLAB_OIDC_TOKEN\" &gt; \/tmp\/gitlab_token.txt\n    - &gt;\n      gcloud iam workload-identity-pools create-cred-config\n      projects\/$GCP_PROJECT_NUMBER\/locations\/global\/workloadIdentityPools\/$POOL_ID\/providers\/$PROVIDER_ID\n      --service-account=\"$GCP_SERVICE_ACCOUNT\"\n      --output-file=\/tmp\/gcp_creds.json\n      --credential-source-file=\/tmp\/gitlab_token.txt\n    - export GOOGLE_APPLICATION_CREDENTIALS=\/tmp\/gcp_creds.json\n    - gcloud config set project $GCP_PROJECT_ID\n    - gcloud run deploy my-service --image gcr.io\/$GCP_PROJECT_ID\/my-app:$CI_COMMIT_SHA\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p>C\u00f4t\u00e9 cloud, configurez la politique de confiance pour valider des claims comme <code>project_path<\/code>, <code>ref<\/code> et <code>ref_protected<\/code> afin que seuls des projets et des branches sp\u00e9cifiques puissent assumer le r\u00f4le.<\/p>\n<h2>6. S\u00e9curit\u00e9 des pipelines de merge request<\/h2>\n<p>Les pipelines de merge request s&#8217;ex\u00e9cutent sur du code qui n&#8217;a pas encore \u00e9t\u00e9 valid\u00e9 par une revue. Traitez-les comme non fiables. N&#8217;exposez jamais les secrets de production aux pipelines de MR.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 r\u00e8gles distinctes pour les pipelines de MR vs. de branche\ntest:\n  stage: test\n  script:\n    - pytest tests\/\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ndeploy_production:\n  stage: deploy\n  script:\n    - .\/deploy.sh production\n  rules:\n    # Ne JAMAIS ex\u00e9cuter sur les pipelines de merge request\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n      when: never\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>Contr\u00f4les critiques :<\/strong><\/p>\n<ul>\n<li>Utilisez <code>rules:<\/code> pour garantir que les jobs de d\u00e9ploiement ne s&#8217;ex\u00e9cutent <strong>jamais<\/strong> sur les pipelines <code>merge_request_event<\/code>.<\/li>\n<li>Exigez la <strong>r\u00e9ussite du pipeline<\/strong> avant la fusion (Settings &gt; Merge Requests).<\/li>\n<li>Activez <strong>&#171; Pipelines must succeed &#187;<\/strong> et <strong>&#171; All discussions must be resolved &#187;<\/strong>.<\/li>\n<li>Envisagez d&#8217;activer les <strong>merged results pipelines<\/strong> pour tester l&#8217;\u00e9tat post-fusion.<\/li>\n<\/ul>\n<h2>7. Template de d\u00e9tection de secrets<\/h2>\n<p>Le scanner de d\u00e9tection de secrets int\u00e9gr\u00e9 \u00e0 GitLab intercepte les credentials accidentellement commit\u00e9s avant qu&#8217;ils n&#8217;atteignent la branche par d\u00e9faut.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 inclure le template de d\u00e9tection de secrets\ninclude:\n  - template: Jobs\/Secret-Detection.gitlab-ci.yml\n\n# Surcharger pour faire \u00e9chouer le pipeline si des secrets sont d\u00e9tect\u00e9s\nsecret_detection:\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"  # Scanner l'historique complet de git\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n  allow_failure: false  # Bloquer le pipeline en cas de d\u00e9tection<\/code><\/pre>\n<p>Pour une analyse plus compl\u00e8te, ajoutez \u00e9galement les templates <strong>SAST<\/strong> et <strong>dependency scanning<\/strong> :<\/p>\n<pre><code>include:\n  - template: Jobs\/Secret-Detection.gitlab-ci.yml\n  - template: Jobs\/SAST.gitlab-ci.yml\n  - template: Jobs\/Dependency-Scanning.gitlab-ci.yml<\/code><\/pre>\n<p>Consultez les r\u00e9sultats dans le <strong>Security Dashboard<\/strong> (disponible sur GitLab Ultimate) ou parsez les artefacts JSON dans les tiers inf\u00e9rieurs.<\/p>\n<h2>8. Push Rules<\/h2>\n<p>Les push rules appliquent des politiques au niveau Git \u2014 avant m\u00eame que le code n&#8217;entre dans un pipeline. Utilisez-les pour emp\u00eacher l&#8217;envoi de secrets, imposer des standards de messages de commit et restreindre les types de fichiers.<\/p>\n<pre><code># D\u00e9finir les push rules via l'API\ncurl --request PUT \\\n  --header \"PRIVATE-TOKEN: $GITLAB_TOKEN\" \\\n  \"https:\/\/gitlab.example.com\/api\/v4\/projects\/$PROJECT_ID\/push_rule\" \\\n  --data '{\"deny_delete_tag\": true, \"prevent_secrets\": true, \"commit_message_regex\": \"^(feat|fix|chore|docs|refactor|test|ci)\\\\(.*\\\\):.*\", \"max_file_size\": 50, \"member_check\": true, \"reject_unsigned_commits\": true}'<\/code><\/pre>\n<p><strong>Push rules recommand\u00e9es :<\/strong><\/p>\n<ul>\n<li><code>prevent_secrets: true<\/code> \u2014 Rejette les pushs contenant des fichiers qui ressemblent \u00e0 des secrets (cl\u00e9s, tokens, certificats).<\/li>\n<li><code>reject_unsigned_commits: true<\/code> \u2014 Exige des commits sign\u00e9s GPG (GitLab Premium+).<\/li>\n<li><code>commit_message_regex<\/code> \u2014 Impose les messages de commit conventionnels pour des pistes d&#8217;audit propres.<\/li>\n<li><code>max_file_size<\/code> \u2014 Emp\u00eache de commiter accidentellement de gros fichiers binaires.<\/li>\n<li><code>member_check: true<\/code> \u2014 Rejette les commits provenant de non-membres du projet.<\/li>\n<\/ul>\n<h2>9. Timeouts de jobs et <code>interruptible<\/code><\/h2>\n<p>Les jobs incontr\u00f4l\u00e9s gaspillent des ressources et peuvent \u00eatre exploit\u00e9s pour du cryptomining. D\u00e9finissez des timeouts explicites et marquez les jobs non critiques comme interruptibles afin qu&#8217;ils soient annul\u00e9s lorsqu&#8217;un nouveau pipeline d\u00e9marre sur la m\u00eame branche.<\/p>\n<pre><code># .gitlab-ci.yml \u2014 timeouts et interruptible\ndefault:\n  timeout: 30m          # Timeout global par d\u00e9faut pour tous les jobs\n  interruptible: true   # Annuler les jobs en cours lorsqu'un nouveau commit est pouss\u00e9\n  retry:\n    max: 1\n    when:\n      - runner_system_failure\n      - stuck_or_timeout_failure\n\ntest:\n  stage: test\n  timeout: 15m\n  interruptible: true\n  script:\n    - pytest tests\/ --timeout=600\n\ndeploy_production:\n  stage: deploy\n  timeout: 20m\n  interruptible: false  # Ne JAMAIS annuler un d\u00e9ploiement en production en cours\n  script:\n    - .\/deploy.sh production\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n  environment:\n    name: production<\/code><\/pre>\n<p><strong>Recommandations :<\/strong><\/p>\n<ul>\n<li>D\u00e9finissez un <strong>timeout au niveau projet<\/strong> dans Settings &gt; CI\/CD &gt; General Pipelines (recommand\u00e9 : 60 minutes maximum).<\/li>\n<li>D\u00e9finissez des <strong>timeouts au niveau job<\/strong> plus courts que la valeur par d\u00e9faut du projet.<\/li>\n<li>Marquez les jobs de test et de lint comme <code>interruptible: true<\/code> pour \u00e9conomiser la capacit\u00e9 des runners.<\/li>\n<li>Marquez les jobs de d\u00e9ploiement comme <code>interruptible: false<\/code> pour \u00e9viter les d\u00e9ploiements partiels.<\/li>\n<li>Utilisez <code>retry<\/code> uniquement pour les d\u00e9faillances d&#8217;infrastructure transitoires \u2014 jamais pour les \u00e9checs de tests.<\/li>\n<\/ul>\n<h2>Tableau de r\u00e9f\u00e9rence rapide<\/h2>\n<table>\n<thead>\n<tr>\n<th>Contr\u00f4le<\/th>\n<th>O\u00f9 configurer<\/th>\n<th>Tier minimum<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Variables prot\u00e9g\u00e9es\/masqu\u00e9es<\/td>\n<td>Settings &gt; CI\/CD &gt; Variables<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>Restriction des runners<\/td>\n<td>Settings &gt; CI\/CD &gt; Runners<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>Environnements prot\u00e9g\u00e9s<\/td>\n<td>Settings &gt; CI\/CD &gt; Protected Environments<\/td>\n<td>Premium<\/td>\n<\/tr>\n<tr>\n<td>Port\u00e9e du CI_JOB_TOKEN<\/td>\n<td>Settings &gt; CI\/CD &gt; Token Access<\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>id_tokens OIDC<\/td>\n<td><code>.gitlab-ci.yml<\/code><\/td>\n<td>Free<\/td>\n<\/tr>\n<tr>\n<td>D\u00e9tection de secrets<\/td>\n<td><code>include: template<\/code><\/td>\n<td>Free (Ultimate pour le dashboard)<\/td>\n<\/tr>\n<tr>\n<td>Push Rules<\/td>\n<td>Settings &gt; Repository &gt; Push Rules<\/td>\n<td>Premium<\/td>\n<\/tr>\n<tr>\n<td>Timeouts de jobs<\/td>\n<td>Settings &gt; CI\/CD + <code>.gitlab-ci.yml<\/code><\/td>\n<td>Free<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Pour aller plus loin<\/h2>\n<p>Continuez \u00e0 renforcer la s\u00e9curit\u00e9 de vos pipelines GitLab CI\/CD avec ces ressources compl\u00e9mentaires :<\/p>\n<ul>\n<li><a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/gitlab-ci-cd-security-definitive-guide\/\">Guide de s\u00e9curit\u00e9 GitLab CI\/CD<\/a> \u2014 Un parcours complet de chaque param\u00e8tre de s\u00e9curit\u00e9 dans GitLab CI\/CD.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/secrets-management-ci-cd-pipelines-patterns-vault-2\/\">Bonnes pratiques de gestion des secrets CI\/CD<\/a> \u2014 Plong\u00e9e en profondeur dans l&#8217;int\u00e9gration de vault, la rotation et les secrets \u00e0 moindre privil\u00e8ge.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/short-lived-credentials-workload-identity-federation-ci-cd\/\">Authentification OIDC dans les pipelines CI\/CD<\/a> \u2014 Lab pas \u00e0 pas pour configurer OIDC avec AWS, GCP et Azure.<\/li>\n<li><a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/complete-guide-ci-cd-pipeline-security\/\">Checklist de s\u00e9curit\u00e9 des pipelines CI\/CD<\/a> \u2014 La checklist d&#8217;audit compl\u00e8te couvrant GitHub Actions, GitLab CI et Jenkins.<\/li>\n<li><a href=\"https:\/\/docs.gitlab.com\/ee\/ci\/\" target=\"_blank\" rel=\"noopener\">Documentation officielle GitLab CI\/CD<\/a> \u2014 La r\u00e9f\u00e9rence officielle pour toutes les fonctionnalit\u00e9s de GitLab CI\/CD.<\/li>\n<\/ul>\n<p>La s\u00e9curit\u00e9 n&#8217;est pas une configuration ponctuelle \u2014 c&#8217;est une pratique continue. Revoyez vos param\u00e8tres de s\u00e9curit\u00e9 de pipeline chaque trimestre, effectuez la rotation des credentials, auditez les acc\u00e8s aux runners et maintenez votre instance GitLab \u00e0 jour. Ce cheat sheet vous fournit les fondations. \u00c0 vous maintenant de verrouiller vos pipelines.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Pourquoi la s\u00e9curit\u00e9 de GitLab CI est essentielle Les pipelines GitLab CI\/CD sont puissants \u2014 mais qui dit puissance dit risque. Une variable mal configur\u00e9e peut exposer des secrets. Un runner non restreint peut ex\u00e9cuter du code malveillant. Un environnement non prot\u00e9g\u00e9 peut permettre \u00e0 un d\u00e9veloppeur junior de d\u00e9ployer directement en production. Ce cheat &#8230; <a title=\"Cheat Sheet S\u00e9curit\u00e9 GitLab CI : Variables, Runners, Environnements et OIDC\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/gitlab-ci-security-cheat-sheet\/\" aria-label=\"En savoir plus sur Cheat Sheet S\u00e9curit\u00e9 GitLab CI : Variables, Runners, Environnements et OIDC\">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,53],"tags":[],"post_folder":[],"class_list":["post-452","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-gitlab-ci"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/452","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=452"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/452\/revisions"}],"predecessor-version":[{"id":734,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/452\/revisions\/734"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=452"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=452"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=452"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=452"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}