Sicherheitsmodell der gehosteten Runner

Die gehosteten Runner von fremforge führen die Forgejo-Actions-Workflows von Kundinnen und Kunden auf virtuellen T-Cloud-Public-ECS-Maschinen pro Commit in der Region EU-DE aus. Ein Job in der Warteschlange, für dessen Commit keine freie VM bereitsteht, stellt eine neue VM mit eingebautem Docker bereit. Diese VM führt nur Jobs desselben Commits desselben Repositorys aus, einen nach dem anderen, wartet bis zu 60 Sekunden auf einen weiteren, schaltet sich dann ab und wird zerstört. Es gibt keinen dauerhaften Runner-Pool, und keine VM führt jemals Code aus zwei Commits, zwei Repositorys oder von zwei Kunden aus.

Diese Seite dokumentiert die Isolationsgarantien, die fremforge gibt, die Limits pro Mandant und das Bedrohungsmodell: was Kundencode tun kann, was nicht, und welche Entwurfsentscheidungen jemand, der Workflows schreibt, treffen sollte, um die eigenen Secrets zu schützen.

Wo Workflows laufen

Isolationsgarantien

Netzwerkisolation (pro VM)

Jede Runner-VM erhält ein eigenes ENI, das an eine Security Group pro VM gebunden ist. Die SG verweigert standardmäßig jeden Verkehr außer:

• DNS (53/UDP, 53/TCP) zum internen DNS-Resolver der Plattform
• Ausgehendem Verkehr über den Egress-Proxy der Runner, dem einzigen ausgehenden HTTP-Weg

Kundencode kann nicht erreichen:

• die fremforge-API oder ihre private Datenbank
• den internen Endpunkt von Forgejo (Runner-VMs sprechen mit Forgejo über die öffentliche, von Bunny vorgeschaltete Domain mit einem Runner-spezifischen Scope; der interne Endpunkt ist nicht erreichbar)
• Plattformdienste von T Cloud Public (RDS, DCS, OBS, SFS-Turbo, IAM, KMS)
• Runner-VMs anderer Mandanten
• die Metadaten-IP des Clusters (169.254.169.254), ausdrücklich im SSRF-Schutz gesperrt
• private Bereiche nach RFC1918 oder Loopback

Die Security Group wird bei der Bereitstellung der VM angewendet und kann aus der VM heraus nicht geändert werden: Der VM ist keine IAM-Agency zugeordnet, sodass die APIs zur Netzwerkkonfiguration über die aus den Metadaten abgeleitete Identität nicht erreichbar sind.

Ausgehender Verkehr

Workflow-Schritte, die das öffentliche Internet brauchen (ein öffentliches Repository klonen, ein Tool herunterladen, eine SaaS-API aufrufen), laufen über den Egress-Proxy der Runner, per HTTPS_PROXY, das in die VM injiziert wird. Dieser Proxy:

• akzeptiert jede öffentliche Unicast-IP einschließlich Carrier-Grade NAT (entspricht dem Verhalten der von GitHub gehosteten Runner; nötig für Dienste von T Cloud Public selbst wie SWR, die im CGNAT liegen)
• sperrt private Bereiche nach RFC1918, Link-Local, Loopback, Multicast, reservierte Bereiche und ausdrücklich die Cloud-Metadaten-IPs (169.254.169.254, 100.100.100.200 von T Cloud Public)
• protokolliert jeden CONNECT-Tunnelversuch mit Hostnamen und aufgelöster IP für die Aufbewahrung im Audit

Der Proxy ist bewusst großzügig im Sinne der von GitHub gehosteten Runner: Kunden-Workflows können jeden öffentlichen Host erreichen, den sie brauchen. Die Grenze liegt beim SSRF-Schutz und der internen Plattform, nicht bei Allowlists für Anbieter.

Paket-Caches (souverän, in der EU)

Bevor ein Workflow das öffentliche Internet erreicht, werden Paketinstallationen und Image-Pulls über den eigenen Dependency-Proxy deiner Organisation geleitet, der in der EU in derselben Region wie die Runner-VMs liegt. Der gemeinsame Docker-Hub-Mirror und die Paket-Caches im VPC wurden im Oktober 2026 stillgelegt. Der Proxy jeder Organisation wendet ihre eigene Paketrichtlinie, ihre Upstream-Zugangsdaten, ihr Zugriffsprotokoll und ihre Speichergrenze an; eine öffentliche Datei, die mehrere Organisationen laden, wird einmal gespeichert, und Inhalte, die mit den eigenen Zugangsdaten einer Organisation geholt wurden, werden nie an eine andere ausgeliefert. Ist das Runner-Pull-through eingeschaltet (Standard für jede Organisation, die keine eigenen Einstellungen für den Dependency-Proxy gespeichert hat), wird jeder Job beim Start auf den Proxy ausgerichtet:

Der Job authentifiziert sich beim Proxy mit Zugangsdaten, die auf seine eigene Organisation und seinen Lauf beschränkt sind, sodass Paketinstallationen die Paketrichtlinie und die Malware-Prüfungen der Organisation durchlaufen und in ihrem Zugriffsprotokoll erscheinen. Für Container-Images auf diesem Weg ist der Proxy ein Cache, keine Sperre: Ein Pull, den er abweist, geht direkt an die Registry. Der Proxy wird zu Beginn jedes Jobs geprüft; ist er nicht erreichbar, installiert und lädt der Job über den Egress-Proxy aus den öffentlichen Registrys, und dieser Rückfall wird protokolliert. Siehe Gehostete Runner.

Im üblichen Fall (öffentliche Abhängigkeiten) ist das transparent; an deinem Workflow ändert sich nichts.

Wenn du einen privaten Index oder eine private Registry verwendest, beachte, dass der injizierte Wert der Standard ist und daher Vorrang vor einem Standard hat, der in einer committeten Konfigurationsdatei (pip.conf, .npmrc, go env) gesetzt ist. Gib deine private Quelle ausdrücklich an, damit sie gewinnt; wie das für jedes Werkzeug geht, steht unten.

Verwende einen Index pro Installation: den Proxy oder einen privaten Index, der selbst die öffentliche Registry spiegelt. Füge nie einen zweiten Index neben dem ersten hinzu (--extra-index-url, PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL): Der Installer nimmt dann einen Paketnamen von dem Index, der ihn gerade anbietet, und genau so funktionieren Dependency-Confusion-Angriffe. Siehe die PyPI-Hinweise des Dependency-Proxys.

• pip: pip install --index-url <your-private> ... (ein --index-url auf der Kommandozeile übersteuert das injizierte PIP_INDEX_URL) oder setze es im env: des Workflow-Schritts, wenn dieser private Index die öffentlichen Pakete spiegelt, die du brauchst. Um deine eigenen Pakete aus der Registry deiner Organisation zu installieren, während öffentliche über den Proxy kommen, verwende zwei getrennte Installationen mit jeweils einem eigenen Index: zuerst die öffentlichen Abhängigkeiten, dann deine Pakete mit --index-url https://frem.sh/api/packages/<org>/pypi/simple/ --no-deps.
• uv: dieselbe Regel. Binde deine eigenen Pakete per Namen an deine Registry, mit einem Index, der als explicit = true markiert ist, und einem Eintrag in [tool.uv.sources] pro Paket, sodass kein Name aus beiden aufgelöst werden kann.
• npm: Setze NPM_CONFIG_REGISTRY (und bei pnpm 11 PNPM_CONFIG_REGISTRY) im env: des Schritts auf eine Registry, die die öffentliche spiegelt, oder behalte den Proxy und leite nur deinen Scope an deine Registry (@<your-scope>:registry=…), was jeden Namen in diesem Scope an eine Registry bindet. Siehe Paket-Caches.
• Go: Setze GOPRIVATE (z. B. GOPRIVATE=git.example.com/*), damit die Toolchain für deine privaten Modulpfade den Proxy und die Prüfsummen-Datenbank umgeht.

Isolation auf VM-Ebene

Kernel-Isolation zwischen und innerhalb von Mandanten

Das ist die tragende Aussage des Modells der gehosteten Runner. Jede VM ist an einen Commit eines Repositorys gebunden: ein Linux-Gastkernel, der auf dem Hypervisor von T Cloud Public läuft. Sie führt die Jobs dieses Commits nacheinander aus, und die Plattform zerstört sie, wenn sie fertig sind. Ein Job aus einem anderen Commit, einem anderen Repository oder einer anderen Organisation bekommt immer eine andere VM mit einem anderen Kernel.

Jobs, die sich eine VM teilen

Eine VM wird nur für Jobs desselben Commits im selben Repository (und damit derselben Organisation) wiederverwendet: andere Workflows, Läufe oder erneute Läufe dieses Commits oder ein Deploy nach seinem Build. Zwischen diesen Jobs setzt fremforge alles zurück, wovon es weiß, dass es Zugangsdaten enthalten kann: den Job-Container, /workspace und /tmp, den Docker-Login und die npm-Konfiguration sowie die üblichen Dateien mit Zugangsdaten. Lässt sich dieses Zurücksetzen nicht bestätigen, nimmt die VM keinen weiteren Job an, und der nächste Job bekommt eine neue VM.

Das Zurücksetzen ist keine neue VM. Jobs können den Docker-Daemon der VM nutzen, der auf der VM root ist, sodass ein Job etwas für einen späteren Job desselben Commits zurücklassen kann. Mit Zugangsdaten geladene Images, der Tool-Cache und der Go-Build-Cache bleiben ebenfalls auf der VM. Behandle alle Jobs eines Commits als eine Vertrauensdomäne:

• Führe keinen nicht vertrauenswürdigen Code (von Beitragenden gelieferte Fixtures, nicht geprüfte Abhängigkeits-Updates) in der Pipeline desselben Commits aus wie einen Job, der Produktions-Secrets hält.
• Sichere Deploys mit einer Freigabe für die Umgebung ab (siehe Jobs validate und apply trennen) und bevorzuge kurzlebige OIDC-Zugangsdaten gegenüber gespeicherten Schlüsseln.
• Darf ein Deploy nie eine Maschine mit einem Build teilen, führe ihn auf einem eigenen Runner aus.

Limits pro Mandant

Überschreitet ein Mandant das Runner-Minuten-Kontingent und ist keine Mehrnutzung aktiviert (oder ist sie eingefroren), verweigert die Plattform die Zuteilung: Der wartende Job des Workflows wechselt in Forgejo auf Cancelled. Mandanten mit aktivierter Mehrnutzung laufen weiter und bekommen den Überschuss in Rechnung gestellt.

Erreicht ein Mandant die Obergrenze für Gleichzeitigkeit, warten weitere Jobs in der Warteschlange und werden zugeteilt, sobald ein Slot frei wird.

Was Kundencode NICHT tun kann

• Die fremforge-API, den internen Endpunkt von Forgejo oder einen anderen Plattformdienst erreichen (die API ist nur über die öffentliche Bunny-Domain mit ordnungsgemäßer Authentifizierung erreichbar, wie für jeden externen Aufrufer)
• Die Runner-VM eines anderen Mandanten lesen (getrenntes ENI; Verkehr zwischen VMs wird von der Security Group ausdrücklich verweigert)
• Die Secrets eines anderen Mandanten lesen (Workflow-Secrets werden nur an den Runner übergeben, der den Workflow ausführt, dem sie gehören; das Zerstören der VM löscht die Zugangsdaten im Speicher)
• Zustand über den eigenen Commit hinaus erhalten (die VM wird zerstört, sobald die Jobs dieses Commits fertig sind, und keine Platte wird zwischen VMs geteilt)
• Die OTC-API direkt mit privilegiertem Scope erreichen (keine IAM-Agency zugeordnet; die aus den Metadaten abgeleitete Identität hat keine Rollen)
• Cloud-Metadaten-Endpunkte erreichen (169.254.169.254, 100.100.100.200, beide ausdrücklich im SSRF-Schutz verweigert)
• Den Runner-Pool erschöpfen (gleichzeitige Obergrenze pro Mandant + globale Rechenobergrenze der Plattform)
• Andere Mandanten in der Warteschlange aushungern (gleichzeitige Obergrenze pro Mandant)
• Aus dem Hypervisor ausbrechen (die VM ist die Grenze; der Host darunter gehört T Cloud Public und ist durch denselben VMM isoliert, der jeden kommerziellen ECS-Mandanten in der Region trennt)

Empfohlene Workflow-Formen

Jobs validate und apply trennen

Führe nicht vertrauenswürdigen Code (PR-Builds, Abhängigkeits-Scans, von Beitragenden gelieferte Test-Fixtures) in einem Job validate ohne Produktionszugangsdaten aus, und sichere den Job apply mit einer Freigabe für die Umgebung ab. Der Job validate sieht die Secrets des Jobs apply nie. Beide Jobs gehören allerdings zum selben Commit und können daher nacheinander auf derselben VM laufen: siehe Jobs, die sich eine VM teilen.

uses:-Referenzen per SHA festlegen, wenn die Lieferkette zählt

uses: actions/checkout@v4 wird zu frem.sh/actions/checkout aufgelöst (der native Forgejo-Pull-Mirror von fremforge für github.com/actions/checkout, Synchronisation alle 8 Stunden). Der Mirror folgt den Upstream-Tags einschließlich Force-Pushes, daher ist das Festlegen per SHA der einzige Weg, bytegenaue Stabilität zu garantieren:

# Bytewise-stable across maintainer force-pushes
- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5  # v4.2.0

# Picks up upstream's current HEAD at last mirror sync — including
# any maintainer-credential-compromise force-push
- uses: actions/checkout@v4

OIDC für die Cloud-Authentifizierung statt langlebiger Secrets

Jede Runner-VM erhält ein neues OIDC-Token mit aud=fremforge. Konfiguriere die Vertrauensrichtlinie deines Cloud-Anbieters so, dass sie dieses Token akzeptiert und gegen kurzlebige Zugangsdaten tauscht. Speichere keine langlebigen AWS-Access-Keys oder GCP-Service-Account-JSONs in Workflow-Secrets, wo sie in der Prozessumgebung landen.

Fristen für Workflow-Schritte begrenzen

Setze timeout-minutes: für einzelne Schritte, um zu begrenzen, wie lange ein hängender Schritt laufen kann. Die Laufzeitgrenze auf VM-Ebene (activeDeadlineSeconds=3600) ist die Untergrenze der Plattform; Timeouts pro Schritt geben schnellere Rückmeldung.

Bedrohungsmodell im Überblick

Nachvollziehbarkeit

Jede Zuteilung wird an drei Stellen protokolliert:

1. Tabelle runner_jobs: tenant_id, repo, forgejo_task_id, started_at, finished_at, duration_seconds, vm_id. Quelle für die Abrechnungsaggregation und den Tab Infrastructure in der Betreiberkonsole
2. Tabelle metering_events: Zeilen mit code=runner_minute, abgeleitet aus runner_jobs.duration_seconds. Grundlage für die Rechnungspositionen und das Panel „Runner minutes used" des Mandanten
3. Protokollstrom für Betreiber: strukturierte Start-Protokolle für den Betreiber, mit laufender Alarmierung bei verweigerten Zuteilungen, hängenden VMs, überschrittenen Fristen und erschöpfter Kapazität

Mandanten sehen ihre eigene Nutzung unter Organisationsverwaltung → Build und Deployment → CI-Nutzung, einschließlich der Minuten pro Monat und einer Tabelle der Laufzeiten pro Job.