IP-Allowlist
Die IP-Allowlist beschränkt deine Organisation auf die Netze, die du angibst. Ist die Liste gesetzt, wird eine Anfrage von einer Adresse außerhalb abgewiesen, selbst wenn die Zugangsdaten gültig sind und sich der Nutzer per SSO angemeldet hat.
Sie liegt unter Sicherheit › Zugriff › IP-Allowlist (<your-org>/_admin/security/access/ip-allowlist). Nur Owner der Organisation können sie ändern.
Wo die Liste gilt
Es gibt eine Liste, und sie gilt für jeden der folgenden Bereiche:
| Bereich | Was außerhalb der Liste abgewiesen wird |
|---|---|
| Web-Verwaltung | <your-org>/_admin/* |
| fremforge-API | https://frem.sh/_app/api/v1/orgs/<your-org>/* |
| Weboberfläche der Repositorys | Die Seiten der Organisation und ihre privaten Repositorys, Dateien, Issues, Pull Requests, Releases und Anhänge |
| Forgejo-REST-API | Aufrufe von https://frem.sh/api/v1/ auf die privaten Repositorys der Organisation und auf die Organisation selbst |
| Git über HTTPS | Clone, Fetch und Push |
| Git LFS | Downloads und Uploads von Objekten sowie Datei-Locks |
| Paket-Registrys | Jede Registry, einschließlich der Container-Registry |
| Git über SSH | Nichts. Siehe Git über SSH ist nicht abgedeckt. |
Öffentliche Repositorys bleiben für alle lesbar, weil ihr Inhalt ohnehin öffentlich ist. Ein Mitglied, das in einem öffentlichen Repository angemeldet ist, wird trotzdem geprüft, wenn es pusht, Einstellungen ändert oder die Seiten der Organisation öffnet. Anonyme Besucher sehen nie eine Abweisung: Ein privates Repository sieht für sie genauso aus wie immer.
Die Sicherheitsseite zeigt Wo die Liste gerade gilt mit einer Zeile pro Bereich: Durchgesetzt, Nur protokolliert (mit dem Grund) oder Nicht abgedeckt. Die API liefert dieselbe Information in surfaces. Wenn diese Seite und das Panel sich widersprechen, hat das Panel recht.
Einführung. Die eine Liste für jeden Bereich wird schrittweise eingeschaltet. Bis deine Organisation umgestellt ist, kann das Panel einen Bereich als Nur protokolliert – wird noch ausgerollt anzeigen. Anfragen von außerhalb der Liste werden dann im Audit-Log erfasst, aber nicht abgewiesen. Die Web-Verwaltung und Git über HTTPS werden durchgehend durchgesetzt (bei einer älteren Liste mit dem Scope
webnur die Web-Verwaltung; siehe unten).
Die Liste festlegen
- Verwende die CIDR-Notation:
203.0.113.0/24,2001:db8::/48. Eine einzelne Adresse ist/32, bei IPv6/128. - Gib einen Bereich pro Zeile an oder trenne sie durch Kommas. Die Obergrenze liegt bei 100 Bereichen.
/0wird abgelehnt. Um jede Adresse zu erlauben, lass die Liste leer.- Nimm deine Büro- und VPN-Bereiche auf sowie die ausgehenden Adressen jeder CI, die nicht auf fremforge läuft.
- Die Seite zeigt Deine Adresse gerade, also die Adresse, die fremforge von dir sieht.
Du kannst dich beim Speichern nicht aussperren. Enthält eine durchsetzende Liste deine eigene Adresse nicht, wird das Speichern abgelehnt: Füge entweder deine Adresse hinzu oder setze zuerst das Häkchen bei Nur-Audit-Vorschau.
Eine Änderung wird auf jedem Bereich innerhalb von etwa einer Minute wirksam.
Nur-Audit-Vorschau
Mit eingeschalteter Nur-Audit-Vorschau erfasst jeder Bereich die Anfragen, die er abweisen würde, lässt sie aber durch. So führst du eine Liste gut ein:
- Trage die Bereiche ein und setze das Häkchen bei Nur-Audit-Vorschau. Speichern.
- Nutze die Organisation ein oder zwei Tage wie gewohnt, einschließlich CI und aller Integrationen.
- Sieh dir die Ereignisse
ip_allowlist.would_blockim Audit-Log an. Jedes nennt den Bereich, die Adresse, einen Beispielpfad und wie viele Anfragen es zusammenfasst. - Füge legitime Bereiche hinzu, die du übersehen hast.
- Entferne das Häkchen bei Nur-Audit-Vorschau. Ab jetzt wird die Liste durchgesetzt.
Von fremforge gehostete Runner
CI-Jobs auf fremforges eigenen Runnern erreichen deine Organisation aus dem Netz von fremforge, nicht aus deinem. Der für einen Job ausgestellte Token funktioniert immer. Von fremforge gehostete Runner erlauben (standardmäßig an) entscheidet, ob andere Zugangsdaten, die von einem Runner aus verwendet werden, etwa ein PAT oder ein OAuth-Token, der als Secret hinterlegt ist, ebenfalls funktionieren. Schalte es aus, wenn ein gestohlener PAT auch dann nutzlos sein soll, wenn er aus einem CI-Job heraus verwendet wird.
Selbst gehostete Runner und externe CI werden wie jeder andere Client nach ihrer ausgehenden Adresse beurteilt. Nimm diese Adressen in die Liste auf.
Wenn ein Owner ausgesperrt ist
Deine Adresse kann sich ändern: ein neues Büro, ein VPN-Ausfall, eine Reise. Break-Glass schaltet jeden Bereich für 24 Stunden auf reines Protokollieren. Nichts wird dauerhaft umgangen, und jeder Schritt wird im Audit-Log erfasst.
- Selbstbedienung für Owner. Öffne
https://frem.sh/_app/ip-allowlist/break-glass?org=<your-org>aus einem beliebigen Netz, angemeldet als Owner. Wir schicken einen signierten Link an die eigene E-Mail-Adresse deines Kontos. Der Link ist 30 Minuten gültig. Öffne ihn und bestätige. Abweisungsseiten und Git-Fehlermeldungen für deine Organisation geben diese Adresse aus. - Der Support von fremverk kann dasselbe Break-Glass für deine Organisation auf Anfrage einschalten.
Break-Glass endet nach 24 Stunden von selbst und wird nie verlängert, solange es aktiv ist. Korrigiere die Liste und beende es dann früher mit Break-Glass jetzt beenden auf der Sicherheitsseite.
Aktionen im Audit-Log: ip_allowlist.break_glass.activated, ip_allowlist.break_glass.ended.
Listen, die erstellt wurden, bevor eine Liste jeden Bereich abdeckte
Ältere Listen hatten einen Scope: web (nur Web-Verwaltung) oder web+git (zusätzlich Git über HTTPS). Diese Listen setzen weiterhin dort durch, wo sie es bisher taten. Auf den übrigen Bereichen protokollieren sie Abweisungen, die erfolgt wären, für 30 Tage, nachdem wir die Owner der Organisation benachrichtigt haben, und setzen danach auch dort durch. Die Sicherheitsseite zeigt das Datum.
Um die Wartezeit zu überspringen, verwende Jetzt auf allen Bereichen durchsetzen (Aktion im Audit-Log security.ip_allowlist.enforce_all). Du kannst eine Liste nicht auf einen alten Scope zurückstellen, und jede neue Liste deckt jeden Bereich ab.
Git über SSH ist nicht abgedeckt
Die IP-Allowlist filtert Git über SSH nicht. SSH erreicht fremforge über einen Load Balancer, der die Adresse des Clients durch die eines unserer eigenen Cluster-Knoten ersetzt, sodass wir die Adresse, von der aus sich deine Entwickler verbinden, nicht sehen. Wir beurteilen eine Verbindung nicht nach einer Adresse, von der wir wissen, dass sie falsch ist. Eine Liste, die stillschweigend jeden SSH-Nutzer blockiert oder stillschweigend alle durchlässt und dabei behauptet zu filtern, wäre schlimmer, als es offen zu sagen.
Wenn deine Organisation jede Git-Operation nach IP filtern muss:
- Schalte SSH-Protokoll erlauben auf der Seite Authentifizierungsrichtlinie aus. Das ist der Standard für Organisationen, die nach dem 22.05.2026 erstellt wurden.
- Lass Mitglieder HTTPS mit Git Credential Manager verwenden (Sichere Anmeldung). Git über HTTPS wird von der Liste abgedeckt.
Ist SSH ausgeschaltet, wird jede Git-Operation über SSH auf die Repositorys der Organisation abgewiesen: Push, Clone und Fetch sowie Git LFS über SSH. Das ist eine Abweisung von SSH als Ganzes, keine IP-Prüfung. Deshalb führt die Sicherheitsseite Git über SSH weiterhin als von der Liste Nicht abgedeckt, und die API gibt ssh_covered: false zurück.
Was eine abgewiesene Anfrage sieht
| Bereich | Antwort |
|---|---|
| fremforge-API | 403 not-in-allowlist mit der Adresse, die wir gesehen haben |
| Weboberfläche, Web-Verwaltung | Eine Abweisungsseite mit der Organisation und der Adresse sowie dem Break-Glass-Link |
| Forgejo-REST-API, LFS, Pakete | 403 mit derselben Meldung |
| Git über HTTPS | git gibt die Meldung und den Break-Glass-Link aus |
Jede Abweisung wird als ip_allowlist.blocked erfasst, jede nur protokollierte Anfrage als ip_allowlist.would_block. Wiederholungen von derselben Adresse auf demselben Bereich werden zu einem Ereignis mit einem count zusammengefasst, sodass eine falsch konfigurierte CI-Schleife das Log nicht flutet.
API
Die Liste ist auch über die fremforge-API verfügbar, mit den Scopes policy:read und policy:write.
# Read: the list, the runner toggle, per-surface modes, break-glass state
curl -H "Authorization: Bearer $TOKEN" \
https://frem.sh/_app/api/v1/orgs/<your-org>/security
# Replace the list
curl -X PUT -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"cidrs":["203.0.113.0/24","2001:db8::/48"],"audit_only":true,"allow_platform_runners":true}' \
https://frem.sh/_app/api/v1/orgs/<your-org>/security/ip-policyDas Objekt ip_allowlist enthält cidrs, scope, audit_only, allow_platform_runners, surfaces (pro Bereich: mode ist enforce oder audit, dazu ein reason), new_surfaces_enforce_at, break_glass_until und ssh_covered.
Über die API gilt der Schutz vor dem Aussperren für die eigene Adresse des Aufrufers. Fehler: invalid-cidr für einen fehlerhaften Bereich, invalid-allowlist für mehr als 100 Bereiche, einen Bereich /0 oder eine Liste, die den Aufrufer blockieren würde, und invalid-scope für einen alten Scope.
Grenzen
- Kann der Git-Dienst von fremforge die Richtlinien der Organisationen länger als 24 Stunden nicht lesen, hört er auf, die Liste durchzusetzen, statt jede Organisation abzuweisen. Die fremforge-API und die Web-Verwaltung sind davon nicht betroffen. Ein solcher Ausfall ist ein Plattformvorfall, um den wir uns kümmern; im Normalbetrieb ist er nicht zu erwarten.
- Adressen werden so beurteilt, wie der Edge von fremforge sie sieht. Ein Proxy oder NAT vor deinen Nutzern bestimmt, welche Adresse das ist; nimm also den ausgehenden Bereich des Proxys in die Liste auf.
- Höchstens 100 Bereiche.