OIDC-tokenføderation

Hvert CI-job i fremforge kan få et kortlivet OIDC-token: en RS256-signeret JWT, udstedt af fremforges runner-OIDC-issuer. Cloududbydere (T Cloud Public, AWS, Azure, GCP) kan sættes op til at stole på tokenet og veksle det til afgrænsede, tidsbegrænsede legitimationsoplysninger. Ingen deploy-nøgler gemt som secrets, og intet, der skal roteres efter en tidsplan.

Oversigt over claims

fremforges runner-JWT indeholder følgende claims:

Claim	Værdi/format	Eksempel
`iss`	`https://frem.sh/_app/runner/oidc` (én global issuer for alle tenants)	`https://frem.sh/_app/runner/oidc`
`sub`	`repo:<org>/<repo>:ref:refs/heads/<branch>`	`repo:acme/api:ref:refs/heads/main`
`aud`	Kan konfigureres; standard er `https://frem.sh`	`https://frem.sh`
`repository_owner`	Organisationens slug – lås betingelserne i din trust policy på dette claim for at isolere hver tenant under den fælles issuer	`acme`
`repository`	`<org>/<repo>`	`acme/api`
`ref`	Fuld git-ref	`refs/heads/main`
`sha`	Commit-SHA	`a1b2c3d4...`
`environment`	Navnet på deployment-miljøet (hvis jobbet angiver et)	`production`
`job_workflow_ref`	Workflow-filens sti og ref	`acme/api/.forgejo/workflows/deploy.yaml@refs/heads/main`
`deployer_group`	(Kun T Cloud Public) navnet på den IAM-gruppe, den føderede bruger skal bindes til, sat pr. workload af fremforge – se T Cloud Public-agency-tillid	`acme-prod-deployers`

sub-claimet er det primære tillidsanker i de fleste udbyderes trust policies. Det identificerer entydigt kombinationen af organisation, repo og branch. For at isolere hver tenant i delte cloudkonti tilføjer du en betingelse, der låser på repository_owner (din organisations slug) – samme mønster som GitHub Actions’ tillid til token.actions.githubusercontent.com. fremforge udsteder fra én global issuer for alle tenants; isolationen håndhæves i claim-laget, ikke i issuer-URL’en.

Hent tokenet i en workflow

Tilføj id-token: write til jobbets permissions-blok. Runneren sætter så ACTIONS_ID_TOKEN_REQUEST_TOKEN og ACTIONS_ID_TOKEN_REQUEST_URL som miljøvariabler, som du bruger til at hente selve JWT’en:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: fremforge
    steps:
      - name: Get OIDC token
        run: |
          TOKEN=$(curl -sS \
            -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://frem.sh" \
            | jq -r .value)
          echo "TOKEN=$TOKEN" >> $GITHUB_ENV

De fleste udbyderspecifikke steps (AWS, Azure, GCP) henter tokenet internt. Du skal kun skrive den manuelle hentning ovenfor, hvis du har brug for den rå JWT til et brugerdefineret tillidsflow.

T Cloud Public-agency-tillid

T Cloud Publics IAM-føderationsmodel stammer fra OpenStack: du registrerer OIDC-issueren som en identitetsudbyder, tilknytter et mapping, der oversætter claims i ID-tokenet til lokale IAM-grupper, og veksler så runnerens ID-token på OTC’s OS-FEDERATION-endpoint til et T Cloud Public Keystone-token, der er afgrænset til de grupper, mappingen bandt.

fremforge bruger claim-styret gruppebinding (samme form som AWS Identity Center, GCP Workload Identity Federation og Azure Federated Credentials): runnerens ID-token bærer et deployer_group-claim pr. workload, og dit OTC-mapping læser claimet ordret. Én mappingregel dækker hele din flåde – når du tilføjer en workload, rører det slet ikke din IAM.

Trin 1: opret en OpenID Connect-identitetsudbyder

I T Cloud Public-konsollen går du til IAM → Identity Providers → Create Identity Provider.

Type: Virtual user
Protocol: OpenID Connect
Access type: Programmatic access (program)

Når udbyderen er oprettet, konfigurerer du OIDC-indstillingerne:

Identity provider URL (idp_url): https://frem.sh/_app/runner/oidc (én global issuer; svarer til iss-claimet i alle fremforges runner-ID-tokens).
Client ID (client_id): https://frem.sh, som skal være lig med aud-claimet i runnerens ID-token.
Signing key (signing_key): indsæt JWKS-JSON’en med den offentlige nøgle. Hent den én gang fra https://frem.sh/_app/runner/oidc/.well-known/openid-configuration → jwks_uri, og kopiér JSON’en. T Cloud Public henter ikke selv JWKS, så indsæt den igen, når fremforge annoncerer en JWKS-rotation (annonceres på trust-siden; rotationer sker højst én gang om året).

Trin 2: tilføj den claim-styrede mappingregel

Én regel, der skalerer til et vilkårligt antal workloads:

[
  {
    "local": [
      { "user":  { "name": "fremforge-{0}-{1}" } },
      { "group": { "name": "{2}" } }
    ],
    "remote": [
      { "type": "repository_owner" },
      { "type": "repository" },
      { "type": "deployer_group" }
    ]
  }
]

Tillidsmodellen:

Den føderede bruger bliver medlem af den IAM-gruppe, som ID-tokenets deployer_group-claim angiver ({2} indsætter claimets værdi ordret).
Claimet sættes af fremforges runner-OIDC-issuer ud fra den workload→gruppe-mapping, du aftaler ved onboarding. Det kan kun angives for workloads, vi har en række for, og kun for den ref, rækken låser (standard: main-branchen).
Samme låsning af JWT-signaturen, samme filtrering på iss + aud + repository_owner – kun beslutningen om workload→gruppe er flyttet fra “N OTC-mappingregler” til “ét claim udstedt af fremforge”.

Trin 3: opret de IAM-grupper, dine workloads skal antage

Opret én gruppe pr. deployer-profil, du vil udstille (f.eks. acme-prod-deployers, acme-staging-deployers). Tilknyt de projekt- og EPS-roller, hver profil har brug for – de er 100 % dine; fremforge rører aldrig din gruppekonfiguration. Gruppenavnene svarer til den værdi, fremforge sætter i deployer_group-claimet, som aftalt ved onboarding.

Trin 4: fortæl fremforge, hvilken workload der bruger hvilken gruppe

En e-mail eller et kald til admin-API’et: “Repo acme/api, main-branchen → gruppen acme-prod-deployers.” fremforge indsætter en række i sin tabel runner_deployer_groups. Fra næste workflowkørsel bærer ID-tokens for den workload deployer_group=acme-prod-deployers, og dit mapping binder den føderede bruger til den gruppe.

Et nyt repo kræver blot endnu en e-mail – din OTC IAM forbliver uændret.

Valgfrit: opret en agency, der skal antages

De fleste opsætninger springer dette over: gruppebindingen fra trin 2 er nok. Bruger du et mønster med antagne roller, så opret en agency (IAM → Agencies → Create Agency) med følgende:

Agency type: Account (cloudtjeneste fra en anden T Cloud Public-konto er ikke relevant her).
Delegated party: vælg den OpenID Connect-identitetsudbyder, du oprettede i trin 1.
Permissions: tilknyt de politikker, CI-jobbet har brug for (f.eks. OBS Administrator afgrænset til workloadens OBS-bucket eller CCE FullAccess afgrænset til workloadens projekt).

Notér agencyens navn og det projekt, du afgrænser den til.

Trin 5: brug legitimationsoplysningerne i en workflow

Runneren henter et ID-token, veksler det på OTC’s OS-FEDERATION-endpoint til et uafgrænset Keystone-token og bytter det derefter til et projektafgrænset token. Både T Cloud Publics CLI (otc) og OpenTofu med opentelekomcloud-provideren accepterer OS_AUTH_TOKEN fra miljøet uden yderligere konfiguration.

# Forgejo-specific: opts the task into the OIDC envelope.
# Forgejo jobparser only reads this top-level key — it does NOT
# auto-derive from `permissions: id-token: write` like GitHub does.
enable-openid-connect: true

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: fremforge
    steps:
      - name: Exchange OIDC for T Cloud Public token
        run: |
          # 1. Fetch the runner OIDC JWT
          JWT=$(curl -sS --fail \
            -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://frem.sh" \
            | jq -r .value)

          # 2. Exchange at OTC's OS-FEDERATION endpoint (NOT /v3/auth/tokens
          #    with methods=["id_token"] — OTC's Keystone fork doesn't support
          #    that. Use the IdP-scoped URL with Bearer header instead).
          UNSCOPED=$(curl -sS -i \
            -X POST -H "Authorization: Bearer $JWT" \
            "https://iam.eu-de.otc.t-systems.com/v3/OS-FEDERATION/identity_providers/fremforge-runner-oidc/protocols/oidc/auth" \
            | awk 'BEGIN{IGNORECASE=1} /^x-subject-token:/ { sub(/^x-subject-token:[ \t]*/,"",$0); gsub(/\r/,"",$0); print }')

          # 3. Swap for project-scoped (the unscoped token gives you no
          #    permissions on its own; you need a project scope to do anything).
          SCOPED=$(curl -sS -i -X POST \
            -H "Content-Type: application/json" \
            -d "{\"auth\":{\"identity\":{\"methods\":[\"token\"],\"token\":{\"id\":\"$UNSCOPED\"}},\"scope\":{\"project\":{\"name\":\"eu-de\"}}}}" \
            "https://iam.eu-de.otc.t-systems.com/v3/auth/tokens" \
            | awk 'BEGIN{IGNORECASE=1} /^x-subject-token:/ { sub(/^x-subject-token:[ \t]*/,"",$0); gsub(/\r/,"",$0); print }')

          echo "::add-mask::$SCOPED"
          echo "OS_AUTH_TOKEN=$SCOPED" >> $GITHUB_ENV

      - name: Tofu plan
        run: tofu plan
        # opentelekomcloud provider picks up OS_AUTH_TOKEN automatically

Noter om T Cloud Publics særheder

OTC bruger /v3/OS-FEDERATION/identity_providers/{idp}/protocols/oidc/auth, IKKE /v3/auth/tokens med methods=["id_token"]. OpenStack-upstreams auth-body-metode returnerer 400 "Unsupported method: id_token" på OTC’s Keystone-fork. Verificeret i praksis og ifølge OTC’s API-dokumentation iam_13_0606.
OTC roterer ikke JWKS automatisk. Du indsætter signeringsnøglen én gang, når udbyderen oprettes, og igen, når fremforge annoncerer en rotation. AWS, Azure og GCP henter alle automatisk fra discovery-dokumentet – kun T Cloud Public kræver, at du indsætter den eksplicit.
Det vekslede token ligger i svar-headeren X-Subject-Token, ikke i body – OpenStack Keystone-konvention.
Afgrænsningen af workloads kommer fra deployer_group-claimet (mappingen binder den føderede bruger til gruppen) OG projektrollerne på gruppen. Claimet forhindrer, at den forkerte workload antager den forkerte gruppe; rollen begrænser, hvad gruppen kan gøre.
Valgfrit: agencies til mønstre med antagne roller understøttes også, men de fleste brugsscenarier har ikke brug for dem – gruppebindingen fra trin 2 er nok.

AWS IAM

Trin 1: opret en OIDC-identitetsudbyder

I AWS-konsollen går du til IAM → Identity providers → Add provider.

Provider type: OpenID Connect
Provider URL: https://frem.sh/_app/runner/oidc (én global issuer; filtreringen pr. tenant sker i trust policyens betingelse, ikke i udbyder-URL’en)
Audience: https://frem.sh

AWS henter JWKS fra discovery-dokumentet for at verificere tokens.

Trin 2: opret en IAM-rolle med en web identity-trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<account-id>:oidc-provider/frem.sh/_app/runner/oidc"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "frem.sh/_app/runner/oidc:aud": "https://frem.sh",
          "frem.sh/_app/runner/oidc:repository_owner": "<your-org>",
          "frem.sh/_app/runner/oidc:sub": "repo:<your-org>/<your-repo>:ref:refs/heads/main"
        }
      }
    }
  ]
}

Tilknyt de rettigheder, CI-jobbet har brug for, til rollen (f.eks. AmazonS3FullAccess, AmazonECRPowerUser).

Trin 3: brug den i en workflow

Brug den officielle action aws-actions/configure-aws-credentials:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<account-id>:role/<role-name>
          aws-region: eu-central-1
          audience: https://frem.sh

      - name: Deploy
        run: aws s3 sync ./dist s3://my-bucket/

Actionen klarer automatisk hentningen af tokenet, kaldet til sts:AssumeRoleWithWebIdentity og indsættelsen af legitimationsoplysningerne.

Azure (Entra Workload Identity)

Trin 1: opret federated credentials på en app registration

I Azure-portalen går du til Entra ID → App registrations → <your app> → Certificates & secrets → Federated credentials.
Klik på Add credential.
Scenario: Other issuer.
Udfyld:
- Issuer: https://frem.sh/_app/runner/oidc (én global issuer; tenant-isolationen håndhæves af Subject identifier nedenfor)
- Subject identifier: repo:<your-org>/<your-repo>:ref:refs/heads/main
- Audience: https://frem.sh
Gem.

Trin 2: brug det i en workflow

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4

      - name: Get OIDC token
        run: |
          TOKEN=$(curl -sS \
            -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://frem.sh" \
            | jq -r .value)
          echo "OIDC_TOKEN=$TOKEN" >> $GITHUB_ENV

      - name: Azure login via federated token
        run: |
          az login \
            --service-principal \
            --tenant <tenant-id> \
            --client-id <client-id> \
            --federated-token "$OIDC_TOKEN"

      - name: Deploy
        run: az webapp deploy --resource-group my-rg --name my-app --src-path ./dist

App registrationens client ID og dit Entra-tenant-ID er ikke hemmelige. De kan gemmes som almindelige workflowvariabler. Kun OIDC-tokenet er følsomt, og det udløber, når jobbet er færdigt.

GCP Workload Identity

Trin 1: opret en Workload Identity-pool og en OIDC-udbyder

# Create the pool
gcloud iam workload-identity-pools create fremforge-pool \
  --location global \
  --display-name "fremforge CI"

# Create the OIDC provider inside the pool
gcloud iam workload-identity-pools providers create-oidc fremforge-provider \
  --location global \
  --workload-identity-pool fremforge-pool \
  --issuer-uri "https://frem.sh/_app/runner/oidc" \
  --allowed-audiences "https://frem.sh" \
  --attribute-mapping "google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner"

Trin 2: giv tilladelse til at impersonere en service account

# Allow the pool to impersonate a service account, scoped by sub claim
gcloud iam service-accounts add-iam-policy-binding <sa>@<project>.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "principalSet://iam.googleapis.com/projects/<project-number>/locations/global/workloadIdentityPools/fremforge-pool/attribute.sub/repo:<your-org>/<your-repo>:ref:refs/heads/main"

Trin 3: brug det i en workflow

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4

      - name: Authenticate to GCP via OIDC
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/<project-number>/locations/global/workloadIdentityPools/fremforge-pool/providers/fremforge-provider
          service_account: <sa>@<project>.iam.gserviceaccount.com
          audience: https://frem.sh

      - name: Deploy
        run: gcloud run deploy my-service --image gcr.io/my-project/my-image

Actionen google-github-actions/auth virker på fremforges runnere. Den bruger samme mekanisme med ACTIONS_ID_TOKEN_REQUEST_TOKEN / ACTIONS_ID_TOKEN_REQUEST_URL.

Fejlfinding

Audience passer ikke.

aud-claimet i tokenet skal svare til det, udbyderen forventer. Er trust policyen eller udbyderen konfigureret til en anden audience (f.eks. sts.amazonaws.com i stedet for https://frem.sh), fejler vekslingen med en fejl i valideringen af audience. Sæt audience: https://frem.sh eksplicit i udbyderkonfigurationen og i token-anmodningen (brug &audience=https://frem.sh i curl-URL’en).

sub-claimet matcher ikke betingelsen i trust policyen.

sub-claimets format er eksakt: repo:<org>/<repo>:ref:refs/heads/<branch>. Typiske uoverensstemmelser:

Stavefejl i branchnavnet (main vs. master).
Trust policyen bruger en tag-ref (refs/tags/v1.0), men jobbet kører på en branch.
Policyen bruger refs/heads/main, men jobbet kører på en PR-branch (refs/pull/42/head). Brug StringLike med et wildcard, hvis du vil tillade PR’er: "repo:acme/api:ref:refs/pull/*".

Tokenet er udløbet, jobs der varer mere end 1 time.

OIDC-tokenet har en TTL på 1 time. Jobs, der kører længere end 1 time, får et nyt token, hver gang de kalder token-endpointet. Hvert step, der kalder ACTIONS_ID_TOKEN_REQUEST_URL, får et nyt token. Hvis du cacher tokenet på tværs af steps, der tilsammen varer mere end 1 time, udløber det. Hent et nyt token i hvert step, der har brug for legitimationsoplysninger.

Rettigheden id-token: write mangler.

Hvis permissions: ikke er sat i workflowen eller jobbet, bruger runneren standardsættet af skrivebeskyttede rettigheder, som ikke omfatter id-token: write. Variablen ACTIONS_ID_TOKEN_REQUEST_TOKEN vil mangle, og token-anmodningen returnerer 403. Tilføj id-token: write til permissions:-blokken på jobniveau (eller på workflowniveau, hvis alle jobs har brug for det).

Føderationstilsidesættelser pr. organisation

Tenant-administrationssiden på https://frem.sh/<org>/_admin/runner-federation er stedet, hvor du læser din organisations føderationsindstillinger og strammer dem op efter behov.

I de fleste opsætninger har du kun brug for issuer-URL’en – kopiér den fra siden ind i din clouds trust policy (feltet Provider/Issuer URL hos AWS, Azure, GCP, Scaleway osv.). Siden viser også JWKS-URL’en til udbydere, der ikke selv henter discovery-dokumentet (T Cloud Public kræver, at du indsætter den eksplicit; AWS, Azure og GCP henter den automatisk).

Under Avancerede tilsidesættelser på samme side kan du:

Låse allowed_audiences – en fast tilladelsesliste over de aud-værdier, issueren vil signere. Brug den, når du kun vil udstede tokens til bestemte trust policies i clouden og blokere enhver utilsigtet bredere audience.
Sætte en brugerdefineret sub-claim-skabelon – når din eksisterende trust policy forventer en anden sub-form end fremforges standard.

De fleste kunder lader de avancerede tilsidesættelser stå på standard og bruger kun issuer-URL’en. Samme indstillinger findes også programmatisk – se nedenfor.

Føderationstilsidesættelser pr. organisation via API’et

Som standard signerer issueren tokens med platformens claim-form (sub = repo:<org>/<repo>:ref:<ref>, ingen begrænsning på aud). To indstillinger lader dig låse strammere aftaler fast pr. tenant:

allowed_audiences, en fast tilladelsesliste over de aud-værdier, issueren vil signere. Enhver udstedelsesanmodning med en aud uden for listen afvises, før JWT’en oprettes. Nyttigt, når du vil udstede tokens til trust policies hos AWS og T Cloud Public, men blokere ethvert utilsigtet bredere audience-claim. Tom liste = ingen begrænsning (platformens standard).
sub_claim_template, en Mustache-agtig skabelon, der udfyldes med fire værdier ({{tenant}}, {{repo}}, {{branch}}, {{ref_type}}), når tokenet udstedes. Nyttigt, når din eksisterende trust policy fra GitHub Actions eller Bitbucket Pipelines forventer en anden sub-form end fremforges standard.

Læs de aktuelle tilsidesættelser

curl -H "Authorization: Bearer $FREMFORGE_PAT" \
  https://frem.sh/_app/api/v1/orgs/acme/runners/federation
# {
#   "issuer": "https://frem.sh/runner/oidc",
#   "jwks_uri": "https://frem.sh/runner/oidc/.well-known/jwks.json",
#   "tenant_org_slug": "acme",
#   "allowed_audiences": [],
#   "sub_claim_template": null
# }

Lås `allowed_audiences`

curl -X PUT -H "Authorization: Bearer $FREMFORGE_PAT" \
  -H "Content-Type: application/json" \
  -d '{
    "allowed_audiences": [
      "sts.amazonaws.com",
      "sts.eu-west-1.amazonaws.com"
    ]
  }' \
  https://frem.sh/_app/api/v1/orgs/acme/runners/federation

Herefter afvises ethvert forsøg på at udstede et token med en aud, der ikke er på listen, og jobbet fejler lukket med en fejl om afvist audience. Påkrævet PAT-scope: runners:write.

Tilpas `sub_claim_template`

curl -X PUT -H "Authorization: Bearer $FREMFORGE_PAT" \
  -H "Content-Type: application/json" \
  -d '{
    "sub_claim_template": "tenant:{{tenant}}:repo:{{repo}}:branch:{{branch}}"
  }' \
  https://frem.sh/_app/api/v1/orgs/acme/runners/federation

De fire understøttede substitutioner er:

Token	Bliver til	Eksempel
`{{tenant}}`	Organisationens slug	`acme`
`{{repo}}`	`<org>/<repo>`	`acme/api`
`{{branch}}`	Branchnavnet (kun når `ref_type=branch`; tomt for tags)	`main`
`{{ref_type}}`	`branch` eller `tag`	`branch`

Ukendte pladsholdere står uændret i outputtet; f.eks. forbliver {{nope}} som {{nope}} i den færdige sub. Det er tilsigtet: en fejlkonfigureret skabelon fejler tydeligt, når trust policyen skal matche, i stedet for i al stilhed at udsende en tom streng.

Nulstil til standard

Send en tom allowed_audiences og null som sub_claim_template:

curl -X PUT -H "Authorization: Bearer $FREMFORGE_PAT" \
  -H "Content-Type: application/json" \
  -d '{ "allowed_audiences": [], "sub_claim_template": null }' \
  https://frem.sh/_app/api/v1/orgs/acme/runners/federation

Alle opdateringer registreres i tenantens auditlog under runner_federation.updated. Øjebliksbilledet af body udelader den fulde sub_claim_template, men registrerer, om der var sat en.

Scaleway IAM External App

Scaleway er en EU-suveræn cloud med hovedkontor i Frankrig og dataresidens i FR/NL/PL. Deres IAM-primitiv External Apps (GA i oktober 2024) accepterer en upstream OIDC-IdP og lader dig binde workload-principals via JWT-claims – samme føderationsform, som AWS, GCP og Azure tilbyder.

Trin 1: opret en IAM External App

I Scaleway-konsollen: IAM → External Apps → Add an External App. Konfigurér:

Issuer URL, fremforges issuer-URL fra guiden (f.eks. https://frem.sh/_app/runner/oidc).
JWKS URI, fremforges JWKS-URI.
Subject mapping, bind på sub. Begræns til ét repo, hvis det er muligt (repo:<your-slug>/<repo>:*).
Audience, din Scaleway-organisations URN (scw:org:<org-id>).

Trin 2: tilknyt en Policy

Tilknyt en Scaleway-Policy til din External App, der giver de handlinger, din CI har brug for. Afgræns til ét enkelt Project for mindst mulige rettigheder.

Trin 3: brug det i en workflow

permissions:
  id-token: write
steps:
  - name: Get the fremforge OIDC token
    run: |
      TOKEN=$(curl -sS \
        -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
        "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=scw:org:<org-id>" \
        | jq -r .value)
      echo "::add-mask::$TOKEN"
      echo "FF_TOKEN=$TOKEN" >> $GITHUB_ENV
  - name: Exchange for Scaleway STS keys
    run: |
      # POST $FF_TOKEN to Scaleway's External-App token endpoint and export the
      # returned short-lived keys. See the Scaleway IAM docs for the exact shape.
      ./scripts/scw-sts-exchange.sh          # writes SCW_ACCESS_KEY / SCW_SECRET_KEY
  - name: Deploy
    run: ./deploy.sh

Formen på token-vekslingens endpoint er beskrevet i Scaleways IAM-dokumentation; External App-primitivet udsteder kortlivede nøgler i STS-stil, knyttet til OIDC-subjektet.

Generisk OIDC-broker (Authentik, Keycloak)

I opsætninger, hvor clouden ikke selv taler workload-OIDC (ældre enterprise-mål, der kun forstår SAML, on-prem-deployere, centralt vedligeholdte tillidskort på tværs af flere clouds), bruger du en broker: Authentik, Keycloak eller en anden opsætning med en OIDC-RP, der har en downstream-RP.

Hvornår du skal bruge en broker

Du kører allerede Authentik eller Keycloak til menneskers SSO og vil have CI-workloads under samme føderationsflade.
Du vil kun have én trust policy-registrering at vedligeholde, ikke N, én pr. cloud. En ny cloud er så “tilføj en ny Authentik-provider”, ikke “lav trust policyen om i hver cloud”.
Dit mål forstår kun SAML (nogle regulerede on-prem-systemer). Brokeren bygger bro fra OIDC til SAML.
Du sigter mod en cloud uden førsteklasses workload-OIDC (Stackit, OVH, Hetzner); føderér via brokeren i stedet for at vente på førsteklasses understøttelse.

Trin 1: tilføj fremforge som upstream-kilde

I Authentik: Directory → Federation → OAuth/OIDC Source. Sæt:

OIDC Provider, issuer-URL’en fra guiden.
Audience, lad feltet stå tomt, eller sæt det efter din downstream-provider.
Scopes, openid er tilstrækkeligt; fremforges tokens bærer ingen profile- eller email-scopes.

Det tilsvarende i Keycloak er Identity Providers → OpenID Connect v1.0 med Use JWKS URL slået til.

Trin 2: map claims til lokale grupper/roller

I Authentik: Customisation → Property Mappings → OIDC. Map runner-JWT’ens sub (med formen repo:<slug>/<repo>:ref:refs/heads/<branch>) til lokale grupper med et lille Python-udtryk:

# Example: anyone deploying main → 'prod-deploy' group
import re
if re.match(r'^repo:[^/]+/[^:]+:ref:refs/heads/main$', token.get('sub', '')):
    return ['prod-deploy']
return []

Trin 3: brug brokeren som issuer over for den downstream cloud

Din clouds trust policy matcher så på et token, der er signeret af Authentik, ikke direkte af fremforge. Audience = Authentik-providerens client_id. Veksl fremforge-JWT’en til en Authentik-signeret JWT via Authentiks endpoint /application/o/token/:

permissions:
  id-token: write
steps:
- name: Get fremforge runner OIDC token
  run: |
    TOKEN=$(curl -sS \
      -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
      "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=<authentik-provider-client-id>" \
      | jq -r .value)
    echo "::add-mask::$TOKEN"
    echo "FF_TOKEN=$TOKEN" >> $GITHUB_ENV
- name: Exchange for Authentik token
  id: ak-token
  run: |
    curl -fsS -X POST https://idp.acme.com/application/o/token/ \
      -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
      -d subject_token=$FF_TOKEN \
      -d subject_token_type=urn:ietf:params:oauth:token-type:jwt \
      -d audience=<downstream-rp> \
      | jq -r .access_token > /tmp/ak-token
- name: Deploy
  env:
    BROKER_TOKEN: $(cat /tmp/ak-token)
  run: ./deploy.sh

Afvejning

Brokeren er et ekstra led på vejen fra runner til cloud (mere latenstid og ét sted mere at fejlsøge). Den betaler sig, hvis du har tre eller flere clouds, regulerede SAML-mål eller allerede kører en broker til menneskers SSO. Ved opsætninger med én cloud føderérer du direkte til clouden (afsnittene ovenfor).

Krydshenvisninger

CI-runnere, reference for hostede runnere og egne runnere (BYO)
Secrets, opbevaring og afgrænsning af langlivede legitimationsoplysninger
Sikkerhed, runnernes isolationsmodel og forsyningskædesikkerhed

Løbsk CI

OIDC-tokenføderation

Oversigt over claims

Hent tokenet i en workflow

T Cloud Public-agency-tillid

Trin 1: opret en OpenID Connect-identitetsudbyder

Trin 2: tilføj den claim-styrede mappingregel

Trin 3: opret de IAM-grupper, dine workloads skal antage

Trin 4: fortæl fremforge, hvilken workload der bruger hvilken gruppe

Valgfrit: opret en agency, der skal antages

Trin 5: brug legitimationsoplysningerne i en workflow

Noter om T Cloud Publics særheder

AWS IAM

Trin 1: opret en OIDC-identitetsudbyder

Trin 2: opret en IAM-rolle med en web identity-trust policy

Trin 3: brug den i en workflow

Azure (Entra Workload Identity)

Trin 1: opret federated credentials på en app registration

Trin 2: brug det i en workflow

GCP Workload Identity

Trin 1: opret en Workload Identity-pool og en OIDC-udbyder

Trin 2: giv tilladelse til at impersonere en service account

Trin 3: brug det i en workflow

Fejlfinding

Føderationstilsidesættelser pr. organisation

Føderationstilsidesættelser pr. organisation via API’et

Læs de aktuelle tilsidesættelser

Lås allowed_audiences

Tilpas sub_claim_template

Nulstil til standard

Scaleway IAM External App

Trin 1: opret en IAM External App

Trin 2: tilknyt en Policy

Trin 3: brug det i en workflow

Generisk OIDC-broker (Authentik, Keycloak)

Hvornår du skal bruge en broker

Trin 1: tilføj fremforge som upstream-kilde

Trin 2: map claims til lokale grupper/roller

Trin 3: brug brokeren som issuer over for den downstream cloud

Afvejning

Krydshenvisninger

Lås `allowed_audiences`

Tilpas `sub_claim_template`