Sikker deployment-pipeline: udgiv appen uden personlige genveje

En pipeline er en kontrolleret produktionsvej

Automatisering er ikke målet i sig selv. Målet er, at en bestemt, gennemgået version går gennem kendte kontroller og bliver udgivet med en identitet, der kun må det nødvendige. Resultatet skal kunne kobles tilbage til commit, workflowkørsel, miljø og tidspunkt.

Vælg deploymentmodel efter den stack, I allerede har

Nogle hostingplatforme bygger automatisk fra en beskyttet Git-branch. Andre kræver et workflow, der logger ind i Azure, Google Cloud eller en anden cloud og kører en deploy-kommando. Begge modeller kan være fornuftige. Kortlæg den faktiske vej frem for at lægge et ekstra automationslag ovenpå.

En manuel proces er ikke automatisk uforsvarlig, og en automatisk proces er ikke automatisk sikker. Fjern først de skjulte trin og den personlige produktionsadgang.

Adskil kontrol fra retten til at udgive

Et pull request kan bygge og teste uden produktionsadgang. Først et særskilt deployment-job bør kunne hente den identitet eller de secrets, der kræves for at ændre produktion. Jobbet skal afhænge af de relevante kontroller og pege på et navngivet environment som production.

name: Udgiv produktion

on:
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: production-deploy
  cancel-in-progress: false

jobs:
  verify:
    uses: ./.github/workflows/verify.yml

  deploy:
    needs: verify
    environment: production
    permissions:
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - name: Hent den godkendte commit
        uses: actions/checkout@<fuld-commit-SHA>
      - name: Hent kortlivet cloudadgang
        uses: <officiel-auth-action>@<fuld-commit-SHA>
      - name: Udgiv
        run: <projektets-dokumenterede-deploy-kommando>

Eksemplet er en struktur, ikke et færdigt workflow. GitHub dokumenterer, at environment-regler kan begrænse brancher, kræve godkendelse og holde environment- secrets tilbage, indtil reglerne er bestået. Tilgængeligheden af bestemte beskyttelsesregler afhænger af repositoryets synlighed og GitHub-plan, så kontrollér de aktuelle vilkår i jeres repository.

Brug en særskilt og afgrænset produktionsidentitet

Pipeline skal ikke logge ind som ejeren af cloudkontoen. Opret en maskinidentitet til deployment, begræns den til de nødvendige ressourcer og adskil test fra produktion. Hvis platformen understøtter workload identity federation, kan workflowet bytte et GitHub OIDC-token til kortlivet cloudadgang i stedet for at gemme en langlivet cloudnøgle i GitHub.

• Afgræns tilliden: Cloudens trust-policy skal kontrollere det konkrete repository og efter behov branch, environment eller workflow — ikke stole på alle GitHub-workflows.
• Afgræns ressourcerne: Deployment-identiteten skal kun kunne ændre de tjenester, som den pågældende release faktisk kræver.
• Afgræns workflowet: Giv kun id-token: write til det job, der autentificerer mod cloud. GitHub præciserer, at rettigheden alene kun tillader hentning af OIDC-tokenet; cloudens trust- og IAM-regler afgør den faktiske adgang.
• Hvis OIDC ikke passer: Brug et separat, mindst muligt privilegeret credential med ejer, udløb eller rotationsplan, og opbevar det i environmentets secret-lager.

Kør kun én produktionsudgivelse ad gangen

To deployments, der overlapper, kan udgive versioner i uventet rækkefølge eller konkurrere om migreringer og konfiguration. GitHub Actions kan samle jobs i en concurrency-gruppe, så kun ét job i gruppen kører ad gangen. Brug en stabil gruppe pr. produktionsmål og tag bevidst stilling til, om en igangværende udgivelse nogensinde må afbrydes.

• Produktionsdeploy: Lad normalt det aktive job afslutte, medmindre jeres platform dokumenterer sikker annullering.
• Nye commits: Beslut om de skal vente, erstattes før start eller samles i en ny release. Gæt ikke ud fra køens rækkefølge.
• Databasemigrering: Kør ikke to migreringer parallelt, og sørg for at gammel og ny appversion kan mødes under udrulningen.

Hvis deployment også ændrer databaseskema, er rollback af kode ikke nødvendigvis nok. Planlæg kompatible schemaændringer og datavejen iguiden om databasemigreringer.

Behandl workflowkode som produktionskode

Et workflow kan læse kode, hente credentials og ændre drift. Derfor skal ændringer i workflowfiler gennem samme review som anden kritisk kode. GitHub anbefaler at giveGITHUB_TOKENmindst mulige rettigheder og at fastlåse tredjeparts-actions til en fuld commit-SHA, som er kontrolleret i actionens rigtige repository.

• Brug kun actions, der er nødvendige, og gennemgå hvad de får adgang til.
• Lad ikke ubetroet tekst fra branch-, issue- eller pull request-data blive fortolket som shellkode.
• Udskriv ikke komplette miljøvariabler, tokens eller cloudkonfiguration i logs.
• Planlæg opdatering af fastlåste action-SHA'er, så sikkerhedsrettelser ikke fryses væk.

Verificér release før den kaldes færdig

En grøn deploy-kommando beviser kun, at værktøjet afsluttede som forventet. Pipeline eller runbook skal bagefter kontrollere den faktiske produktionsadresse og registrere den udgivne version.

1. 1. Bekræft mål og version. Kontrollér domæne, miljø, commit og eventuel artefakt før ændringen.
2. 2. Kør et sikkert smoke test. Test sundhedsstatus og én eller få kritiske brugerrejser uden rigtige betalinger, masseudsendelser eller ukontrollerede produktionsdata.
3. 3. Se driften. Følg fejl, svartider og relevante forretningssignaler i et aftalt tidsrum.
4. 4. Stop på kendte kriterier. Beslut på forhånd hvilke fejl der udløser pause, rollback eller deaktivering af en funktion.
5. 5. Bevis vejen tilbage. Genudgiv en kendt god version i et sikkert miljø, og dokumentér hvad der ikke kan rulles tilbage automatisk.

Typiske fejl

• Ejertoken som repository-secret: Et læk giver langt større adgang end en deployment behøver.
• Alle jobs får alle secrets: Test, lint og tredjeparts-actions kan se produktionsadgang uden at bruge den.
• Workflowet bruger flytbare action-tags: Koden, der får credentials, kan ændre sig uden en ændring i jeres repository.
• To releases overlapper: En ældre release kan ende sidst, eller schema og appversion kan komme ud af takt.
• “Deploy succeeded” er eneste kontrol: Forkert miljø, fejlet login eller en brudt brugerrejse opdages først af brugerne.
• Rollback betyder kun gammel frontend: Migreringer, køjobs, konfiguration og eksterne sideeffekter bliver ikke gjort om af den grund.

Tjekliste før pipeline får produktionsadgang

• ☐ Én dokumenteret vej forbinder en godkendt version med det rigtige produktionsmiljø.
• ☐ Build og relevante tests kan køre uden produktionscredentials.
• ☐ Deployment-jobbet bruger et navngivet environment med passende branch- og godkendelsesregler.
• ☐ Produktionsadgang ligger kun i deployment-jobbet og er begrænset til nødvendige ressourcer.
• ☐ OIDC-trust er afgrænset til repository og relevant branch, environment eller workflow — eller et alternativt credential har ejer og rotationsplan.
• ☐ Workflowets standardrettigheder er eksplicitte og mindst mulige.
• ☐ Tredjeparts-actions er gennemgået og fastlåst til verificerede fulde commit-SHA'er.
• ☐ Kun én deployment kan ændre samme produktionsmål ad gangen.
• ☐ Schemaændringer er kompatible med den gamle og nye app under udrulningen.
• ☐ Live smoke test, observation, stopkriterier og ansvarlig modtager er aftalt.
• ☐ Udgivet commit og workflowkørsel kan findes i deploymenthistorikken.
• ☐ En kendt god version kan genudgives, og datakonsekvenserne ved rollback er dokumenteret.

Relaterede guides

• GitHub Actions til build og test
• Beskyt den branch, der kan gå i produktion
• Testmiljø, smoke tests og rollback
• API-nøgler, secrets og rotation