Ajouter des utilisateurs sur GitLab : Gérer la collaboration
La force du travail collaboratif
L'un des plus grands avantages de la plateforme est de pouvoir travailler en équipe sur GitLab de manière centralisée. Que vous collaboriez avec d'autres développeurs, des testeurs ou des chefs de projet, vous devez leur donner accès à votre espace de travail pour qu'ils puissent contribuer efficacement.
Cependant, donner accès ne signifie pas donner tous les droits à tout le monde. Le système de permissions GitLab permet de définir des rôles précis pour s'assurer que chaque membre possède uniquement les droits nécessaires à sa mission. Cela garantit la sécurité de votre code source et évite les erreurs de manipulation sur les branches critiques.
Inviter un nouveau membre manuellement
Le processus d'invitation est simple et se gère directement depuis les paramètres de votre projet pour ajouter des utilisateurs sur GitLab.
Accéder à la gestion des membres
Rendez-vous dans votre projet. Dans le menu latéral de gauche, survolez l'onglet Manage et cliquez sur l'option Members (Membres).
"L'onglet Members est le centre de contrôle des accès de votre projet"
Configurer l'accès
Sur l'écran qui s'affiche, vous devez remplir les informations suivantes pour inviter un collaborateur :
- GitLab member or Email : Tapez le nom d'utilisateur ou l'adresse email de la personne à inviter.
- Select a role : Choisissez le niveau de permission adapté à ses responsabilités.
Cliquez sur le bouton bleu Invite pour valider l'invitation. Un message de succès confirmera l'ajout de l'utilisateur.
Information
Vous aurez ensuite accès à l'option Access expiration date (Optionnel) ou pouvez définir une date à laquelle l'accès sera automatiquement coupé, idéal pour les prestataires temporaires.
Comprendre les rôles utilisateurs sur GitLab :
- Guest : Peut uniquement voir les tickets (issues) et poster des commentaires sans accéder au code.
- Reporter : Peut lire le code et les rapports de test, mais ne peut pas effectuer de modifications.
- Developer : Peut modifier le code et créer des branches, c'est le rôle standard pour un développeur.
- Maintainer : Peut configurer les paramètres du projet et valider les fusions sur la branche principale.
Nous examinerons plus en détail le rôle des utilisateurs dans les chapitres suivants.
Importer des membres depuis un autre projet
Si vous avez déjà une équipe constituée sur un autre projet, vous pouvez gérer vos collaborateurs plus rapidement grâce à la fonction d'importation intégrée.
Utiliser la fonction Import
Sur la même page des membres, cliquez sur le bouton Import situé en haut à droite de l'interface.
Sélectionner la source
Choisissez le projet source qui contient déjà vos collaborateurs, puis cliquez sur Import project members. Toute l'équipe sera instantanément ajoutée avec les mêmes rôles GitLab.
"Un gain de temps précieux pour la gestion d'équipes récurrentes"
Conclusion
Savoir gérer les accès est un pilier fondamental d'une bonne méthodologie DevOps. Vous pouvez désormais inviter vos collègues et leur attribuer des rôles adaptés pour sécuriser votre flux de travail collaboratif.
Cependant, lorsque votre équipe grandit, inviter des personnes projet par projet peut devenir fastidieux. Pour organiser vos collaborateurs à plus grande échelle et gérer des groupes sur GitLab, nous allons explorer une solution plus globale dans le chapitre suivant.
Espace commentaire
Écrire un commentaire
Rejoignez la discussion
Vous devez être connecté pour poster un message.
18 commentaires
C'est basique, mais vrai. Le fait de séparer les rôles (Reporter vs Developer) sur GitLab, c'est la clé de voûte d'une bonne gouvernance CI/CD. Ne jamais laisser le write access à tout le monde.
Question de sécurité plus pointue : pour les prestataires temporaires, l'utilisation de l'option
Access expiration dateest vitale. On a dû faire ça pour un client qui avait des devs freelance, sinon on était en train de laisser des clés trop longtemps.Le concept de 'Maintainer' valider les merges sur la
mainest fondamental. Il faut absolument que ce soit configuré avec des Merge Request Approvals pour éviter les pushes directs.Attention à ne pas confondre les rôles de niveau
Projectet les permissions au niveauGroup. Une bonne structure d'équipe passe par une bonne segmentation des accès (groupes vs projets).L'importation depuis un autre projet (
Import project members) est un gain de temps énorme quand on refactor un monorepo. J'ai testé ça avec 50+ utilisateurs et ça a fonctionné nickel.Ok, mais quand on parle de gestion des accès, on doit forcément parler d'intégration LDAP/SSO. Uniquement par email/username, c'est trop manuel et ça ne scale pas au-delà de 10 personnes.
Le rôle
Guestest souvent sous-estimé. On l'utilise souvent juste pour des accès JIRA/Issue Tracking sans jamais leur donner accès au code source. Juste pour le suivi de ticket, ça suffit.Par contre, le fait de pouvoir définir une expiration automatique de l'accès, même si c'est optionnel, c'est un must-have pour l'audit trail. C'est le côté compliance qui nous motive.
Juste un conseil en pratique : si vous avez un gros groupe, utilisez plutôt la gestion par groupes/top-level namespace avant de gérer les membres projet par projet. C'est plus propre pour la visibilité.
Le workflow Dev/Maintainer est parfait pour les petites équipes, mais dans les grands groupes, il faut rajouter la gestion des 'Protected Branches' par des règles spécifiques, pas juste par le rôle.
Le guide est très clair sur les bases. Mais si on veut être vraiment béton sur la sécu, faut absolument passer par la gestion des 'API Tokens' avec expiration et scope très limités. C'est l'autre facette de la gestion des droits.
J'ai trouvé que la méthode manuelle (aller dans
Manage > Members) était chronophage si l'équipe changeait souvent. Je préfère automatiser l'ajout/suppression via des scripts CI/CD (via l'API, évidemment).Super rappel sur la séparation des droits. Beaucoup de jeunes équipes oublient que même un 'Developer' ne doit pas pouvoir toucher aux paramètres de security settings du projet.
L'importation est stylée. Mais si on change un identifiant ou un rôle sur la source, est-ce que la mise à jour se propage correctement ? Ça dépend de l'API, il faudrait tester le delta update.
Quand j'ai commencé, j'étais en train de faire du 'Wildcard Access' sur toutes les branches. C'était un cauchemar de merge conflict. Le role Maintainer qui valide les fusions limite ça fortement, c'est un must.
Je suis de l'avis qu'il faut faire un focus sur l'intégration des RBAC (Role-Based Access Control) au niveau du Groupe GitLab pour que les projets enfants héritent des règles, au lieu de tout reconfigurer au niveau du projet.
Ce document ne couvre pas assez la notion de 'scoped access' pour les CI/CD jobs. Quand on parle de droits, on parle aussi des secrets et des variables d'environnement que ces users peuvent potentiellement modifier ou voir.
Très bien pour les rôles Dev/Maintainer. Par contre, pour les pipelines, même un Developer ne devrait pas avoir le droit de
delete pipelinepar défaut. Ça doit être un droit restreint au niveau des admins.