Naar de hoofdinhoud

Repository's spiegelen

fremforge ondersteunt zowel pull-mirroring (een externe repository → fremforge, volgens een schema gesynchroniseerd) als push-mirroring (een fremforge-repository → een externe bestemming, bij elke push gespiegeld). Beide richtingen gebruiken de onderliggende mirrorfunctie van Forgejo en draaien als geplande achtergrondtaken.

Een mirror instellen

Pull-mirror (extern → fremforge)

Bij het aanmaken van een nieuwe repository:

  1. Ga naar frem.sh/repo/migrate (of klik in de bovenbalk op “+” → “Nieuwe migratie”).
  2. Kies de bronservice: GitHub, GitLab, Gitea, Forgejo, Bitbucket of Plain Git.
  3. Plak de bron-URL (HTTPS).
  4. Vink “This repository will be a mirror” aan voordat je op Migrate klikt. Zonder dit vinkje is de import een eenmalige kopie en geen doorlopende synchronisatie.
  5. Het mirrorinterval is standaard 8 uur. Na het aanmaken kun je het wijzigen op de pagina Instellingen → Mirror instellingen van de repository. Het minimale interval is 10 minuten.

Push-mirror (fremforge → extern)

Bij een bestaande repository:

  1. Instellingen van de repository → Mirror instellingen → het onderdeel “Push Mirrors”.
  2. Voeg de bestemmings-URL (HTTPS) en de inloggegevens toe (gebruikersnaam en toegangstoken voor de bestemmingsservice).
  3. De mirror draait bij elke push naar de standaardbranch van de fremforge-repository en daarnaast op het ingestelde interval (standaard 8 uur).

Ondersteunde bron- en bestemmingshosts

Uitgaand Git-verkeer vanuit de Forgejo-pod van fremforge loopt via een allowlist (extra verdediging tegen SSRF en het weglekken van gegevens via mirror-URL’s). De volgende hosts zijn op dit moment toegestaan:

HostPull-mirrorPush-mirrorOpmerkingen
github.com (+ *.githubusercontent.com)✅✅Inclusief GitHub Enterprise Cloud (*.github.com); GHES-instanties op domeinen van de klant hebben een toevoeging aan de allowlist nodig (zie hieronder).
*.gitlab.com✅✅GitLab.com SaaS. Zelfgehoste GitLab-instanties op domeinen van de klant hebben een toevoeging aan de allowlist nodig.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center op domeinen van de klant heeft een toevoeging aan de allowlist nodig.
codeberg.org✅✅Communityhosting op basis van Forgejo.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (moderne en oude hostnamen).
code.forgejo.org✅✅De eigen hosting van het Forgejo-project.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

Alleen HTTPS. Mirror-URL’s via SSH (git@<host>:owner/repo.git) worden op dit moment niet ondersteund: de Forgejo-pod van fremforge stuurt Git-verkeer via de HTTPS-proxy en niet rechtstreeks via poort 22 naar buiten. Gebruik de HTTPS-vorm van je bron-URL met een persoonlijk toegangstoken als de bron authenticatie vereist.

Doelen in privénetwerken worden geblokkeerd. RFC1918-bereiken (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) en link-local worden in de Forgejo-laag geweigerd, ongeacht de allowlist. Wil je spiegelen vanaf een interne Git-server van je bedrijf, dan moet die server via een vaste hostnaam op het openbare internet bereikbaar zijn.

Een host aan de allowlist toevoegen

Voor bronnen of bestemmingen die niet in de lijst hierboven staan (meestal zelfgehoste GitLab / GitHub Enterprise Server / Bitbucket Data Center op een domein van de klant):

  1. Mail naar support@frem.sh met de hostnaam en een korte toelichting op het gebruik.
  2. We voegen de host binnen één werkdag toe aan de globale allowlist (er is vandaag geen afbakening per klant: de host wordt voor mirrorbewerkingen bereikbaar vanuit alle fremforge-tenants).
  3. Daarna kun je de mirror instellen zoals hierboven beschreven.

Waarom we erom vragen in plaats van je het zelf te laten doen: de allowlist wordt gedeeld door de egress-proxy van het hele cluster. Beleidshandhaving per tenant, waarmee elke beheerder van een organisatie een eigen allowlist kan beheren, staat op onze roadmap (fase 2); tot die tijd worden toevoegingen om de genoemde reden door een operator beoordeeld.

Limieten en kenmerken

  • Interval van een pull-mirror: minimaal 10 minuten, standaard 8 uur, per repository instelbaar.
  • Trigger van een push-mirror: bij elke push naar de standaardbranch en op het ingestelde interval.
  • Inloggegevens in rust: Forgejo versleutelt de inloggegevens van mirrors in zijn database (wachtwoorden van mirrors zijn niet zichtbaar voor operators van fremforge).
  • Mirrorbewerkingen tellen mee voor de metering van de repository, op dezelfde manier als gewone Git-bewerkingen.

Dreigingsmodel en auditnotities

  • Elke keer dat een mirror wordt aangemaakt, gewijzigd of verwijderd, ontstaat een auditgebeurtenis die je ziet op <org>/_admin/audit-log.
  • Mislukte fetches van een mirror (bijvoorbeeld omdat de inloggegevens bij de bron zijn ingetrokken) worden als waarschuwing vastgelegd in de activiteitenfeed van de repository. We alarmeren onze dienstdoende engineer niet bij mislukte mirrors van klanten.
  • Een push-mirror met gelekte inloggegevens geeft de bestemmingsservice de mogelijkheid je repository te lezen (en erin te schrijven, als je push hebt ingesteld). Behandel het toegangstoken als elk ander geheim: roteer het als je vermoedt dat het gecompromitteerd is; de stappen daarvoor staan in de documentatie van de bestemmingsservice.

Zie ook