Comprendre les Permissions Utilisateurs sur GitLab
Pourquoi des niveaux d'accès différents ?
Dans un projet professionnel, tout le monde n'a pas besoin de pouvoir tout modifier. Donner les droits de suppression à un stagiaire qui vient d'arriver ou un accès en écriture à un client qui veut juste suivre l'avancement est un risque inutile. C'est pour cela que GitLab propose des niveaux de permissions granulaires.
Le but est de protéger la branche principale (souvent le code qui tourne en production) tout en permettant à chacun de contribuer efficacement selon son rôle. Bien configurer ces droits, c'est s'assurer que le projet avance sans accrocs techniques ou sécuritaires.
Les rôles principaux sur GitLab
Pour simplifier la gestion, GitLab regroupe les droits dans des rôles prédéfinis. Voici ce qu'il faut retenir pour chaque profil :
-
Guest (Invité) : Le rôle le plus restrictif. Il est idéal pour les personnes qui doivent suivre le projet sans toucher au code (clients, managers). Ils peuvent voir les tickets et laisser des commentaires, mais ne voient pas le code source dans un cadre privé.
-
Reporter (Rapporteur) : Le rôle parfait pour les testeurs ou observateurs techniques. Ils peuvent lire et télécharger le code, mais ils n'ont pas le droit de le modifier ou de créer des branches.
-
Developer (Développeur) : Le rôle standard pour l'équipe technique. Un développeur peut créer des branches, pousser du code sur les branches non protégées et créer des demandes de fusion (Merge Requests).
-
Maintainer (Mainteneur) : C'est l'administrateur du projet. Il a tous les droits : configurer les accès, gérer les runners de CI/CD et surtout, il peut modifier les branches protégées comme le main.
Voici un résumé des actions autorisées selon le rôle attribué à l'utilisateur :
| Action | Guest | Reporter | Developer | Maintainer |
|---|---|---|---|---|
| Créer des tickets et commenter | ✅ | ✅ | ✅ | ✅ |
| Lire et télécharger le code | ❌ | ✅ | ✅ | ✅ |
| Créer des branches / MR | ❌ | ❌ | ✅ | ✅ |
| Gérer les Jalons (Milestones) | ❌ | ❌ | ✅ | ✅ |
| Ajouter de nouveaux membres | ❌ | ❌ | ❌ | ✅ |
| Gérer les variables CI/CD et Runners | ❌ | ❌ | ❌ | ✅ |
Information importante
Le rôle Guest ne peut pas lire ni télécharger le code sur un projet Privé ou Interne. Cependant, sur un projet Public, tout utilisateur (y compris Guest) peut accéder au code source.
Comment modifier les permissions ?
Si vous avez déjà ajouté un membre et que vous souhaitez changer son rôle, la procédure pour modifier les accès est très rapide.
Accéder à la liste des membres
Allez dans le menu Settings puis sélectionnez Members.
Changer le rôle d'un collaborateur
En face du nom de l'utilisateur, cliquez sur le menu déroulant de sa permission actuelle et sélectionnez le nouveau rôle souhaité. La mise à jour est instantanée.
"Le changement de rôle s'applique sans avoir besoin de rafraîchir la page"
Conclusion
Une bonne gestion des permissions est le socle d'un projet sécurisé. En tant que Mainteneur, votre rôle est de veiller à ce que chacun ait assez de liberté pour travailler, sans pour autant mettre en péril la stabilité du code final.
Maintenant que votre équipe est configurée avec les bons accès, vous allez pouvoir commencer à organiser les tâches à accomplir. Pour cela, GitLab propose un outil indispensable : le Système de Tickets (Work items). C'est ce que nous allons découvrir dès maintenant.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
28 commentaires
Pas de souci. Pensez à auditer vos accès une fois par mois, c'est le minimum syndical.
Va dans
Settings -> Memberset remonte les droits un par un. Il n'y a pas de bouton "annuler" magique.J'ai fait une boulette sur les permissions, tout le monde est passé en Guest.
C'est à toi de gérer tes membres. Moins il y en a, mieux c'est pour la sécurité.
Peut-on limiter le nombre de Maintainer ?
Uniquement par le Maintainer. C'est écrit dans le tableau des permissions.
Les runners sont gérés par qui ?
Si la branche n'est pas protégée, oui. Il faut protéger la branche dans les paramètres du projet pour restreindre la suppression.
Mon stagiaire a supprimé une branche par erreur, il était en Developer. C'est normal ?
Non, c'est binaire. Si tu veux du sur-mesure, il faut passer sur les Custom Roles (disponibles en version Premium/Ultimate).
Existe-t-il un rôle entre Developer et Maintainer ?
Regarde si tu n'es pas sur un projet hérité d'un groupe. Les permissions sont peut-être verrouillées au niveau supérieur.
Le menu
Membersest grisé pour moi, je suis pourtant admin.Utilise le provider GitLab. Voici un exemple pour définir un membre :
Comment automatiser l'ajout d'utilisateurs via Terraform ?
Oui, comme précisé dans l'article, sur un projet public, le rôle Guest a accès au code source. C'est le comportement attendu.
J'ai un projet public, les Guest voient tout le code, c'est normal ?
Non, le Reporter est en lecture seule. Pour créer des branches, il faut passer au rôle Developer.
Question bête : un Reporter peut-il créer une branche ?
Merci pour l'article, c'est beaucoup plus clair maintenant.
Non, seul le Maintainer peut gérer les variables CI/CD. C'est une sécurité de base pour éviter que n'importe qui récupère des clés API.
C'est bien le bordel cette gestion des rôles. Un dev peut-il voir les variables CI/CD ?
Ton token n'a probablement pas les scopes nécessaires. Vérifie que tu as bien les droits Maintainer sur le projet.
J'essaie de changer les droits via l'API, j'ai une erreur 403. Une idée ?
Si ton projet est privé, le rôle Guest ne verra pas le code source. Passe-le en Reporter, c'est fait pour ça.