fremforges provider för Terraform och OpenTofu

fremforges provider hanterar din organisations inställningar i fremforge från OpenTofu eller HashiCorp Terraform: autentiserings- och åtkomstpolicy, IP-tillåtelselistan, skannings- och skannerpolicy, oföränderliga releaser, signaturregler för images och paket, beroendeproxyn, paketåtkomst och registerrobotar.

Repon, team och regler för branchskydd är Forgejo-objekt och stannar hos communityns provider svalabs/forgejo, så som det beskrivs i Konfiguration som kod. De två providerna fungerar sida vid sida i samma konfiguration.

Installation

Providern publiceras på själva frem.sh, så båda CLI:erna installerar den utan extra konfiguration:

terraform {
  required_providers {
    fremforge = {
      source  = "frem.sh/fremforge/fremforge"
      version = "~> 0.1"
    }
  }
}

tofu init (eller terraform init) hittar registret på https://frem.sh/.well-known/terraform.json, laddar ned zip-filen för din plattform från cli.frem.sh och kontrollerar den mot SHA256SUMS, vars OpenPGP-signatur verifieras med fremforges releasenyckel. Det finns byggen för Linux och macOS (amd64, arm64) och Windows (amd64).

Releasenyckeln:

Den privata nyckeln lämnar aldrig fremforges plattform: varje release signeras av plattformen, och bara för providerns releasebygge.

Konfiguration

provider "fremforge" {
  # endpoint = "https://frem.sh/_app/api/v1"   # the default
}

Providern läser sin token från FREMFORGE_TOKEN. Använd en API-token för organisationen som du hanterar, skapad under Organisationens administration → API-token (frem.sh/<org>/_admin/api-tokens), med de scopes som dina resurser behöver. Ha en token med enbart läsbehörighet för plan och skrivscopet för jobbet som kör apply:

Resurser

Organisationsinställningar är singletons: varje organisation har dem alltid, och API:t har ingen borttagning. Varje argument är valfritt. Bara de argument som du anger skrivs; de övriga läses tillbaka till state och lämnas orörda, så en ändring som någon gör i konsolen av en inställning som du inte hanterar räknas inte som drift. Importera en singleton med organisationens slug.

Varje singleton är också en datakälla med samma namn.

Samlingar har en riktig skapa- och ta bort-operation:

Ett paketnamn kan innehålla / (ett npm-scope, en containersökväg), och därför kommer det sist i import-id:na.

Exempel

resource "fremforge_auth_policy" "this" {
  org                   = "acme"
  max_pat_lifetime_days = 30
  allow_user_pats       = false
  ssh_disabled          = true
}

resource "fremforge_ssh_ca" "this" {
  org          = "acme"
  ca_keys      = [file("ssh-ca.pub")]
  require_cert = true
}

resource "fremforge_scan_policy" "images" {
  org            = "acme"
  scanner        = "image_scan"
  mode           = "enforce"
  block_severity = "high"
}

Borttagna inställningar

Två inställningar togs bort från fremforge den 2026-10-14, eftersom de sparades men aldrig tillämpades: principal_policy på fremforge_ssh_ca och default_template_repo på fremforge_branch_protection_defaults. Sedan provider 0.1.1 är båda attributen föråldrade: providern varken skickar eller läser dem längre, så en konfiguration som fortfarande sätter dem fungerar och ger en ren plan, och tofu plan skriver ut en varning om att de är föråldrade. Ta bort dem från konfigurationen; ingenting ändras när du gör det. Se Branchskydd och SSH-certifikatutfärdare.

Scoped CI-secrets: värdet hamnar aldrig i state

fremforge_ci_secret (från provider 0.9.0) hanterar en scoped CI-secret. Värdet är ett write-only-argument, value_wo: det skickas när secreten skapas och vid varje ändring (API:t ersätter värde och scope tillsammans), och det läses aldrig tillbaka och lagras aldrig i plan eller state. Write-only-argument kräver OpenTofu 1.11 eller Terraform 1.11 eller senare. Utelämna repository_id för hela organisationen; höj value_wo_version för att skriva ett nytt värde.

variable "deploy_key" {
  type      = string
  sensitive = true
  ephemeral = true
}

resource "fremforge_ci_secret" "deploy" {
  org              = "acme"
  name             = "DEPLOY_KEY"
  repository_id    = 42
  value_wo         = var.deploy_key
  value_wo_version = 1
  workflows        = ["deploy.yaml"]
  refs             = ["refs/heads/main"]
  events           = ["push", "workflow_dispatch"]
  environment      = "production"
}

• Rotation: fremforge kan inte visa värdet, så ett nytt value_wo ensamt är ingen ändring. Höj value_wo_version för att skriva det.
• Drift: en ändring av scope eller beskrivning gjord utanför din konfiguration visas i planen; en ändring av värdet gör det inte.
• Att skapa tar aldrig över: finns det redan en secret med det namnet och repositoryt misslyckas apply och ber dig importera den.
• Import: <org>/<NAME> för en secret för hela organisationen, <org>/<repository id>/<NAME> för en som är bunden till ett repository. Ange value_wo i konfigurationen före nästa apply.
• Token-scopes: providerns token behöver ci-secrets:read och ci-secrets:write.

Scope-argumenten nekas innan någon begäran skickas när de skulle kunna vidga leveransen: en tom post, ett reserverat namn (FORGEJO_, GITHUB_, GITEA_) eller ett repository-id som inte är ett positivt tal.

Tokens för registerrobotar hamnar aldrig i state

API:t visar en registerrobots token en gång, när den utfärdas. Providern sparar den aldrig i state, i inget attribut. Den skriver token en gång, när API:t utfärdar den (när roboten skapas och varje gång du ändrar rotation), till filen som du anger i token_file, med läge 0600, och skriver aldrig över en befintlig fil:

resource "fremforge_registry_robot" "ci" {
  org        = "acme"
  name       = "ci-pull"
  access     = "read"
  token_file = "${path.module}/.robot-ci.token"
  rotation   = "2026-10"   # change to issue a new token; the old one is revoked at once
}

Utan token_file kastas token bort. Flytta undan filen innan du roterar igen.

Drift, import och destroy

• Drift: plan -detailed-exitcode avslutas med 2 när en inställning som du hanterar har ändrats utanför din konfiguration; apply återställer den.
• Import: import { to = fremforge_auth_policy.this; id = "acme" }, därefter skriver tofu plan -generate-config-out=generated.tf konfigurationen åt dig.
• Destroy: för en singleton tar destroy bara bort den från state och ändrar ingenting i organisationen: att skriva standardvärden skulle i tysthet försvaga en säkerhetsinställning. Samlingar tas bort. fremforge_package_access tar bort paketets inställningar och varje behörighet som getts för det.

Flytta från modulen

Modulen förblir dokumenterad medan du flyttar. För varje inställning lägger du till providerns resurs, importerar den med organisationens slug, kontrollerar att plan inte visar några ändringar, tar sedan bort modulens argument och kör tofu state rm på dess restful_resource.

Så testar vi den

Varje resurs och datakälla körs genom det riktiga OpenTofu-CLI:t mot ett inspelat fremforge-API vid varje ändring: bara de argument som du anger skrivs, ändringar som inte hanteras ignoreras, drift i hanterade inställningar planeras, import läser tillbaka samma state och destroy beter sig som det beskrivs ovan.

De inställningar som är säkra att ändra i en delad organisation körs dessutom live mot en testorganisation varje natt: apply, en ren plan, en ändring via API:t, en plan som visar den, apply, import till ett nytt state, en ren plan, destroy, en tillbakaläsning och återställning av det ursprungliga värdet. Det gäller autentiseringspolicyn, SSH-CA:n, SLA-policyn och beroendeproxyns metadatafilter; paketåtkomst, skyddsregler och registerrobotar kördes live på samma sätt före releasen. IP-tillåtelselistan och signaturpolicyerna testas bara mot det inspelade API:t, eftersom en ändring av dem i en delad organisation skulle störa andra tester.