Zum Hauptinhalt springen

Repository-Mirroring

fremforge unterstützt sowohl Pull-Mirroring (ein externes Repository → fremforge, nach Zeitplan synchron gehalten) als auch Push-Mirroring (ein fremforge-Repository → ein externes Ziel, bei jedem Push gespiegelt). Beide Richtungen nutzen die zugrunde liegende Mirror-Funktion von Forgejo und laufen als geplante Hintergrundjobs.

Einen Mirror einrichten

Pull-Mirror (extern → fremforge)

Beim Anlegen eines neuen Repositorys:

  1. Öffne frem.sh/repo/migrate (oder klicke in der oberen Leiste auf „+“ → „Neue Migration“).
  2. Wähle den Quelldienst: GitHub, GitLab, Gitea, Forgejo, Bitbucket oder Plain Git.
  3. Füge die Quell-URL (HTTPS) ein.
  4. Setze das Häkchen bei „Dieses Repository wird ein Spiegel sein“, bevor du auf „Repository migrieren“ klickst. Ohne dieses Häkchen ist der Import eine einmalige Kopie und keine laufende Synchronisation.
  5. Das Mirror-Intervall beträgt standardmäßig 8 Stunden. Du kannst es nach dem Anlegen unter Einstellungen → Spiegeleinstellungen des Repositorys ändern. Das kürzeste Intervall sind 10 Minuten.

Push-Mirror (fremforge → extern)

In einem bestehenden Repository:

  1. Repository → Einstellungen → Spiegeleinstellungen → Abschnitt „Push Mirrors“.
  2. Füge die Ziel-URL (HTTPS) und die Zugangsdaten hinzu (Benutzername + Zugriffstoken für den Zieldienst).
  3. Der Mirror läuft bei jedem Push auf den Standard-Branch des fremforge-Repositorys und zusätzlich im konfigurierten Intervall (standardmäßig 8 h).

Unterstützte Quell- und Zielhosts

Der ausgehende Git-Verkehr aus dem Forgejo-Pod von fremforge läuft über eine Allowlist (gestaffelte Abwehr gegen SSRF und Datenabfluss über Mirror-URLs). Derzeit sind folgende Hosts erlaubt:

HostPull-MirrorPush-MirrorHinweise
github.com (+ *.githubusercontent.com)✅✅Einschließlich GitHub Enterprise Cloud (*.github.com); GHES-Instanzen auf kundeneigenen Domains brauchen einen Eintrag in der Allowlist (siehe unten).
*.gitlab.com✅✅GitLab.com SaaS. Selbst gehostete GitLab-Instanzen auf Kunden-Domains brauchen einen Eintrag in der Allowlist.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center auf Kunden-Domains braucht einen Eintrag in der Allowlist.
codeberg.org✅✅Community-Hosting auf Basis von Forgejo.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (moderne + alte Hostnamen).
code.forgejo.org✅✅Das eigene Hosting des Forgejo-Projekts.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

Nur HTTPS. SSH-basierte Mirror-URLs (git@<host>:owner/repo.git) werden derzeit nicht unterstützt – der Forgejo-Pod von fremforge leitet Git-Verkehr über den HTTPS-Proxy, nicht direkt über Port 22 nach außen. Nutze die HTTPS-Form deiner Quell-URL mit einem persönlichen Zugriffstoken, wenn die Quelle eine Authentifizierung verlangt.

Ziele in privaten Netzen werden blockiert. RFC1918-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) und Link-Local werden unabhängig von der Allowlist auf der Forgejo-Ebene abgewiesen. Um von einem internen Git-Server deines Unternehmens zu spiegeln, muss dieser über einen festen Hostnamen im öffentlichen Internet erreichbar sein.

Einen Host zur Allowlist hinzufügen

Für Mirror-Quellen oder -Ziele, die nicht in der Liste oben stehen (typischerweise selbst gehostetes GitLab / GitHub Enterprise Server / Bitbucket Data Center auf einer kundeneigenen Domain):

  1. Schreibe an support@frem.sh mit dem Hostnamen und einer kurzen Beschreibung des Anwendungsfalls.
  2. Wir nehmen ihn innerhalb eines Werktags in die globale Allowlist auf (eine Beschränkung pro Kunde gibt es derzeit nicht – der Host wird für Mirror-Vorgänge aller fremforge-Mandanten erreichbar).
  3. Danach kannst du den Mirror wie oben beschrieben einrichten.

Warum wir das auf Anfrage machen statt per Selbstbedienung: Die Allowlist gilt gemeinsam für den Egress-Proxy des ganzen Clusters. Eine Durchsetzung von Richtlinien pro Mandant, mit der jede Organisationsverwaltung ihre eigene Allowlist pflegen könnte, steht auf unserer Roadmap (Phase 2); bis dahin werden Ergänzungen aus dem genannten Grund von einem Operator geprüft.

Grenzen und Eigenschaften

  • Intervall für Pull-Mirrors: mindestens 10 Minuten, standardmäßig 8 Stunden, pro Repository einstellbar.
  • Auslöser für Push-Mirrors: bei jedem Push auf den Standard-Branch + im konfigurierten Intervall.
  • Zugangsdaten im Ruhezustand: Forgejo verschlüsselt Mirror-Zugangsdaten in seiner Datenbank (Mirror-Passwörter sind für fremforge-Operatoren nicht einsehbar).
  • Mirror-Vorgänge zählen zur Verbrauchsmessung des Repositorys, genauso wie normale Git-Vorgänge.

Bedrohungsmodell und Audit-Hinweise

  • Jedes Anlegen, Ändern und Löschen eines Mirrors erzeugt ein Audit-Ereignis, das du unter <org>/_admin/audit-log sehen kannst.
  • Fehlgeschlagene Mirror-Abrufe (z. B. weil die Zugangsdaten an der Quelle widerrufen wurden) werden als Warnungen im Aktivitäts-Feed des Repositorys protokolliert. Bei Fehlern in Kunden-Mirrors alarmieren wir unsere Rufbereitschaft nicht.
  • Ein Push-Mirror mit geleakten Zugangsdaten gibt dem Zieldienst die Möglichkeit, dein Repository zu lesen (und zu schreiben, wenn du Push konfiguriert hast). Behandle das Zugriffstoken wie jede andere Zugangsberechtigung – rotiere es, wenn du eine Kompromittierung vermutest; wie das geht, ist beim Zieldienst dokumentiert.

Siehe auch