Aller au contenu principal

Mise en miroir des dépôts

fremforge prend en charge à la fois le miroir pull (un dépôt externe → fremforge, synchronisé selon un planning) et le miroir push (un dépôt fremforge → une destination externe, mis en miroir à chaque push). Les deux sens reposent sur la fonction de miroir de Forgejo et s’exécutent comme des tâches planifiées en arrière-plan.

Configurer un miroir

Miroir pull (externe → fremforge)

Lors de la création d’un nouveau dépôt :

  1. Allez sur frem.sh/repo/migrate (ou cliquez sur « + » → « Nouvelle migration » dans la barre supérieure).
  2. Choisissez le service source : GitHub, GitLab, Gitea, Forgejo, Bitbucket ou Plain Git.
  3. Collez l’URL source (HTTPS).
  4. Cochez « Rendre ce dépôt mirroir » avant de cliquer sur « Migrer le dépôt ». Sans cette case, l’import est une copie unique et non une synchronisation continue.
  5. L’intervalle du miroir est de 8 heures par défaut. Vous pouvez le modifier après la création sur la page Paramètres → Réglages miroir du dépôt. L’intervalle minimal est de 10 minutes.

Miroir push (fremforge → externe)

Sur un dépôt existant :

  1. Paramètres du dépôt → Réglages miroir → section « Push Mirrors ».
  2. Ajoutez l’URL de destination (HTTPS) et les identifiants (nom d’utilisateur + jeton d’accès du service de destination).
  3. Le miroir s’exécute à chaque push sur la branche par défaut du dépôt fremforge, ainsi qu’à l’intervalle configuré (8 h par défaut).

Hôtes source et destination pris en charge

Le trafic sortant en protocole Git depuis le pod Forgejo de fremforge passe par une liste d’autorisation (défense en profondeur contre le SSRF et l’exfiltration de données via des URL de miroir). Les hôtes suivants sont actuellement autorisés :

HôteMiroir pullMiroir pushRemarques
github.com (+ *.githubusercontent.com)✅✅Y compris GitHub Enterprise Cloud (*.github.com) ; les instances GHES sur des domaines appartenant au client nécessitent un ajout à la liste d’autorisation (voir ci-dessous).
*.gitlab.com✅✅GitLab.com SaaS. Les instances GitLab auto-hébergées sur des domaines du client nécessitent un ajout à la liste d’autorisation.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center sur des domaines du client nécessite un ajout à la liste d’autorisation.
codeberg.org✅✅Hébergement communautaire basé sur Forgejo.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (noms d’hôte actuels et historiques).
code.forgejo.org✅✅L’hébergement propre du projet Forgejo.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

HTTPS uniquement. Les URL de miroir SSH (git@<host>:owner/repo.git) ne sont pas prises en charge aujourd’hui : le pod Forgejo de fremforge achemine le trafic Git via le proxy HTTPS, et non par une sortie directe sur le port 22. Utilisez la forme HTTPS de votre URL source avec un jeton d’accès personnel si la source exige une authentification.

Les cibles de réseaux privés sont bloquées. Les plages RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et les adresses link-local sont rejetées au niveau de Forgejo, quelle que soit la liste d’autorisation. Pour mettre en miroir depuis un serveur Git interne d’entreprise, ce serveur doit être joignable sur l’internet public via un nom d’hôte stable.

Ajouter un hôte à la liste d’autorisation

Pour les sources ou destinations de miroir absentes de la liste ci-dessus (généralement GitLab auto-hébergé / GitHub Enterprise Server / Bitbucket Data Center sur un domaine appartenant au client) :

  1. Écrivez à support@frem.sh en indiquant le nom d’hôte et une brève description du cas d’usage.
  2. Nous l’ajoutons à la liste d’autorisation globale sous un jour ouvré (pas de cloisonnement par client aujourd’hui : l’hôte devient joignable pour les opérations de miroir de tous les tenants fremforge).
  3. Vous pouvez ensuite configurer le miroir comme décrit ci-dessus.

Pourquoi nous vous demandons de passer par nous plutôt que de le faire vous-même : la liste d’autorisation est partagée par le proxy de sortie du cluster. L’application de politiques par tenant, qui permettrait à chaque administrateur d’organisation de gérer sa propre liste, figure sur notre feuille de route (phase 2) ; d’ici là, les ajouts sont examinés par un opérateur pour la raison ci-dessus.

Limites et caractéristiques

  • Intervalle du miroir pull : 10 minutes au minimum, 8 heures par défaut, configurable par dépôt.
  • Déclenchement du miroir push : à chaque push sur la branche par défaut + à l’intervalle configuré.
  • Identifiants au repos : Forgejo chiffre les identifiants de miroir dans sa base de données (les mots de passe de miroir ne sont pas exposés aux opérateurs de fremforge).
  • Les opérations de miroir comptent dans le métrage du dépôt, comme les opérations Git normales.

Modèle de menace et notes d’audit

  • Chaque création, modification ou suppression de miroir émet un événement d’audit visible sur <org>/_admin/audit-log.
  • Les échecs de récupération d’un miroir (par exemple des identifiants révoqués à la source) sont consignés comme avertissements dans le fil d’activité du dépôt. Notre astreinte n’est pas alertée en cas d’échec d’un miroir client.
  • Un miroir push dont les identifiants ont fuité donne au service de destination la possibilité de lire votre dépôt (et d’y écrire si vous avez configuré le push). Traitez le jeton d’accès comme tout autre identifiant : renouvelez-le si vous soupçonnez une compromission ; la procédure de renouvellement est documentée par le service de destination.

Voir aussi