Maîtriser les permissions GitLab CI/CD pour la sécurité

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é.

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 main

Sortie 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'

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.