Sikkerhetsmodellen for hostede runnere

fremforges hostede runnere kjører kundenes Forgejo Actions-workflower på virtuelle ECS-maskiner i T Cloud Public, én per commit, i regionen EU-DE. En jobb i kø som ikke har en ledig VM for sin commit, klargjør en ny VM med innebygd Docker. Den VM-en kjører bare jobber fra den samme commiten i det samme repositoryet, én om gangen, venter i opptil 60 sekunder på en ny jobb og slås deretter av og slettes. Det finnes ingen varig runner-pool, og ingen VM kjører noen gang kode fra to commits, to repositoryer eller to kunder.

Denne siden beskriver isolasjonsgarantiene fremforge gir, grensene som gjelder per tenant, og trusselmodellen: hva kundekode kan gjøre, hva den ikke kan gjøre, og hvilke designvalg en workflow-forfatter bør ta for å holde secrets trygge.

Hvor workflower kjører

Isolasjonsgarantier

Nettverksisolasjon (per VM)

Hver runner-VM får sitt eget ENI, knyttet til en Security Group per VM. Som standard avviser SG-en all trafikk unntatt:

• DNS (53/UDP, 53/TCP) til plattformens interne DNS-resolver
• Utgående trafikk gjennom runnernes utgående proxy – den eneste utgående HTTP-veien

Kundekode kan ikke nå:

• fremforge-API-et eller den private databasen bak det
• Forgejos interne endepunkt (runner-VM-er snakker med Forgejo gjennom det offentlige apex-domenet bak Bunny med et runner-spesifikt scope; det interne endepunktet kan ikke nås)
• Plattformtjenester i T Cloud Public (RDS, DCS, OBS, SFS-Turbo, IAM, KMS)
• Andre tenanters runner-VM-er
• Klyngens metadata-IP (169.254.169.254) – eksplisitt blokkert i SSRF-vernet
• Private RFC1918-områder eller loopback

Security Group-en settes når VM-en klargjøres, og kan ikke endres fra innsiden av VM-en – VM-en har ingen IAM-agency knyttet til seg, så API-ene for nettverkskonfigurasjon kan ikke nås med identiteten fra metadatatjenesten.

Utgående trafikk

Workflow-steg som trenger det offentlige internett (klone et offentlig repo, laste ned et verktøy, kalle et SaaS-API), går gjennom runnernes utgående proxy via HTTPS_PROXY, som settes inn i VM-en. Denne proxyen:

• Godtar alle offentlige unicast-IP-er, inkludert Carrier-Grade NAT (samme oppførsel som GitHub-hostede runnere – nødvendig for T Cloud Publics egne tjenester som SWR, som ligger i CGNAT)
• Blokkerer private RFC1918-adresser, link-local, loopback, multicast, reserverte adresser og eksplisitte metadata-IP-er for skyen (169.254.169.254, T Cloud Publics 100.100.100.200)
• Logger hvert forsøk på CONNECT-tunnel med vertsnavn og oppslått IP for revisjonsoppbevaring

Proxyen er bevisst romslig i samme forstand som GitHub-hostede runnere: kundeworkflower kan nå alle offentlige verter de trenger. Grensen går ved SSRF og den interne plattformen, ikke ved tillatelseslister for leverandører.

Pakkebuffere (suverene, i EU)

Før en workflow når det offentlige internett, går pakkeinstallasjoner og pull av imager gjennom organisasjonens egen avhengighetsproxy, som ligger i EU i den samme regionen som runner-VM-ene. Det delte Docker Hub-speilet og pakkebufferne i VPC-en ble avviklet i oktober 2026. Hver organisasjons proxy bruker sin egen pakkepolicy, egne upstream-legitimasjoner, egen tilgangslogg og egen lagringsgrense; en offentlig fil som flere organisasjoner puller, lagres én gang, og innhold som er hentet med en organisasjons egne legitimasjoner, leveres aldri til en annen. Med pull-through for runnere slått på (standard for alle organisasjoner som ikke har lagret egne innstillinger for avhengighetsproxyen), pekes hver jobb mot proxyen når den starter:

Jobben autentiserer seg mot proxyen med legitimasjon som er avgrenset til sin egen organisasjon og kjøring, så pakkeinstallasjoner går gjennom organisasjonens pakkepolicy og skadevaresjekker og vises i tilgangsloggen. For containerimager på denne veien er proxyen en buffer, ikke en sperre: en pull som den avviser, faller gjennom til registeret. Proxyen sjekkes ved starten av hver jobb; hvis den ikke kan nås, installerer og puller jobben fra de offentlige registrene gjennom den utgående proxyen, og reserveløsningen logges. Se Hosted runners.

I det vanlige tilfellet (offentlige avhengigheter) er dette usynlig, så ingenting i workflowen din endres.

Hvis du bruker en privat indeks eller et privat register, er verdien som settes inn, standardverdien, så den går foran en standard som er satt i en committet konfigurasjonsfil (pip.conf, .npmrc, go env). Pek eksplisitt på den private kilden din, slik at den vinner; hvordan du gjør det for hvert verktøy, står nedenfor.

Bruk én indeks per installasjon: proxyen, eller én privat indeks som selv speiler det offentlige registeret. Legg aldri til en ekstra indeks ved siden av den første (--extra-index-url, PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL): installasjonsverktøyet tar da et pakkenavn fra hvilken som helst indeks som tilbyr det, og det er slik angrep med avhengighetsforvirring virker. Se avhengighetsproxyens merknader om PyPI.

• pip: pip install --index-url <your-private> ... (en --index-url på kommandolinjen overstyrer PIP_INDEX_URL som er satt inn), eller sett den i env: for workflow-steget, når den private indeksen speiler de offentlige pakkene du trenger. For å installere dine egne pakker fra organisasjonens register mens de offentlige kommer gjennom proxyen, bruker du to separate installasjoner, hver med sin ene indeks: offentlige avhengigheter først, deretter pakkene dine med --index-url https://frem.sh/api/packages/<org>/pypi/simple/ --no-deps.
• uv: samme regel. Fest dine egne pakker til registeret ditt etter navn, med en indeks merket explicit = true og en [tool.uv.sources]-oppføring per pakke, slik at ingen navn kan løses fra begge.
• npm: sett NPM_CONFIG_REGISTRY (og, for pnpm 11, PNPM_CONFIG_REGISTRY) i stegets env: til ett register som speiler det offentlige, eller behold proxyen og send bare ditt eget scope til registeret ditt (@<your-scope>:registry=…), som fester hvert navn i det scopet til ett register. Se Pakkebuffere.
• Go: sett GOPRIVATE (f.eks. GOPRIVATE=git.example.com/*) slik at verktøykjeden går utenom proxyen og sjekksumdatabasen for de private modulstiene dine.

Isolasjon på VM-nivå

Kjerneisolasjon mellom og innenfor tenanter

Dette er den bærende påstanden i modellen for hostede runnere. Hver VM er bundet til én commit i ett repository – en gjeste-Linux-kjerne som kjører på T Cloud Publics hypervisor. Den kjører jobbene for den commiten én om gangen, og plattformen sletter den når de er ferdige. En jobb fra en annen commit, et annet repository eller en annen organisasjon får alltid en annen VM med en annen kjerne.

Jobber som deler en VM

En VM brukes på nytt bare for jobber fra den samme commiten i det samme repositoryet (og dermed den samme organisasjonen): andre workflower, kjøringer eller nye kjøringer av den commiten, eller en utrulling etter byggingen. Mellom disse jobbene nullstiller fremforge alt den vet kan inneholde legitimasjon: jobbcontaineren, /workspace og /tmp, Docker-innloggingen og npm-konfigurasjonen, og de vanlige legitimasjonsfilene. Hvis nullstillingen ikke kan bekreftes, tar VM-en ikke flere jobber, og neste jobb får en ny VM.

Nullstillingen er ikke en ny VM. Jobber kan bruke VM-ens Docker-daemon, som er root på VM-en, så en jobb kan legge igjen noe til en senere jobb fra den samme commiten. Imager som er pullet med legitimasjon, verktøybufferen og Go-byggebufferen blir også liggende på VM-en. Behandle alle jobber fra én commit som ett tillitsdomene:

• Ikke kjør kode du ikke stoler på (testdata fra bidragsytere, ikke-gjennomgåtte avhengighetsoppdateringer) i den samme commitens pipeline som en jobb som har produksjons-secrets.
• Sett utrullinger bak en miljøgodkjenning (se Del opp validate- og apply-jobber), og foretrekk kortlivede OIDC-legitimasjoner fremfor lagrede nøkler.
• Hvis en utrulling aldri må dele maskin med et bygg, kjører du den på en egen runner (BYO).

Grenser per tenant

Når en tenant overskrider potten med runner-minutter og overforbruk ikke er slått på (eller er fryst), avviser plattformen utsendelsen: jobben i kø går over til Cancelled i Forgejo. Tenanter med overforbruk slått på fortsetter å kjøre og faktureres for det som overskrides.

Når en tenant når taket for samtidighet, venter flere jobber i kø og sendes ut så snart en jobbenhet blir ledig.

Hva kundekode IKKE kan gjøre

• Nå fremforge-API-et, Forgejos interne endepunkt eller noen annen plattformtjeneste (API-et er bare tilgjengelig gjennom det offentlige Bunny-apex-domenet med riktig autentisering, akkurat som for enhver ekstern klient)
• Lese en annen tenants runner-VM (separat ENI; trafikk mellom VM-er eksplisitt avvist i Security Group-en)
• Lese en annen tenants secrets (workflow-secrets sendes bare til runneren som kjører workflowen som eier dem; når VM-en slettes, forsvinner legitimasjonene i minnet)
• Beholde tilstand utover sin egen commit (VM-en slettes når jobbene for den commiten er ferdige, og ingen disk deles mellom VM-er)
• Nå OTC-API-et direkte med privilegert scope (ingen IAM-agency knyttet til; identiteten fra metadatatjenesten har ingen roller)
• Nå metadata-endepunktene i skyen (169.254.169.254, 100.100.100.200 – begge eksplisitt avvist i SSRF-vernet)
• Bruke opp runner-poolen (tak for samtidighet per tenant pluss plattformens samlede beregningstak)
• Sulte ut køen for andre tenanter (tak for samtidighet per tenant)
• Bryte ut av hypervisoren (VM-en er grensen; verten under den tilhører T Cloud Public og er isolert av den samme VMM-en som skiller alle kommersielle ECS-tenanter i regionen)

Anbefalte workflow-former

Del opp validate- og apply-jobber

Kjør kode du ikke stoler på (PR-bygg, avhengighetsskanninger, testdata fra bidragsytere) i en validate-jobb uten produksjonslegitimasjon, og sett apply-jobben bak en miljøgodkjenning. Validate-jobben ser aldri secrets til apply-jobben. Begge jobbene hører likevel til den samme commiten, så de kan kjøre på den samme VM-en etter hverandre: se Jobber som deler en VM.

Fest uses:-referanser med SHA når forsyningskjeden er viktig

uses: actions/checkout@v4 løses til frem.sh/actions/checkout (fremforges innebygde Forgejo-pull-speil av github.com/actions/checkout, synkronisert hver 8. time). Speilet følger upstream-tagger, inkludert force-pusher, så å feste med SHA er den eneste måten å garantere byte-for-byte-stabilitet på:

# 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

Bruk OIDC for autentisering mot skyen, ikke langlivede secrets

Hver runner-VM får et nytt OIDC-token med aud=fremforge. Konfigurer tillitspolicyen hos skyleverandøren din til å godta dette tokenet og bytte det mot kortlivede legitimasjoner. Unngå å lagre langlivede AWS-tilgangsnøkler eller JSON-filer for GCP-tjenestekontoer i workflow-secrets, der de havner i prosessmiljøet.

Sett frister for workflow-steg

Sett timeout-minutes: på enkeltsteg for å begrense hvor lenge et steg som henger, kan kjøre. Taket for veggklokketid på VM-nivå (activeDeadlineSeconds=3600) er plattformens gulv; tidsavbrudd per steg gir raskere tilbakemelding.

Sammendrag av trusselmodellen

Sporbarhet

Hver utsendelse logges tre steder:

1. Tabellen runner_jobs – tenant_id, repo, forgejo_task_id, started_at, finished_at, duration_seconds, vm_id. Kilde for faktureringsaggregering og Infrastructure-fanen i operatørkonsollen
2. Tabellen metering_events – rader med code=runner_minute utledet fra runner_jobs.duration_seconds. Styrer fakturalinjene og tenantens panel «Runner minutes used»
3. Operatørens loggstrøm – strukturerte oppstartslogger for operatøren, med løpende varsling om avviste utsendelser, VM-er som henger, overskredne frister og oppbrukt kapasitet

Tenanter ser sitt eget forbruk under Organisasjonsadministrasjon → Bygg og utrulling → CI-forbruk, med antall minutter per måned og en tabell over varighet per jobb.