Godkendelsespolitik

Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.

Siden for godkendelsespolitik samler de indstillinger for hele organisationen, der bestemmer, hvordan jeres medlemmer godkendes mod Git og REST API’et. Hver indstilling er uafhængig af de andre; standardværdien er den mest tilladende, så eksisterende medlemmer ikke bliver lukket ude ved et uheld, første gang du åbner siden. Stram dem én ad gangen, efterhånden som jeres sikkerhedsniveau modnes.

Siden ligger på <your-org>/_admin/auth-policy, under gruppen Sikkerhed i organisationens administrationsmenu.

Sammenlægning 2026-05-26: den selvstændige fane SSH-certifikatmyndighed blev lagt ind på denne side som et underafsnit under “Tillad SSH-protokol” (den giver kun mening, når SSH er slået til, så den vises og skjules sammen med indstillingen). Direkte links til /admin/ssh-ca/ viderestiller nu hertil. De samme skrivefunktioner er bevaret — indsæt CA-nøgler, angiv principal-politik, slå krav om certifikat til og fra — uden at du skal forlade godkendelsespolitikken.

Politikker

Krav til SSH-nøgler

Når denne indstilling er slået til, afviser fremforge nye SSH-nøgler, der ikke er hardwarebaserede. Det fremgår af OpenSSH-nøglealgoritmen — kun sk-ssh-ed25519@openssh.com og sk-ecdsa-sha2-nistp256@openssh.com er godkendt; almindelige ssh-ed25519 og ssh-rsa afvises i formularen Add key.

Hardwarebaseret betyder, at den private nøgle ligger i en sikkerhedschip (macOS Secure Enclave, TPM, YubiKey, FIDO-autentifikator). Nøglen kan ikke trækkes ud af den bærbare. Touch ID, PIN-kode eller et tryk på hardwaren kræves ved hvert push. Det er det tætteste, man i praksis kommer på “MFA ved git push” uden at sætte en fuld SSH-certifikatmyndighed op.

Eksisterende nøgler afvises IKKE med tilbagevirkende kraft — kun nye nøgler bliver kontrolleret. Det er sikkert at slå indstillingen til i en velfungerende organisation; medlemmer kan blive ved med at pushe med deres eksisterende nøgler, men når de tilføjer en ny bærbar, skal den sættes op med hardwarebaseret nøgle. Kombinér med SSH-certifikatmyndighed nedenfor for det stærkeste slutmål (ingen almindelige nøgler overhovedet).

Handlinger i revisionsloggen: tenant.auth_policy.hardware_keys.enabled / tenant.auth_policy.hardware_keys.disabled.

SSH-certifikatmyndighed

(Vises kun, når SSH-protokollen er slået til ovenfor — det er naturligt kun at vise en SSH-funktion, når SSH er slået til.)

Godkendelse med SSH-certifikater er den stærkeste praktiske måde at logge ind via SSH på. Et kortlivet certifikat udstedt af jeres egen CA og bundet til jeres IdP’s MFA-flow erstatter den langlivede offentlige nøgle, der ligger på hver udviklers bærbare. fremforge understøtter denne model direkte — det er den samme mekanisme, som GitHub Enterprise Cloud kalder “SSH certificate authority.”

Forudsætning: siden 2026-05-22 har fremforge som standard oprettet nye organisationer med SSH slået fra (indstillingen ovenfor). Hvis jeres organisation beholder standarden, har I slet ikke brug for SSH CA — vejen med HTTPS + Git Credential Manager giver jer MFA ved hvert push via jeres IdP uden nogen CA-opsætning. Hvis jeres organisation udtrykkeligt har slået SSH til igen (fordi I har en konkret grund, f.eks. ældre CI-værktøjer eller en stærk præference blandt udviklerne), er dette afsnit det næste lag af hærdning for den SSH-vej, I har valgt.

Hvornår du skal bruge SSH CA

Brug godkendelse med SSH-certifikater, hvis jeres organisation har slået SSH til igen, OG et af følgende gælder:

• I vil have hvert Git-push beskyttet af en ny MFA-udfordring fra IdP’en (ingen “mistet bærbar → en angriber pusher i 90 dage, indtil nogen opdager SSH-nøglen”)
• I migrerer fra GitHub Enterprise Cloud, og jeres udviklere forventer GHEC’s SSH CA-flow
• Jeres CISO har specifikt bedt om “MFA ved Git push” OG insisterer på SSH som transport — men bemærk, at den renere løsning er standardvejen med HTTPS+GCM
• I har en eksisterende CA, der udsteder OpenSSH-certifikater (Smallstep, HashiCorp Vault SSH secrets engine, en egen OIDC-bundet udsteder), og vil have fremforge til at stole på de certifikater, den signerer

Hvis ingen af de situationer passer på jer, er hardwarebaserede SSH-nøgler (Touch ID, Secure Enclave, YubiKey — indstillingen ovenfor) en enklere vej med sammenlignelig sikkerhed. Se Secure sign-in for en oversigt over valgmulighederne.

Opsætning

Trin 1 — forbered jeres CA. Mulighederne er sorteret efter, hvor nemme de er:

1. Smallstep step ca — open source, egnet til EU-hosting og med understøttelse af OIDC-provisioner fra start. Bind den til jeres IdP, så bliver step ssh login et MFA-flow på én linje.
2. HashiCorp Vault SSH secrets engine — hvis I allerede kører Vault til hemmeligheder, tilføjer SSH secrets engine udstedelse af OpenSSH-certifikater med politikbaseret adgangskontrol.
3. Manuel ssh-keygen -s — kun til proof-of-concept.

Generér CA-nøgleparret, hvis I ikke allerede har et:

ssh-keygen -t ed25519 -f acme-ssh-ca -C "acme-ssh-ca@example.com"

Det giver acme-ssh-ca (privat — hold den hemmelig, og distribuér den til jeres udstedende infrastruktur) og acme-ssh-ca.pub (offentlig — den indsætter du i fremforge i næste trin).

Trin 2 — registrér CA’en. Indsæt acme-ssh-ca.pub i tekstfeltet Trusted CA public keys på denne side, én CA pr. linje. Der accepteres op til 8 CA’er (praktisk ved rotation: tilføj den nye, distribuér den nye private nøgle, udfas den gamle). Klik på Save CA keys. Et automatisk platformsjob fører ændringen videre til Forgejos SSH-lag. Post i revisionsloggen: tenant.ssh_ca.keys.updated.

Trin 3 — vælg principal-politik. Hvert SSH-certifikat bærer én eller flere principals — korte strenge, der navngiver den eller de brugere, certifikatet er gyldigt for:

Post i revisionsloggen: tenant.ssh_ca.principal_policy.updated.

Trin 4 — kræv eventuelt certifikatgodkendelse. Når mindst én CA er konfigureret, kan du slå Require CA-signed certificate til for at afvise almindelig SSH-godkendelse med offentlig nøgle. Det er det reneste slutmål — langlivede ~/.ssh/id_*-nøgler holder helt op med at virke, og hvert Git-push skal gå gennem jeres CA (og dermed jeres IdP’s MFA-flow). Hvis du slog det til uden en fungerende CA, ville alle blive lukket ude; formularen afviser derfor ændringen, når der ikke er konfigureret nogen CA. Poster i revisionsloggen: tenant.ssh_ca.require_cert.enabled / tenant.ssh_ca.require_cert.disabled.

Trin 5 — udsted brugernes første certifikat. Med Smallstep:

step ssh login user@example.com --provisioner=your-oidc-provisioner
# Browser opens → IdP login + MFA → cert issued + cached ~1 hour.

git clone git@frem.sh:<org>/<repo>.git
# OpenSSH presents the cert; fremforge validates against trusted CA + principal policy.

Til Vault, se dokumentationen for HashiCorp Vault SSH secrets engine. Med manuel ssh-keygen -s (kun POC): ssh-keygen -s acme-ssh-ca -I "alice-cert-2026-05-22" -n alice -V +1h alice-id_ed25519.pub → distribuér alice-id_ed25519-cert.pub til brugeren sammen med vedkommendes private nøgle; OpenSSH samler den automatisk op.

Rotation af CA’en

Sådan udskifter du en eksisterende CA uden nedetid: generér et nyt CA-nøglepar → tilføj den nye offentlige nøgle i tekstfeltet ved siden af den eksisterende (op til 8 accepteres) → opdatér jeres CA-infrastruktur, så den udsteder med den nye nøgle → vent, til certifikater udstedt af den gamle CA er udløbet (typisk 1 time) → fjern den gamle CA fra tekstfeltet.

Deaktivering af CA-godkendelse

Fjern alle CA-nøgler fra tekstfeltet, og gem. Posten tenant.ssh_ca.keys.updated i revisionsloggen registrerer next_key_count: 0. Hvis Require CA-signed certificate var slået til, slås det automatisk fra (indstillingen kræver mindst én CA). Medlemmerne går tilbage til almindelig SSH-godkendelse med offentlig nøgle.

PAT-levetid

Den maksimalt tilladte levetid for nyudstedte personlige access tokens. Eksisterende tokens bliver IKKE forkortet med tilbagevirkende kraft — grænsen gælder kun ved udstedelse.

Anbefaling: start med 90 dage. Stram til 30, hvis I har et aktivt program for scanning af legitimationsoplysninger, der fanger lækkede tokens inden for rotationsvinduet.

Handling i revisionsloggen: tenant.auth_policy.max_pat_lifetime.updated.

Tillad deploy-nøgler på repoer

Deploy-nøgler på repoer er langlivede SSH-legitimationsoplysninger afgrænset til ét repository — en parallel vej for langlivede maskinlegitimationsoplysninger ved siden af brugeres PAT’er. De er nyttige for eksterne CI- og mirror-klienter, der ikke kan federere via OIDC. Standard: fra — i tråd med den sikre standardopsætning med ssh_disabled=true og allow_user_pats=false. Langlivede maskinlegitimationsoplysninger er slået fra, indtil I aktivt vælger dem til.

Når politikken er slået fra (standard), træder tre lag i kraft:

1. Banner i Forgejo — når en repo-administrator åbner Repo settings → Deploy keys, sendes siden gennem api-intercept, som indsætter et banner i Fomantic-stil over Forgejos almindelige header, der forklarer, at deploy-nøgler er slået fra af organisationens politik. Forgejos navigation og sidepanel bevares (brugeren bliver aldrig kastet ud af repoet). Indsendelse af formularen Add deploy key blokeres i api’et (POST-anmodningen 303-viderestilles tilbage til GET, så brugeren ser forklaringen i banneret).
2. Blokering i REST API’et — POST /api/v1/repos/<owner>/<repo>/keys returnerer 403 med error: use_fremforge_admin og redirect_to, der peger hertil. DELETE og GET sendes altid videre (operatører kan rydde op i og gennemgå eksisterende nøgler uanset politikken).
3. Advarsel i revisionsloggen — hver eksisterende aktiv deploy-nøgle udløser en tenant.auth_policy.deploy_key_violation-hændelse i revisionsloggen ved næste kørsel af håndhævelsen. Eksisterende nøgler tilbagekaldes IKKE automatisk; operatøren beslutter, hvilke der skal fjernes via Forgejos repo-indstillinger (sletning er stadig mulig).

Hvornår du skal slå det til: kun i det særlige tilfælde, hvor eksterne CI- eller mirror-klienter reelt ikke kan federere via OIDC. Det tilsigtede alternativ til maskinidentitet i CI er OIDC-federation for runners — kortlivede tokens udstedt af fremforges OIDC-udsteder og federeret til jeres clouds tillidspolitik, uden en langlivet hemmelighed pr. repo. De fleste CI-integrationer har ikke brug for deploy-nøgler.

Handlinger i revisionsloggen: tenant.auth_policy.allow_repo_deploy_keys.enabled / .disabled (indstillingen); tenant.auth_policy.deploy_key_violation (pr. aktiv nøgle, mens politikken er slået fra).

Kræv signerede commits

Når denne indstilling er slået til, har default branch i hvert repository i organisationen en branch protection-regel, der kræver signerede commits. Medlemmerne skal sætte GPG- eller SSH-signering af commits op på deres maskiner; Forgejo afviser usignerede commits til default branch ved push.

Indstillingen er minimumskravet på organisationsniveau — branch protection-overstyringer pr. repo gælder, hvis de er sat. Slår du den fra, fjernes eksisterende regler pr. repo IKKE; administratorer fjerner dem manuelt, hvis de vil rulle tilbage.

Opsætning af signering hos medlemmerne:

# Generate a signing key (or use the existing SSH key)
ssh-keygen -t ed25519 -f ~/.ssh/git-signing-key -C "alice signing key"

# Configure git to sign with it
git config --global user.signingkey ~/.ssh/git-signing-key.pub
git config --global gpg.format ssh
git config --global commit.gpgsign true

# Upload the public key to frem.sh/user/settings/keys with usage:
# "Signing key" alongside the same key as an "Authentication key".

Handlinger i revisionsloggen: tenant.auth_policy.signed_commits.enabled / tenant.auth_policy.signed_commits.disabled.

Tillad SSH-protokol

Denne indstilling styrer, om Git over SSH overhovedet er tilladt. Fra (standard for organisationer oprettet efter 2026-05-22) betyder, at alle Git-operationer over SSH på organisationens repositories afvises: push, clone og fetch samt Git LFS over SSH. Clone og fetch afvises, før Git starter; et push afvises i pre-receive-hooket. En afvist clone eller fetch viser en besked, der nævner denne indstilling og giver den HTTPS-clone-URL, der skal bruges i stedet (se Hvad en afvist udvikler ser). Medlemmerne bruger HTTPS + Git Credential Manager, som fører MFA igennem via jeres organisations IdP, hver gang tokenet fornyes. Slå indstillingen til for at tillade SSH (den ældre standard fra før 2026-05-22).

Hvorfor den findes: IP-tilladelseslisten dækker ikke Git over SSH. SSH når fremforge gennem en load balancer, der erstatter kildeadressen med en af vores egne klyngenoder, så den adresse, jeres udvikler forbinder fra, er ikke synlig for os, og fremforge nægter at bedømme en forbindelse ud fra en adresse, vi ved er forkert. Organisationer, der vil have hver eneste Git-operation filtreret på IP, slår SSH fra her og bruger HTTPS, som tilladelseslisten dækker.

Hvad en afvist udvikler ser

En git clone eller git fetch over SSH på et repository i en organisation med SSH slået fra fejler med:

$ git clone git@frem.sh:acme/web.git
Cloning into 'web'...
Forgejo: SSH is turned off for the organisation acme (Authentication policy: "Allow SSH protocol" is off), so SSH push, clone and fetch are refused. Use HTTPS instead: git clone https://frem.sh/acme/web.git

fatal: Could not read from remote repository.

Udviklerens SSH-nøgler og medlemskab af organisationen berøres ikke: slår du indstillingen til igen, er SSH-adgangen tilbage med det samme.

Hver afvisning registreres i revisionsloggen som git.ssh.tenant_disabled_blocked, både for push og for clone og fetch.

Handlinger i revisionsloggen: tenant.auth_policy.ssh_disabled.enabled / tenant.auth_policy.ssh_disabled.disabled.

IP-tilladelsesliste

IP-tilladelseslisten er flyttet til sin egen side: IP-tilladelsesliste. Én liste dækker nu alle HTTPS-flader, så der skal ikke længere vælges et omfang. Dens forhåndsvisning i audit-only-tilstand, runner-indstillingen og break-glass er beskrevet der.

Opbevaring af revisionslog

Styrer det søgbare vindue for hændelsesdata i revisionsloggen. Den kryptografiske kæde (3 års WORM) påvirkes ikke af denne indstilling; kun de læsbare kolonner actor og fields_json påvirkes.

Indstillingen anvendes ved den daglige maskeringskørsel (~02:30 UTC). Udvider du vinduet, forbliver nyudsendte rækker søgbare længere; forkorter du det, maskeres rækker, der er ældre end det nye vindue, uigenkaldeligt ved næste kørsel. Se Revisionslog → Opbevaring for den fulde mekanik.

Handling i revisionsloggen: tenant.auth_policy.audit_retention.updated.

Sådan spiller de sammen

Hvad håndhæver hvad

Disse politikker håndhæves i platformslaget ved hver anmodning. Administrationsgrænsefladen er den autoritative kilde til, hvad organisationen har valgt.

Begrænsninger

• Grænsen for PAT-levetid gælder ved udstedelse. Eksisterende tokens bliver IKKE forkortet med tilbagevirkende kraft. Strammer du grænsen, må du forvente, at nogle bot- og CI-tokens lever længere end den nye politik; de virker stadig, indtil deres oprindelige udløb.
• Håndhævelse af hardwarenøgler gælder kun NYE nøgler. Medlemmerne beholder deres eksisterende nøgler.
• Udrulning af signerede commits til eksisterende repoer sker via et platformsjob; teksten på siden siger ca. 5 minutter. Nye repoer, der oprettes, efter indstillingen er slået til, får reglen ved oprettelsen.