Maîtriser les permissions dans GitLab CI
Pourquoi le contrôle d'accès est-il vital ?
Dans une usine logicielle moderne, tout le monde n'a pas besoin de posséder les clés de tous les bureaux. Donner un accès total à un stagiaire qui vient d'arriver ou à un client externe présente un risque de sécurité majeur. GitLab utilise un système de permissions granulaires pour s'assurer que chaque membre de l'équipe possède exactement les droits nécessaires à sa mission.
Imaginez que votre projet est un immeuble sécurisé. Le Guest reste à l'accueil, le Reporter peut visiter les bureaux pour inspecter le travail, le Developer possède son propre bureau pour produire et le Maintainer est le gestionnaire qui possède le pass général de l'immeuble. De nos jours, cette rigueur est le socle de la culture DevSecOps.
Niveaux de permissions des utilisateurs
Le tableau suivant résume les capacités de chaque rôle au sein d'un projet. Notez que de nos jours, le rôle historiquement nommé "Master" est définitivement devenu Maintainer pour plus de clarté.
| Action | Guest | Reporter | Developer | Maintainer |
|---|---|---|---|---|
| Créer des tickets et commenter | ✅ | ✅ | ✅ | ✅ |
| Cloner et télécharger le code | ❌ | ✅ | ✅ | ✅ |
| Créer des branches et Merge Requests | ❌ | ❌ | ✅ | ✅ |
| Pousser vers des branches non protégées | ❌ | ❌ | ✅ | ✅ |
| Gérer les Jalons (Milestones) | ❌ | ❌ | ✅ | ✅ |
| Annuler ou relancer des jobs CI/CD | ❌ | ❌ | ✅ | ✅ |
| Ajouter de nouveaux membres | ❌ | ❌ | ❌ | ✅ |
| Pousser vers des branches protégées (main) | ❌ | ❌ | ❌ | ✅ |
| Gérer les Runners et variables secrètes | ❌ | ❌ | ❌ | ✅ |
Permissions spécifiques à GitLab CI/CD
L'automatisation possède ses propres règles de sécurité. Les permissions CI/CD déterminent qui peut manipuler les Pipelines et accéder aux ressources critiques comme le registre d'images Docker.
Capacités liées aux Jobs
Lorsqu'un pipeline s'exécute, il utilise les droits de l'utilisateur qui a déclenché le commit. Voici les limitations techniques rencontrées :
- Visualisation : Les Guests et Reporters peuvent voir l'état des jobs, mais ne peuvent pas voir les logs détaillés si ceux-ci contiennent des informations sensibles.
- Nettoyage : Seuls les Developers et rôles supérieurs peuvent supprimer les artefacts (fichiers générés) d'un job.
- Sécurité : Seuls les Maintainers peuvent configurer les Shared Runners (Runners partagés) à l'échelle du projet.
Interaction avec le registre de conteneurs
Le stockage des images Docker est très encadré :
- Pull : Autorisé à partir du rôle Reporter (lecture seule).
- Push/Delete : Strictement réservé au rôle Developer et supérieurs.
Échec de permission
Voici ce qui s'affiche dans votre terminal si vous tentez de pousser du code vers la branche protégée main alors que vous ne possédez que le rôle Developer :
Sortie terminal - Erreur de permission :
git push origin mainSortie terminal - Erreur de permission :
remote: GitLab: You are not allowed to push code to protected branches on this project.
To https://gitlab.example.com/mon-groupe/mon-projet.git
! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 'https://gitlab.example.com/mon-groupe/mon-projet.git'Focus sur le LFS
LFS (Large File Storage) est une extension de Git qui permet de gérer les fichiers volumineux (vidéos, graphiques haute résolution) sans ralentir le dépôt. Les permissions LFS suivent strictement les permissions du dépôt : si vous avez le droit de "Push" sur une branche, vous avez le droit d'envoyer vos fichiers LFS associés.
Conclusion
Bien configurer les Permissions est la première étape pour protéger l'intégrité de votre code. Cela permet d'automatiser vos tests en toute confiance, sachant que seules les personnes habilitées peuvent modifier les réglages critiques ou déployer en production.
Maintenant que vous savez "qui a le droit de quoi", nous allons voir comment donner au système les moyens techniques d'agir. Dans le prochain chapitre, nous apprendrons à configurer les GitLab Runners, ces moteurs qui exécutent vos tâches automatisées.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
10 commentaires
Ce tableau est hyper clair sur le Dev/Maintainer split. On oublie trop souvent que le simple fait de pouvoir *créer des branches* est déjà un niveau de risque critique.
Le passage de Master à Maintainer est vital pour la clarté, je suis d'accord. Sinon, les nouveaux devs viennent avec un préjugé obsolète sur les droits
Le principe du moindre privilège (PoLP) appliqué à CI/CD : c'est le socle. Quand on exécute des jobs, on doit s'assurer que l'utilisateur du runner n'a que les droits strictement nécessaires (par exemple, accès lecture/écriture uniquement sur les artifacts spécifiques au job).
Sinon, c'est une porte ouverte pour un leak de données si un stage échoue ou si le script est compromis.
Super résumé. Pour aller plus loin, il faut absolument regarder les **Protected Branches** et configurer les `rules:` dans le `.gitlab-ci.yml`. Ne jamais faire confiance à une `if: $CI_COMMIT_BRANCH` sans validation de rôle.
On a vu la grosse faille en Prod où un développeur pouvait pousser sur la `main` juste parce qu'il avait le rôle 'Developer' mais pas le rôle 'Maintainer' sur la branche protégée. Le réglage des `Allowed to Merge` est vraiment la seule défense.
C'est la différence entre Dev et Maintainer qui est la plus cruciale : le pouvoir d'**ajouter de nouveaux membres**.
C'est le point de non-retour. Le Maintainer peut ajouter quelqu'un, et ce quelqu'un peut ensuite dérégler tout le reste. C'est la clé du risque d'escalade des privilèges.
Pour les organisations gérant plusieurs projets, pensez au niveau global des groupes. Limiter qui peut modifier la politique de sécurité de l'instance elle-même est encore plus important que le niveau projet.
⚠️ Attention, si vous utilisez des Runners auto-hébergés (`runner-machine`), vous devez gérer la sécurité du nœud hôte lui-même. Le problème n'est pas juste l'utilisateur GitLab, mais le contexte OS qui exécute le job. Préférez des Pods isolés si c'est possible.
Un point crucial pour le DevSecOps : les permissions doivent s'appliquer au **runner** lui-même, pas seulement à l'utilisateur qui lance le MR. Le `ci_job_runner_user` doit avoir le minimum de droits (sandbox).
Le concept de