Git et LDAP en entreprise

Le gain apporté par les gestionnaires de configuration distribués n’est plus à démontrer. Dans ce domaine, les projets libres montrent la voie, et en utilisent presque tous un, que ce soit Git, Mercurial, etc.

Cela fait maintenant quelques temps que je teste Git, y compris au travail en interface avec SVN, notre gestionnaire de configuration d’entreprise.

Pour aller plus loin dans cette utilisation, il fallait envisager de remplacer (ou de doubler) le serveur SVN central par un repository Git central (« bare repository« ). La contrainte imposée par mon administrateur système préféré étant d’avoir le même système de gestion des droits d’accès, centralisé sur notre serveur LDAP (où chaque projet est associé à un groupe d’utilisateurs).

Voici différentes pistes que nous avons envisagées pour ce faire :

Utiliser un hébergement dédié

Une première solution est d’externaliser l’hébergement des sources des projets (sur GitHub par exemple). Pour avoir des dépôts privés, la solution payante. Nous ne souhaitons pas externaliser la gestion des sources, et cette solution ne s’interface pas avec LDAP. Elle a été écartée d’office, mais peut être intéressante.

Gitosis ou Gitolite

Ces deux outils sont basés sur le même principe :

  • le serveur connaît les clés SSH publiques des utilisateurs autorisés
  • à la connexion de l’utilisateur, le serveur vérifie si la machine se connectant correspond à une de ces clés : si oui, on lui associe les droits correspondants sur les différents dépôts hébergés

Cette approche est intéressante, et elle a le mérite d’éviter d’avoir à saisir un login/mot de passe : l’identification et la gestion des droits est transparente côté utilisateur (dès lors que les clés SSH sont correctement configurées sur sa machine).

Pour les détails de mise en oeuvre, je vous renvoie à ce tutoriel complet.

Malgré l’intérêt et la facilité de mise en oeuvre, elle est également écartée car elle ne répond malheureusement pas au cahier des charges : elle ne peut être facilement couplée à un serveur LDAP, ce qui oblige dans notre cas à gérer les droits et les clés SSH de manière séparée.

Droits du système

Une autre approche est d’utiliser les droits du système (à base d’Unix) :

  • chaque projet est accessible en lecture/écriture au groupe, et en lecture seule (ou non accessible) aux autres
  • les membres du projets sont également membres du groupe Unix correspondant, ce qui leur permet de faire des mises à jour du dépôt

Ce système peut partiellement être couplé avec le serveur LDAP pour l’identification, au moyen de systèmes comme PAM LDAP. Ce système a cependant des défauts :

  • ce mécanisme est assez complexe à mettre en oeuvre (en particulier pour synchroniser à la fois les utilisateurs et les groupes avec le serveur LDAP)
  • il offre moins de souplesse de configuration : pour un même projet, on ne peut avoir en même temps des utilisateurs identifiés ayant les droits en lecture/écriture, en lecture seule, et sans aucun droit sur le projet

Par ailleurs, il ne permet l’accès extérieur que si on ouvre les accès SSH sur internet (ce que nous voulons éviter, même dans la DMZ).

Présentation des dépôts par un serveur web

Cette idée nous est venue de ce chapitre du livre ProGit. En particulier, il explique que depuis Git 1.6.6, il est possible d’utiliser des scripts CGI pour accélérer le traitement des requêtes et « émuler » le comportement du protocole « git:// » et ainsi ne pas trop perdre en performances à cause de la couche http(s).

Concernant notre problématique de gestion des droits avec LDAP, elle est automatiquement résolue par la possibilité des serveurs Apache de gérer l’identification grâce à LDAP.

Pour ceux qui seraient tentés par l’aventure, voici la configuration expliquée de « git.conf » que nous ajoutons à la configuration de notre serveur Apache 2 (qu’il faut bien évidemment adapter à vos besoins) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Variables d'environnement pour Git
SetEnv GIT_PROJECT_ROOT /home/git/repositories
SetEnv GIT_HTTP_EXPORT_ALL
 
# Déclaration du VirtualHost Git
<VirtualHost git.courtine.org>
    DocumentRoot /home/git/repositories
    ServerName git.courtine.org
    ErrorLog /var/log/httpd/git.error.log
    LogLevel warn
    CustomLog /var/log/httpd/git.access.log combined
    ServerSignature On
    SSLEngine off
    Options Indexes FollowSymLinks MultiViews
 
    # Scripts CGI de git
    ScriptAlias / /usr/libexec/git-core/git-http-backend/
 
    # Dès la racine du serveur Git, on demande au minimum un utilisateur valide
    <Location "/">
        AuthBasicProvider ldap # Identification déléguée à LDAP
        AuthType Basic
        AuthzLDAPAuthoritative on # Autorisation d'accès uniquement par LDAP
        AuthName "Git server"
        AuthLDAPURL "ldap://ldap.courtine.org:389/CN=users,DC=courtine,DC=org" NONE # Adresse (et filtre) du serveur LDAP
        AuthLDAPBindDN "CN=git,CN=users,DC=courtine,DC=org" # Utilisateur effectuant les recherches dans l'annuaire
        AuthLDAPBindPassword gitPassword # Mot de passe de cet utilisateur
        require valid-user # Obligation d'identification valide
        Order deny,allow
        allow from 192.168.0 # Obligation de connexion depuis le réseau local
    </Location>
 
    # Les droits peuvent être restreints pour chaque dépôt (obligation d'appartenir à un groupe)
    <Location "/projet.git">
        require ldap-group CN=Groupe projet,OU=projets,DC=courtine,DC=org
    </Location>
</VirtualHost>

Conclusion

Ce système présente de nombreux avantages, et c’est pourquoi nous l’avons adopté :

  • Il est complètement intégré au SI, l’identification et la gestion des droits sur les dépôts étant intégralement confiée au serveur LDAP, ce qui répond complètement au cahier des charges
  • elle permet une gestion complète des droits (lecture seule, lecture/écriture, aucune autorisation)
  • elle peut être ouverte sur internet si on a besoin d’un accès externe, via un proxy http dans la DMZ (le https étant recommandé pour des raisons évidentes de sécurité), sans ouvrir d’autre protocole que le http(s)

Pour tordre le cou aux idée reçues, avec le « git http backend« , les benchmarks que j’ai effectués n’ont pas montré de différence flagrante de débit entre « git+ssh:// » et « https:// » (tests évidemment effectués pour un même dépôt, et sur le même serveur).

A titre d’exemple, le clonage complet d’un projet qui compte plus de 1800 commits pour 17 Mo de sources (librairies exclues) via « http:// » prend 25 secondes. Par pudeur, je tairai le temps que met SVN à récupérer le dernier commit uniquement du « trunk » de ce même projet…

Enfin, avec Git, on évite enfin définitivement ce genre de choses

Gitorious

[Mise à jour le 24/11/2010] Sur la suggestion d’Olivier Lamy, je rajoute Gitorious.

C’est un autre hébergeur de dépôt Git, basé sur le même principe que GitHub (hébergement gratuit des projets Open Source). Mais Gitorious est également lui-même un projet Open Source, développé en Ruby on Rails que l’on peut installer dans son système d’information. Voici un tutoriel complet sur cette possibilité.

N’ayant pas testé, je ne sais pas ce que donne cette solution par rapport à notre problématique initiale de couplage LDAP, mais l’interface de gestion de cette application web est très agréable.

À propos de Benoît Courtine

Open Source enthousiast, and CTO at Alcion Group.
Ce contenu a été publié dans Systèmes d'information, avec comme mot(s)-clé(s) , , , , , , , . Vous pouvez le mettre en favoris avec ce permalien.

6 réponses à Git et LDAP en entreprise

  1. Ping : Tweets that mention Git et LDAP en entreprise -- Topsy.com

  2. Hello Benoit,
    petit bémol sur ton article : installer pam-ldap n’est pas compliqué, c’est ce que j’ai sur toutes mes machines ici (sur Debian, ca se résume à répondre aux questions pendant l’installation du paquet. Squeeze simplifie la configration d’ailleurs). Ce qui a l’avantage par ex. de laisser les développerurs créer des dépôts sur le serveur.

    Enfin, tu as oublié une dernière possibilité trés intéressante : Gerrit. A la fois outil de revue de code et de gestion de dépôt, et qui se couple à ldap. Je vais d’ailleurs faire un billet sur le sujet car ce projet mérite d’être connu.
    Mais j’ai uitilisé ldap-apache pendant des années pour SVN puis Hg. Je suis donc content d’apprendre que les avancées réçentes de Git sur le protocole HTTP donne des résultats intéressants.

    • Merci beaucoup pour ce commentaire très instructif, en particulier sur Gerrit : je ne le connaissais pas, c’est pourquoi il ne figure pas dans les solutions comparées. J’irai jeter un coup d’oeil, le projet ayant l’air très intéressant.

      Concernant pam-ldap, ce n’est pas tant son installation qui est compliquée, mais sa configuration (pour attribuer aux utilisateurs les bons groupes d’appartenance, dans notre cas un peu spécifique où l’annuaire LDAP se trouve en réalité être un annuaire Active Directory, et nos distributions à base de RedHat). Mais il est vrai que je n’ai pas entièrement creusé cette solution…

  3. Buakaw dit :

    Le problème c’est que les clients GIT gèrent très simplement ce genre d’authentification, à chaque push/pull il faut entrer le username et le password, à la longue c’est assez lourd…
    Y a-t-il un moyen d’automatiser cela ? Dans Tortoisegit, directement dans windows ou autre ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

ERREUR : le plugin si-captcha signale que le support de la librairie image GD n'est pas détécté dans le PHP !

Contactez votre hébergeur et demandez pourquoi le support de la librairie image GD n'est pas activé pour PHP.

ERREUR : le plugin si-captcha signale que la fonction imagepng n'est pas détectée dans PHP !

Contactez votre hébergeur et demandez lui pourquoi la fonction imagepng n'est pas activée pour le PHP

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>