Beveiligingsmodel van de gehoste runners

De gehoste runners van fremforge voeren de Forgejo Actions-workflows van klanten uit op virtuele ECS-machines van T Cloud Public, één per commit, in de regio EU-DE. Een job in de wachtrij waarvoor geen vrije VM van zijn commit bestaat, krijgt een nieuwe VM met ingebouwde Docker. Die VM draait alleen jobs van dezelfde commit in dezelfde repository, één tegelijk, wacht maximaal 60 seconden op een volgende job, en wordt dan uitgeschakeld en vernietigd. Er is geen permanente runnerpool, en geen enkele VM draait ooit code van twee commits, twee repository’s of twee klanten.

Deze pagina beschrijft de isolatiegaranties die fremforge geeft, de limieten die per tenant gelden en het dreigingsmodel: wat klantcode kan, wat ze niet kan, en welke ontwerpkeuzes een workflowauteur maakt om zijn secrets veilig te houden.

Waar workflows draaien

Isolatiegaranties

Netwerkisolatie (per VM)

Elke runner-VM krijgt een eigen ENI, gekoppeld aan een Security Group per VM. De SG weigert standaard al het verkeer, behalve:

• DNS (53/UDP, 53/TCP) naar de interne DNS-resolver van het platform
• Uitgaand verkeer via de egressproxy voor runners: de enige uitgaande HTTP-route

Klantcode kan niet bij:

• De fremforge-API of de bijbehorende privédatabase
• Het interne endpoint van Forgejo (runner-VM’s praten met Forgejo via het publieke apexdomein achter Bunny, met een scope die specifiek is voor runners; het interne endpoint is onbereikbaar)
• Platformdiensten van T Cloud Public (RDS, DCS, OBS, SFS-Turbo, IAM, KMS)
• Runner-VM’s van andere tenants
• Het metadata-IP van het cluster (169.254.169.254), dat in de SSRF-guard expliciet wordt geblokkeerd
• Private RFC1918-bereiken of loopback

De Security Group wordt bij het aanmaken van de VM toegepast en kan vanuit de VM niet worden gewijzigd: aan de VM hangt geen IAM-agency, dus de API’s voor netwerkconfiguratie zijn via de identiteit uit de metadata onbereikbaar.

Uitgaand verkeer

Workflowstappen die het publieke internet nodig hebben (een publieke repo klonen, een tool downloaden, een SaaS-API aanroepen) gaan via de egressproxy voor runners, via een HTTPS_PROXY die in de VM wordt geïnjecteerd. Deze proxy:

• Accepteert elk publiek unicast-IP, inclusief Carrier-Grade NAT (net als de gehoste runners van GitHub; nodig voor diensten van T Cloud Public zelf, zoals SWR, die in CGNAT zitten)
• Blokkeert private RFC1918-adressen, link-local, loopback, multicast, gereserveerde adressen en expliciete cloud-metadata-IP’s (169.254.169.254, 100.100.100.200 van T Cloud Public)
• Logt elke poging tot een CONNECT-tunnel met hostnaam en opgelost IP, zodat die voor audit bewaard blijft

De proxy is bewust ruim in de zin van de gehoste runners van GitHub: klantworkflows bereiken elke publieke host die ze nodig hebben. De grens ligt bij SSRF en het interne platform, niet bij allowlists van leveranciers.

Pakketcaches (soeverein, in de EU)

Voordat een workflow het publieke internet bereikt, gaan pakketinstallaties en image-pulls via de eigen dependency proxy van je organisatie, die in de EU staat, in dezelfde regio als de runner-VM’s. De gedeelde Docker Hub-mirror en de pakketcaches binnen de VPC zijn in oktober 2026 uitgefaseerd. De proxy van elke organisatie past een eigen pakketbeleid, eigen upstream-inloggegevens, een eigen toegangslog en een eigen opslaglimiet toe; een publiek bestand dat meerdere organisaties ophalen, wordt één keer opgeslagen, en inhoud die met de eigen inloggegevens van een organisatie is opgehaald, wordt nooit aan een andere organisatie geleverd. Met runner pull-through aan (de standaard voor elke organisatie die geen eigen instellingen voor de dependency proxy heeft opgeslagen) wordt elke job bij de start naar de proxy verwezen:

De job authenticeert bij de proxy met inloggegevens die beperkt zijn tot zijn eigen organisatie en run, zodat pakketinstallaties door het pakketbeleid en de malwarecontroles van de organisatie gaan en in haar toegangslog verschijnen. Voor containerimages op deze route is de proxy een cache, geen poort: een pull die de proxy weigert, valt terug op de registry. De proxy wordt aan het begin van elke job gecontroleerd; is hij niet bereikbaar, dan installeert en pullt de job via de egressproxy van de publieke registry’s, en wordt die terugval gelogd. Zie Gehoste runners.

In het gangbare geval (publieke afhankelijkheden) merk je hier niets van, dus in je workflow verandert niets.

Gebruik je een private index of registry, let dan op: de geïnjecteerde waarde is de standaard, dus die gaat vóór een standaard uit een gecommit configuratiebestand (pip.conf, .npmrc, go env). Verwijs expliciet naar je private bron, zodat die wint; hoe je dat per tool doet, staat hieronder.

Gebruik één index per installatie: de proxy, of één private index die zelf de publieke registry spiegelt. Voeg nooit een tweede index naast de eerste toe (--extra-index-url, PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL): de installer neemt een pakketnaam dan van de index die hem aanbiedt, en zo werken dependency-confusion-aanvallen. Zie de PyPI-opmerkingen bij de dependency proxy.

• pip: pip install --index-url <your-private> ... (een --index-url op de opdrachtregel gaat vóór de geïnjecteerde PIP_INDEX_URL), of stel hem in onder env: van de workflowstap, als die private index de publieke pakketten spiegelt die je nodig hebt. Wil je je eigen pakketten uit de registry van je organisatie installeren terwijl publieke pakketten via de proxy komen, gebruik dan twee aparte installaties, elk met één eigen index: eerst de publieke afhankelijkheden, daarna je eigen pakketten met --index-url https://frem.sh/api/packages/<org>/pypi/simple/ --no-deps.
• uv: dezelfde regel. Pin je eigen pakketten op naam aan je registry, met een index die als explicit = true is gemarkeerd en een [tool.uv.sources]-regel per pakket, zodat geen enkele naam uit beide kan worden opgelost.
• npm: stel NPM_CONFIG_REGISTRY (en voor pnpm 11 ook PNPM_CONFIG_REGISTRY) in onder env: van de stap, naar één registry die de publieke spiegelt, of houd de proxy en stuur alleen je scope naar je registry (@<your-scope>:registry=…), waarmee elke naam in die scope aan één registry wordt vastgepind. Zie Pakketcaches.
• Go: stel GOPRIVATE in (bijv. GOPRIVATE=git.example.com/*), zodat de toolchain de proxy en de checksumdatabase overslaat voor je private modulepaden.

Isolatie op VM-niveau

Kernelisolatie tussen en binnen tenants

Dit is de dragende bewering van het model van de gehoste runners. Elke VM hoort bij één commit van één repository: een Linux-gastkernel op de hypervisor van T Cloud Public. Hij draait de jobs van die commit één voor één, en het platform vernietigt hem zodra ze klaar zijn. Een job van een andere commit, een andere repository of een andere organisatie krijgt altijd een andere VM met een andere kernel.

Jobs die een VM delen

Een VM wordt alleen hergebruikt voor jobs van dezelfde commit in dezelfde repository (en dus dezelfde organisatie): andere workflows, runs of nieuwe runs van die commit, of een deploy na de build ervan. Tussen die jobs zet fremforge alles terug waarvan bekend is dat het een inloggegeven kan bevatten: de jobcontainer, /workspace en /tmp, de Docker-login en de npm-configuratie, en de gebruikelijke bestanden met inloggegevens. Kan die reset niet worden bevestigd, dan neemt de VM geen job meer aan en krijgt de volgende job een nieuwe VM.

De reset is geen nieuwe VM. Jobs kunnen de Docker-daemon van de VM gebruiken, die root is op de VM, dus een job kan iets achterlaten voor een latere job van dezelfde commit. Images die met inloggegevens zijn gepulld, de toolcache en de Go-buildcache blijven ook op de VM staan. Behandel alle jobs van één commit als één vertrouwensdomein:

• Draai geen onvertrouwde code (fixtures van bijdragers, niet-gereviewde updates van afhankelijkheden) in de pipeline van dezelfde commit als een job die productiesecrets heeft.
• Zet deploys achter een goedkeuring van een omgeving (zie Splits jobs voor validate en apply), en kies liever kortlevende OIDC-inloggegevens dan opgeslagen sleutels.
• Mag een deploy nooit een machine delen met een build, draai hem dan op een eigen runner (BYO).

Limieten per tenant

Overschrijdt een tenant de pool van runnerminuten en is overschrijding niet ingeschakeld (of bevroren), dan weigert het platform het toewijzen: de job in de wachtrij gaat in Forgejo naar Cancelled. Tenants met ingeschakelde overschrijding blijven draaien en krijgen het meerverbruik gefactureerd.

Bereikt een tenant de limiet voor gelijktijdige jobs, dan wachten de extra jobs in de wachtrij en worden ze toegewezen zodra er een slot vrijkomt.

Wat klantcode NIET kan

• De fremforge-API, het interne endpoint van Forgejo of een andere platformdienst bereiken (de API is alleen beschikbaar via het publieke Bunny-apexdomein met de juiste authenticatie, net als voor elke externe aanroeper)
• De runner-VM van een andere tenant lezen (aparte ENI; verkeer tussen VM’s expliciet geweigerd in de Security Group)
• De secrets van een andere tenant lezen (workflowsecrets gaan alleen naar de runner die de workflow draait waar ze bij horen; het vernietigen van de VM wist de inloggegevens in het geheugen)
• Status bewaren voorbij de eigen commit (de VM wordt vernietigd zodra de jobs van die commit klaar zijn, en er wordt geen schijf tussen VM’s gedeeld)
• De OTC-API rechtstreeks bereiken met bevoorrechte scope (geen IAM-agency gekoppeld; de identiteit uit de metadata heeft geen rollen)
• Cloud-metadata-endpoints bereiken (169.254.169.254, 100.100.100.200: beide expliciet geweigerd in de SSRF-guard)
• De runnerpool uitputten (limiet voor gelijktijdige jobs per tenant plus het globale rekenplafond van het platform)
• Wachtrijen van andere tenants laten verhongeren (limiet voor gelijktijdige jobs per tenant)
• Uit de hypervisor ontsnappen (de VM is de grens; de host eronder is van T Cloud Public, geïsoleerd door dezelfde VMM die elke commerciële ECS-tenant in de regio scheidt)

Aanbevolen vormen voor workflows

Splits jobs voor validate en apply

Draai onvertrouwde code (PR-builds, scans van afhankelijkheden, testfixtures van bijdragers) in een validate-job zonder productie-inloggegevens, en zet de apply-job achter een goedkeuring van een omgeving. De validate-job ziet de secrets van de apply-job nooit. Beide jobs horen wel bij dezelfde commit, dus ze kunnen na elkaar op dezelfde VM draaien: zie Jobs die een VM delen.

Pin uses:-verwijzingen op SHA als de supply chain ertoe doet

uses: actions/checkout@v4 verwijst naar frem.sh/actions/checkout (de native Forgejo-pull-mirror van fremforge voor github.com/actions/checkout, gesynchroniseerd elke 8 uur). De mirror volgt upstream-tags, inclusief force-pushes, dus pinnen op SHA is de enige manier om byte-voor-byte stabiliteit te garanderen:

# 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

Gebruik OIDC voor cloudauthenticatie, geen langlevende secrets

Elke runner-VM krijgt een nieuw OIDC-token met aud=fremforge. Stel de trust policy van je cloudprovider zo in dat die dit token accepteert en inruilt voor kortlevende inloggegevens. Sla geen langlevende AWS-toegangssleutels of JSON-bestanden van GCP-serviceaccounts op in workflowsecrets, waar ze in de procesomgeving terechtkomen.

Begrens de deadlines van workflowstappen

Stel timeout-minutes: in op afzonderlijke stappen om te begrenzen hoe lang een vastgelopen stap kan draaien. De maximale looptijd op VM-niveau (activeDeadlineSeconds=3600) is de ondergrens van het platform; time-outs per stap geven sneller feedback.

Samenvatting van het dreigingsmodel

Controleerbaarheid

Elke toewijzing wordt op drie plekken gelogd:

1. Tabel runner_jobs: tenant_id, repo, forgejo_task_id, started_at, finished_at, duration_seconds, vm_id. Bron voor de facturatie-aggregatie en het tabblad Infrastructuur in de operatorconsole
2. Tabel metering_events: rijen met code=runner_minute, afgeleid van runner_jobs.duration_seconds. Voedt de factuurregels en het paneel “Runner minutes used” van de tenant
3. Logstroom van de operator: gestructureerde startlogs voor de operator, met doorlopende alerting op geweigerde toewijzingen, vastgelopen VM’s, overschreden deadlines en uitgeputte capaciteit

Tenants zien hun eigen gebruik onder Organisatiebeheer → Bouwen en uitrollen → CI-gebruik, met een minutentelling per maand en een tabel met de duur per job.