Hvorfor lagring af hemmeligheder i Git er risikabelt, og hvordan Semaphore Key Store løser problemet

Udviklere hardkoder stadig API-tokens, adgangskoder og andre legitimationsoplysninger i kildekoden eller .env-filer og pusher dem til Git. Det sker i sideprojekter såvel som i produktionssystemer.

Mønsteret er velkendt: Hvis der ikke er nogen ligetil måde at levere hemmeligheder til automatiserings- og udrulningspipelines på, begynder Git at ligne det eneste holdbare sted at opbevare dem. Teams bilder sig ind, at de vil rydde op i det senere. I praksis er det, når en hemmelighed først er committed, næsten umuligt at fjerne den helt fra historikken.

Hvorfor Git er farligt til hemmeligheder #

Git gemmer hver eneste revision. Du kan slette et token fra toppen af en branch, men ældre commits indeholder det stadig. Kloner, forks, spejle, CI-checkouts og sikkerhedskopier spreder alle denne historik. I det øjeblik en hemmelighed lander i et commit, bør du antage, at den har forladt din direkte kontrol.

Hvem der kan læse repositoryet, har også en tendens til at være bredere end folk forventer — eksterne leverandører, kortsigtede bidragydere, interne forks — enhver af dem kan se legitimationsoplysninger, de aldrig var beregnet til at have.

GitHub og GitLab udfører scanning efter hemmeligheder. Hvis en udbyder flager et token, skal du behandle det som lækket: tilbagekald det og roter alt, hvad der var afhængigt af det.

Hvor hemmeligheder hører hjemme i stedet for Git #

En hemmelighed er ikke bare endnu en fil i træet. Det er en legitimationsoplysning, der bør leve uden for repositoryet, kun kunne læses af de rette aktører, understøtte rotation og differentiere sig pr. miljø (udvikling, staging, produktion).

Selvhosting af Vault eller OpenBao er en valid tilgang, men det tilføjer infrastruktur, der skal drives, patches og overvåges.

Semaphore indeholder et Key Store, der integreres direkte i automatiseringen. Du kan opbevare hemmeligheder i enten:

• Semaphores krypterede lager (standard)
• En ekstern backend, såsom:
  • HashiCorp Vault — gem legitimationsoplysninger i din egen Vault-udrulning i stedet for i Semaphores database; værdier læses, når et job behøver dem (Pro).
  • OpenBao — det community-vedligeholdte, Vault-kompatible fork; forbinder gennem samme integrationssti som Vault (Pro).
  • Devolutions Server — brug Devolutions som backend til hemmeligheder for Enterprise-installationer, i samme ånd som Vault (Enterprise).

Brug det indbyggede lager for en hurtig løsning, eller tilslut dit eksisterende hemmelighedssystem på virksomhedsniveau. Begge integreres med arbejdsgange uden brugerdefineret limkode.

Hvad du kan gemme i Key Store #

• API-tokens
• SSH-nøgler
• Adgangskoder
• Miljøvariabler
• JSON og andre konfigurationsnyttelaster

Værdier ligger aldrig i repositoryet; de leveres til jobs under kørsel. Du kan bruge forskellige poster pr. miljø og begrænse, hvem eller hvilke arbejdsgange der må bruge hver hemmelighed.

Hvordan det fungerer i praksis #

Du opretter en post i Key Store, knytter hemmeligheder til den og refererer til denne post fra din opgavekonfiguration. Semaphore opløser og injicerer værdierne, når jobbet kører.

For eksempel eksisterer adgangsnøgler under en AWS-udrulning kun i det pågældende jobs levetid på den agent, der udfører det. Udviklere behøver ikke en kopi i deres lokale checkout, og intet følsomt behøver at blive committed til Git.

Eksempel #

Åbn Secrets → New Secret i brugerfladen, og definer variabler såsom:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Referer til hemmeligheden ved navn i din arbejdsgang. Semaphore udstiller værdierne som miljøvariabler for det pågældende job:

blocks:
  - name: Deploy
    task:
      secrets:
        - name: aws-credentials
      jobs:
        - name: deploy
          commands:
            - aws s3 sync ./dist s3://my-bucket

For SSH gemmes den private nøgle i en hemmelighed; Semaphore kan placere den under ~/.ssh/ for jobbet:

blocks:
  - name: Deploy via SSH
    task:
      secrets:
        - name: production-ssh-key
      jobs:
        - name: deploy
          commands:
            - ssh deploy@production-server "cd /app && git pull"

Key Store vs. andre tilgange #

Du får også rotation uden at redigere applikationskode, adgangsgrænser efter rolle eller team samt en ren adskillelse mellem miljøer.

Konklusion #

Behandl ethvert token, der er blevet committed til Git, som kompromitteret. Historikken forgrener sig på tværs af maskiner og organisationer; hver ekstra kopi er endnu et sted, en angriber kan lede.

Key Store holder materiale ude af repositories, leverer det kun ved udførelsestidspunktet og giver dig håndtag til rotation og adgangskontrol. For automatisering baseret på Ansible, Terraform, OpenTofu eller PowerShell er dette ikke valgfri pynt — det er minimumskravet for at operere sikkert.