Sikkerhedsmodel for hostede runners

fremforges hostede runners kører kundernes Forgejo Actions-workflows på virtuelle T Cloud Public ECS-maskiner pr. commit i regionen EU-DE. Et job i kø, som ikke har en ledig VM til sit commit, får en ny VM med indbygget Docker. Den VM kører kun jobs fra det samme commit i det samme repository, ét ad gangen, venter op til 60 sekunder på det næste og bliver derefter slukket og destrueret. Der er ingen vedvarende runner-pulje, og ingen VM kører nogensinde kode fra to commits, to repositorier eller to kunder.

Denne side beskriver de isolationsgarantier, fremforge giver, de grænser, der gælder pr. tenant, og trusselsmodellen: hvad kundekode kan, hvad den ikke kan, og hvilke designvalg en workflow-forfatter bør træffe for at holde sine secrets sikre.

Hvor workflows kører

Isolationsgarantier

Netværksisolation (pr. VM)

Hver runner-VM får sit eget ENI bundet til en Security Group pr. VM. Som standard afviser SG’en al trafik undtagen:

• DNS (53/UDP, 53/TCP) til platformens interne DNS-resolver
• Udgående trafik gennem runnernes egress-proxy, den eneste udgående HTTP-vej

Kundekode kan ikke nå:

• fremforges api eller dens private database
• Forgejos interne endpoint (runner-VM’er taler med Forgejo gennem det offentlige apex bag Bunny med et runner-specifikt scope; det interne endpoint kan ikke nås)
• T Cloud Publics platformtjenester (RDS, DCS, OBS, SFS-Turbo, IAM, KMS)
• Andre tenants’ runner-VM’er
• Klyngens metadata-IP (169.254.169.254), som eksplicit blokeres af SSRF-værnet
• Private RFC1918-intervaller eller loopback

Security Group’en anvendes, når VM’en oprettes, og kan ikke ændres indefra VM’en. VM’en har ingen IAM-agency tilknyttet, så API’erne til netværkskonfiguration kan ikke nås gennem den identitet, der udledes fra metadata.

Udgående trafik

Workflow-trin, der skal bruge det offentlige internet (klone et offentligt repo, hente et værktøj, kalde et SaaS-API), går gennem runnernes egress-proxy via HTTPS_PROXY, som sættes ind i VM’en. Proxyen:

• Accepterer enhver offentlig unicast-IP inklusive Carrier-Grade NAT (svarer til GitHub-hostede runners og er nødvendigt for T Cloud Publics egne tjenester som SWR, der ligger i CGNAT)
• Blokerer private RFC1918-adresser, link-local, loopback, multicast, reserverede adresser og eksplicitte cloud-metadata-IP’er (169.254.169.254, T Cloud Publics 100.100.100.200)
• Logger hvert forsøg på en CONNECT-tunnel med værtsnavn og opslået IP til opbevaring i revisionsøjemed

Proxyen er bevidst tilladende på samme måde som GitHub-hostede runners: kundeworkflows kan nå enhver offentlig vært, de har brug for. Grænsen går ved SSRF og den interne platform, ikke ved tilladelseslister over leverandører.

Pakkecacher (suveræne, i EU)

Før et workflow når det offentlige internet, sendes pakkeinstallationer og hentning af images gennem din organisations egen afhængighedsproxy, som ligger i EU i samme region som runner-VM’erne. Det fælles Docker Hub-spejl og pakkecacherne i VPC’en blev udfaset i oktober 2026. Hver organisations proxy anvender sin egen pakkepolitik, sine egne legitimationsoplysninger opstrøms, sin egen adgangslog og sit eget lagerloft. En offentlig fil, som flere organisationer henter, gemmes én gang, og indhold hentet med en organisations egne legitimationsoplysninger serveres aldrig for en anden. Når pull-through for runners er slået til (standard for alle organisationer, der ikke har gemt deres egne indstillinger for afhængighedsproxyen), peges hvert job mod proxyen, når det starter:

Jobbet godkendes over for proxyen med legitimationsoplysninger, der er afgrænset til dets egen organisation og kørsel, så pakkeinstallationer går gennem organisationens pakkepolitik og malwaretjek og vises i dens adgangslog. For container-images på denne vej er proxyen en cache, ikke en gate: en hentning, den afviser, går videre til registryet. Proxyen tjekkes i starten af hvert job. Kan den ikke nås, installerer og henter jobbet fra de offentlige registries gennem egress-proxyen, og reserveløsningen logges. Se Hostede runners.

I det almindelige tilfælde (offentlige afhængigheder) er det gennemsigtigt, så intet i dit workflow ændres.

Bruger du et privat indeks eller registry, så bemærk, at den indsatte værdi er standarden, og derfor går den forud for en standard, der er sat i en committet konfigurationsfil (pip.conf, .npmrc, go env). Peg eksplicit på din private kilde, så den vinder; hvordan du gør det for hvert værktøj, står nedenfor.

Brug ét indeks pr. installation: proxyen eller ét privat indeks, der selv spejler det offentlige registry. Tilføj aldrig et andet indeks ved siden af det første (--extra-index-url, PIP_EXTRA_INDEX_URL, UV_EXTRA_INDEX_URL): installationsværktøjet tager så et pakkenavn fra det indeks, der tilbyder det, og det er sådan, dependency confusion-angreb virker. Se afhængighedsproxyens noter om PyPI.

• pip: pip install --index-url <your-private> ... (et --index-url på kommandolinjen tilsidesætter den indsatte PIP_INDEX_URL), eller sæt den i workflow-trinnets env:, når det private indeks spejler de offentlige pakker, du har brug for. Vil du installere dine egne pakker fra din organisations registry, mens de offentlige kommer gennem proxyen, så brug to separate installationer med hvert sit ene indeks: først de offentlige afhængigheder, derefter dine pakker med --index-url https://frem.sh/api/packages/<org>/pypi/simple/ --no-deps.
• uv: samme regel. Fastlås dine egne pakker til dit registry ved navn, med et indeks markeret explicit = true og en [tool.uv.sources]-linje pr. pakke, så intet navn kan slås op i begge.
• npm: sæt NPM_CONFIG_REGISTRY (og, for pnpm 11, PNPM_CONFIG_REGISTRY) i trinnets env: til ét registry, der spejler det offentlige, eller behold proxyen og send kun dit scope til dit registry (@<your-scope>:registry=…), hvilket fastlåser hvert navn i det scope til ét registry. Se Pakkecacher.
• Go: sæt GOPRIVATE (fx GOPRIVATE=git.example.com/*), så toolchainen går uden om proxyen og checksum-databasen for dine private modulstier.

Isolation på VM-niveau

Kerneisolation mellem og inden for tenants

Dette er det bærende løfte i modellen for hostede runners. Hver VM er bundet til ét commit i ét repository: en Linux-gæstekerne, der kører på T Cloud Publics hypervisor. Den kører commit’ets jobs ét ad gangen, og platformen destruerer den, når de er færdige. Et job fra et andet commit, et andet repository eller en anden organisation får altid en anden VM med en anden kerne.

Jobs, der deler en VM

En VM genbruges kun til jobs fra samme commit i samme repository (og dermed samme organisation): andre workflows, kørsler eller genkørsler af det commit, eller en udrulning efter dets build. Mellem de jobs nulstiller fremforge alt, hvad den ved kan indeholde en legitimationsoplysning: jobcontaineren, /workspace og /tmp, Docker-login og npm-konfiguration og de sædvanlige filer med legitimationsoplysninger. Kan nulstillingen ikke bekræftes, tager VM’en ikke flere jobs, og det næste job får en ny VM.

Nulstillingen er ikke det samme som en ny VM. Jobs kan bruge VM’ens Docker-dæmon, som er root på VM’en, så et job kan efterlade noget til et senere job fra samme commit. Images hentet med legitimationsoplysninger, værktøjscachen og Go-buildcachen bliver også på VM’en. Behandl alle jobs fra ét commit som ét tillidsdomæne:

• Kør ikke kode, du ikke stoler på (testdata fra bidragydere, afhængighedsopdateringer, der ikke er reviewet), i samme commits pipeline som et job, der har produktions-secrets.
• Beskyt udrulninger med en godkendelse på miljøet (se Opdel jobs i validate og apply), og foretræk kortlivede OIDC-legitimationsoplysninger frem for gemte nøgler.
• Hvis en udrulning aldrig må dele maskine med et build, så kør den på en BYO-runner.

Grænser pr. tenant

Når en tenant overskrider puljen af runner-minutter, og merforbrug ikke er slået til (eller er frosset), afviser platformen at sende jobbet ud: workflowets job i kø skifter til Cancelled i Forgejo. Tenants med merforbrug slået til kører videre og faktureres for det ekstra.

Når en tenant rammer loftet for samtidige jobs, venter yderligere jobs i kø og sendes ud, så snart et job-slot bliver ledigt.

Hvad kundekode IKKE kan

• Nå fremforges api, Forgejos interne endpoint eller nogen anden platformtjeneste (api’et er kun tilgængeligt gennem det offentlige Bunny-apex med korrekt godkendelse, ligesom for enhver ekstern kalder)
• Læse en anden tenants runner-VM (separat ENI; trafik mellem VM’er afvises eksplicit af Security Group’en)
• Læse en anden tenants secrets (workflow-secrets sendes kun til den runner, der kører det workflow, de tilhører; når VM’en destrueres, slettes legitimationsoplysningerne i hukommelsen)
• Bevare tilstand ud over sit eget commit (VM’en destrueres, når commit’ets jobs er færdige, og ingen disk deles mellem VM’er)
• Nå OTC-API’et direkte med privilegeret scope (ingen IAM-agency tilknyttet; identiteten fra metadata har ingen roller)
• Nå cloud-metadata-endpoints (169.254.169.254, 100.100.100.200, begge afvist eksplicit af SSRF-værnet)
• Opbruge runner-puljen (loft for samtidige jobs pr. tenant og platformens samlede beregningsloft)
• Udsulte køen for andre tenants (loft for samtidige jobs pr. tenant)
• Bryde ud af hypervisoren (VM’en er grænsen; værten under den tilhører T Cloud Public og er isoleret af den samme VMM, der adskiller alle kommercielle ECS-tenants i regionen)

Anbefalede workflow-strukturer

Opdel jobs i validate og apply

Kør kode, du ikke stoler på (PR-builds, afhængighedsscanninger, testdata fra bidragydere), i et validate-job uden produktionslegitimationsoplysninger, og beskyt apply-jobbet med en godkendelse på miljøet. Validate-jobbet ser aldrig apply-jobbets secrets. Begge jobs hører dog til samme commit, så de kan køre på samme VM efter hinanden: se Jobs, der deler en VM.

Fastlås uses:-referencer med SHA, når forsyningskæden betyder noget

uses: actions/checkout@v4 slås op som frem.sh/actions/checkout (fremforges native Forgejo pull-spejl af github.com/actions/checkout, synkroniseret hver 8. time). Spejlet følger tags opstrøms, inklusive force-pushes, så at fastlåse med SHA er den eneste måde at 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

Brug OIDC til cloud-godkendelse, ikke langlivede secrets

Hver runner-VM får et nyt OIDC-token med aud=fremforge. Konfigurér din cloududbyders tillidspolitik til at acceptere dette token og bytte det til kortlivede legitimationsoplysninger. Undgå at gemme langlivede AWS-adgangsnøgler eller JSON-filer til GCP-servicekonti i workflow-secrets, hvor de ender i processens miljø.

Sæt frister på workflow-trin

Sæt timeout-minutes: på de enkelte trin for at begrænse, hvor længe et trin, der hænger, kan køre. Loftet for vægurstid på VM-niveau (activeDeadlineSeconds=3600) er platformens bund; timeouts på trinniveau giver hurtigere feedback.

Overblik over trusselsmodellen

Sporbarhed

Hver udsendelse af et job logges tre steder:

1. Tabellen runner_jobs: tenant_id, repo, forgejo_task_id, started_at, finished_at, duration_seconds, vm_id. Kilde til aggregering af fakturering og fanen Infrastructure i operatørkonsollen
2. Tabellen metering_events: rækker med code=runner_minute udledt af runner_jobs.duration_seconds. Driver fakturalinjerne og tenantens panel “Runner minutes used”
3. Operatørens logstrøm: strukturerede logs over oprettelser til operatøren, med løbende alarmer ved afviste udsendelser, VM’er, der sidder fast, overskredne frister og opbrugt kapacitet

Tenants ser deres eget forbrug under Administration → Byg og udrul → CI-forbrug, inklusive et antal minutter pr. måned og en tabel med varighed pr. job.