Sichere Geheimnisverwaltung in GitHub Actions

Home » Python » Sichere Geheimnisverwaltung in GitHub Actions

Die Verwaltung von Geheimnissen in GitHub Actions ist eines jener Themen, die auf den ersten Blick einfach erscheinen, sich aber schnell zu einem kritischen Sicherheitsrisiko entwickeln, sobald Ihre Pipelines mit der Produktion, Cloud-Anbietern und Diensten von Drittanbietern in Berührung kommen. Ihre CI/CD-Workflows arbeiten regelmäßig mit API-Schlüsseln, Datenbankpasswörtern, SSH-Schlüsseln, Tokens und mehr, und jeder dieser Werte stellt ein potenzielles Einfallstor für Angreifer dar, wenn er unachtsam behandelt wird.

In diesem Leitfaden gehen wir detailliert darauf ein, wie Geheimnisse in GitHub Actions funktionieren, wie man sie auf Repository-, Umgebungs- und Organisationsebene konfiguriert, wie man Arbeitsabläufe gegen Datenlecks und Lieferkettenangriffe absichert und wann es sinnvoll ist, externe Geheimnismanager hinzuzuziehen. Die Idee ist, Ihnen einen praktischen, sicherheitsorientierten Überblick zu geben, damit Sie Ihre Pipelines schnell halten können. kombiniert mit einem nachhaltigen Materialprofil. Sicherheit, ohne den Arbeitsalltag zur Belastung zu machen.

Was genau sind GitHub Actions Secrets?

In GitHub Actions ist ein „Secret“ eine verschlüsselte Umgebungsvariable, deren Wert vor der Benutzeroberfläche, den Protokollen und den Repository-Inhalten verborgen bleibt. Sie definieren es einmal (auf Repository-, Organisations- oder Umgebungsebene) und referenzieren es dann in Ihrer Workflow-YAML-Datei mithilfe des secrets. Kontext, damit Ihre Pipelines sensible Werte verwenden können, ohne diese jemals in die Codebasis einzuchecken.

Im Hintergrund verschlüsselt GitHub Geheimnisse mithilfe starker Kryptographie (Libsodium-versiegelte Boxen), bevor sie überhaupt die Server von GitHub erreichen, und die Werte werden erst zur Laufzeit auf dem Workflow-Runner entschlüsselt. Einmal erstellt, sind Geheimnisse über die Benutzeroberfläche unveränderlich: Sie können zwar überschrieben, aber nicht mehr gelesen werden, und in Protokollen werden sie automatisch maskiert. *** woimmer möglich.

Dieses Modell bringt einige wichtige Designbeschränkungen mit sich, die Sie beachten sollten: Geheimnisse können nicht über die Benutzeroberfläche oder die API abgerufen werden, sie werden in den Protokollen unkenntlich gemacht und sie befinden sich in einem bestimmten Bereich: Repository, Umgebung innerhalb eines Repositorys oder Organisation. Die Wahl des richtigen Geltungsbereichs ist die erste wichtige Entscheidung für eine vernünftige Geheimhaltungsstrategie.

Repository-, Umgebungs- und Organisationsgeheimnisse

GitHub bietet drei Hauptebenen für Geheimnisse: Repository-Geheimnisse, Umgebungsgeheimnisse und Organisationsgeheimnisse, jede mit ihren eigenen Anwendungsfällen und Prioritätsregeln. Das Verständnis ihrer Wechselwirkungen hilft Ihnen, Konflikte zu vermeiden und sensible Werte dort zu belassen, wo sie hingehören.

Geheimnisse auf Repository-Ebene

Repository-Geheimnisse sind an ein einzelnes Repository gebunden und stehen allen Workflows in diesem Repository zur Verfügung. Sie eignen sich perfekt für projektspezifische Werte wie den API-Schlüssel eines Dienstes, ein Bereitstellungspasswort oder ein Webhook-Token, das nur von diesem Repository verwendet wird.

Um ein Repository-Geheimnis über die Benutzeroberfläche zu erstellen, gehen Sie zum Ziel-Repository, öffnen „Einstellungen“ → „Geheimnisse und Variablen“ → „Aktionen“ und klicken dann auf „Neues Repository-Geheimnis“. Sie vergeben einen Namen in Großbuchstaben mit Unterstrichen (zum Beispiel PAYMENTS_API_KEYFügen Sie den geheimen Wert ein und speichern Sie; ab diesem Zeitpunkt können Workflows darauf zugreifen als ${{ secrets.PAYMENTS_API_KEY }}.

Jeder, der Schreibzugriff auf das Repository hat, kann in Workflows auf diese Geheimnisse verweisen, sodass Berechtigungen für das Repository selbst Teil Ihrer Sicherheitsstrategie werden. Wenn Sie vielen Benutzern unbedacht Schreibzugriff gewähren, geben Sie ihnen implizit auch die Möglichkeit, jedes Repository-Geheimnis in der Automatisierung zu nutzen.

Umgebungsspezifische Geheimnisse

Umgebungsgeheimnisse befinden sich eine Ebene unterhalb der Repository-Geheimnisse und ermöglichen es Ihnen, unterschiedliche Werte pro Umgebung zu definieren, wie zum Beispiel: dev, staging oder production. Sie sind an eine benannte Umgebung gebunden und können durch Regeln wie erforderliche Prüfer oder Wartezeiten geschützt werden, bevor ein Job gegen sie ausgeführt werden kann.

Sie konfigurieren diese, indem Sie zu „Einstellungen“ → „Umgebungen“ gehen, eine Umgebung erstellen oder auswählen und dann Geheimnisse innerhalb dieser Umgebungskonfiguration hinzufügen. Die geheimen Namen werden immer noch verwendet secrets. Kontext (zum Beispiel) secrets.PROD_DB_PASSWORDDie Werte stehen jedoch nur für Jobs zur Verfügung, die explizit in dieser Umgebung ausgeführt werden.

Ein wichtiger Aspekt ist, dass Umgebungsgeheimnisse Repository-Geheimnisse überschreiben, wenn sie denselben Namen haben. Das bedeutet, Sie können definieren DB_PASSWORD auf Repository-Ebene für lokale/Testzwecke und dann eine andere DB_PASSWORD als Umgebungsgeheimnis für die Produktion, das bei Produktionsaufträgen Vorrang hat, ohne die Workflow-Syntax zu ändern.

Umgebungen ermöglichen auch Schutzregeln wie „erforderliche Prüfer“ oder „nur aus bestimmten Branches“, was unglaublich nützlich ist, um den Zugriff auf Ihre sensibelsten Geheimnisse einzuschränken. Beispielsweise kann es in einer Produktionsumgebung erforderlich sein, dass vor der Ausführung eines Jobs, der auf deren Geheimnisse zugreift, die Genehmigung durch DevOps erteilt wird.

Geheimnisse der gesamten Organisation

Organisationsgeheimnisse werden über mehrere Repositories innerhalb einer Organisation hinweg geteilt und eignen sich ideal für Anmeldeinformationen, die breit wiederverwendet werden, wie beispielsweise ein gemeinsamer Slack-Webhook oder ein zentrales Metrik-API-Token. Sie reduzieren die Duplizierung und erleichtern die Rotation, da Sie das Geheimnis nur einmal aktualisieren und alle konsumierenden Repositories den neuen Wert übernehmen.

Administratoren erstellen sie in der Organisation unter „Einstellungen“ → „Geheimnisse und Variablen“ → „Aktionen“, indem sie auf „Neues Organisationsgeheimnis“ klicken und dann auswählen, welche Repositories auf dieses Geheimnis zugreifen dürfen. Sie können alle aktuellen und zukünftigen Repositories zulassen oder die Auswahl auf eine bestimmte Teilmenge beschränken.

Es gibt eine Prioritätshierarchie, die Sie beachten sollten: Organisationsgeheimnis < Repository-Geheimnis < Umgebungsgeheimnis bei Namenskonflikten. Mit anderen Worten: Ein Umgebungsgeheimnis hat Vorrang vor einem Repository-Geheimnis, welches wiederum Vorrang vor einem Organisationsgeheimnis hat, wenn alle denselben Schlüssel verwenden.

Wie sich Geheimnisse zur Laufzeit verhalten

Sobald Geheimnisse definiert sind, stehen sie den Jobs zur Laufzeit über die secrets Kontext und werden bei Referenzierung als Umgebungsvariablen injiziert. Sie werden nicht standardmäßig in jedem Schritt exportiert; Sie müssen sie explizit in Ihrem Code einbinden. env: Blockiert oder übergibt sie an Aktionen, die Geheimnisse als Eingaben unterstützen.

GitHub bietet außerdem eine spezielle Funktion an. GITHUB_TOKEN pro Workflow-Lauf, wobei es sich nicht um ein manuell definiertes Geheimnis handelt, es sich aber wie eines verhält und häufig für API-Aufrufe oder Repository-Operationen verwendet wird. Sie können (und sollten) die detaillierten Berechtigungen dieses Tokens mithilfe der permissions: block so, dass es den für jeden Job erforderlichen Mindestumfang hat.

Um versehentliche Offenlegung zu reduzieren, maskiert GitHub jeden Wert, der einem registrierten Geheimnis in Workflow-Protokollen entspricht, und ersetzt ihn durch ***. Diese Maskierung erfolgt serverseitig und funktioniert im Allgemeinen gut für unformatierte Zeichenketten. Sie setzt jedoch voraus, dass der exakte geheime Wert in der Ausgabe enthalten ist. Wenn Sie den geheimen Wert transformieren (z. B. Base64-kodieren oder in strukturiertes JSON einbetten), kann die Maskierung ihn möglicherweise nicht mehr erkennen.

Da die Maskierung nach bestem Bemühen erfolgt und keine mathematische Garantie bietet, sollten Sie Arbeitsabläufe so gestalten, dass Geheimnisse oder deren Ableitungen überhaupt nicht in Protokolle geschrieben werden, und Maskierungsbefehle für zusätzliche Werte verwenden, die Sie zur Laufzeit generieren. Behandeln Sie Protokolldateien so, als wären sie für mehr Personen sichtbar, als Sie erwarten, und gehen Sie davon aus, dass alles Gedruckte durchsickern könnte.

Praktische Anwendung: Referenzieren von Geheimnissen in Arbeitsabläufen

In den meisten Fällen werden Geheimnisse verwendet, indem man sie in einem bestimmten Schritt oder Job Umgebungsvariablen zuordnet und dann die Skripte oder Tools aus der Umgebung lesen lässt. Ein klassisches Muster sieht so aus:

– Name: Bereitstellung auf API
Umgebung:
API-Schlüssel: ${{ secrets.PROD_API_KEY }}
laufen: |
curl -H “Authorization: Bearer $API_KEY” https://api.example.com/deploy

Sie können auch ein Geheimnis in eine Datei auf dem Runner schreiben, das sicher ist, solange die Datei innerhalb des temporären Arbeitsbereichs des Jobs verbleibt und nicht als Artefakt gespeichert oder hochgeladen wird. Zum Beispiel das Speichern eines SSH-Schlüssels:

– Name: SSH-Schlüssel in Datei schreiben
Shell: Bash
Umgebung:
SSH-Schlüssel: ${{ secrets.SSH_KEY }}
laufen: |
echo “$SSH_KEY” > key
chmod 600 Schlüssel

In den Protokollen sieht man nur den eigentlichen Shell-Befehl (mit $SSH_KEY), jedoch nicht der geheime Wert selbst, der geschwärzt oder verborgen wird. Da die auf GitHub gehosteten Runner nach Abschluss des Jobs zerstört werden, verschwindet diese temporäre Datei mit der VM; bei selbst gehosteten Runnern muss man beim Aufräumen viel strenger vorgehen.

Sicherheitsbest Practices für Geheimnisse in GitHub Actions

Die Nutzung der Secrets-UI allein reicht nicht aus; Sie benötigen eine Reihe von Gewohnheiten und Sicherheitsvorkehrungen, um den Schaden zu minimieren, falls etwas schiefgeht. GitHub bietet viele Einstellmöglichkeiten, aber es liegt an Ihnen, diese richtig zu nutzen.

Wenden Sie das Prinzip der geringsten Rechte an

Jedes Geheimnis und jedes Token sollte nur die Berechtigungen gewähren, die für eine bestimmte Aufgabe unbedingt erforderlich sind. Für externe Dienste sollten Sie dedizierte Anmeldeinformationen mit eingeschränkten Berechtigungen erstellen (z. B. „Nur bereitstellen“ oder „Nur Metriken lesen“), anstatt die vollständigen Administratorschlüssel wiederzuverwenden.

Das gleiche Prinzip gilt auch für die eingebauten GITHUB_TOKEN; die Standardberechtigungen auf das absolute Minimum setzen (oft contents: read) und dann die Berechtigungen nur in bestimmten Jobs zu erhöhen, die mehr benötigen. Sie konfigurieren dies mit einem permissions: Abschnitt auf Workflow- oder Jobebene, damit ein kompromittierter Job nicht unbemerkt beliebige Schreibvorgänge durchführen kann.

Vermeiden Sie das Drucken oder Verschlüsseln von Geheimnissen in Protokolldateien.

Geheimnisse sollten niemals in Workflow-Dateien fest codiert oder aus Gründen der Debugging-Vereinfachung im Klartext ausgegeben werden. Falls Sie weitere sensible Werte besitzen, die nicht als GitHub-Geheimnisse registriert sind (z. B. ein zur Laufzeit generiertes Token), können Sie den Runner dennoch anweisen, diese mithilfe der folgenden Befehlssyntax als Geheimnisse zu behandeln:

echo “::add-mask::$GENERATED_TOKEN”

Strukturierte Datenblöcke wie JSON, XML oder große YAML-Dokumente sind als Geheimnisse besonders gefährlich, da der Maskierer von GitHub auf exaktem Zeichenkettenvergleich basiert. Wenn Sie mehrere sensible Werte in eine große JSON-Zeichenkette einfügen und diese als ein einziges Geheimnis verwenden, können bereits geringfügige Formatierungsänderungen dazu führen, dass die Maskierung fehlschlägt; definieren Sie stattdessen für jedes sensible Feld ein individuelles Geheimnis.

Überprüfen Sie beim Testen von Arbeitsabläufen stets die Protokolle und achten Sie dabei besonders auf Fehlermeldungen und Stacktraces. Manche Tools geben Befehle und Flags bereitwillig auf stderr aus, wodurch versehentlich auch geheime Werte erfasst werden können, es sei denn, man vermeidet dieses Muster explizit.

Geheimnisse regelmäßig rotieren und überprüfen.

Die regelmäßige Rotation geheimer Zugangsdaten ist zwar mühsam, aber unerlässlich, wenn einem die Sicherheit am Herzen liegt; wenn Zugangsdaten jahrelang unverändert bleiben, vergrößert sich das Zeitfenster für Angreifer. Eine vernünftige Grundeinstellung ist es, die wichtigsten Produktionsgeheimnisse monatlich, risikoreiche Geheimnisse alle paar Monate und alle anderen mindestens vierteljährlich zu rotieren.

Einen Teil davon können Sie mithilfe der GitHub REST API für Geheimnisse automatisieren. Damit können Sie den öffentlichen Schlüssel eines Repositorys oder einer Organisation abrufen und neue verschlüsselte Werte hochladen. Dies ist besonders praktisch für große Organisationen mit vielen Repositories, die Servicekonten gemeinsam nutzen und diese im Falle von Vorfällen schnell rotieren müssen.

Die Überprüfung ist ebenso wichtig: Überprüfen Sie regelmäßig die Liste der konfigurierten Geheimnisse und löschen Sie diejenigen, die nicht mehr verwendet werden, und verwenden Sie die Sicherheits-/Überwachungsprotokolle von GitHub, um Ereignisse wie die folgenden zu verfolgen: org.update_actions_secret. Auf diese Weise wissen Sie, wer was wann geändert hat, und Sie können verdächtige Änderungen mit anderen Aktivitäten in Zusammenhang bringen.

Umgebungsbasierte Trennung nutzen

Umgebungsgeheimnisse sind eine der einfachsten Möglichkeiten, Ihre Pipelines abzusichern, da sie es Ihnen ermöglichen, hochsensible Werte (wie z. B. Zugangsdaten für die Produktionsdatenbank) hinter expliziten Genehmigungen zu isolieren. Sie können menschliche Prüfer vorschreiben, einschränken, welche Branches bereitgestellt werden dürfen, und sogar Wartezeiten vor dem Start einer Bereitstellung hinzufügen.

Ein gängiges Muster ist, dass man staging Umgebung mit mildem Schutz und einem production Umgebung mit strengeren Regeln und getrennten Geheimnissen. Anschließend werden Workflows definiert, die auf die jeweilige Umgebung abzielen, um sicherzustellen, dass Produktionsgeheimnisse niemals versehentlich in Testjobs verwendet werden.

Wählen Sie klare Namenskonventionen

Eine gute Benennung von Geheimnissen bewahrt Sie vor frustrierendem Rätselraten und gefährlichen Verwechslungen. Anstelle von generischen Namen wie API_KEY, kodieren Sie den Dienst und die Umgebung im Namen, zum Beispiel STRIPE_PROD_API_KEY or AWS_STAGING_DEPLOY_ROLE_ARN.

Teams, die mit vielen Dienstleistungen zu tun haben, wenden oft ein ähnliches Muster an wie <SERVICE>_<ENV>_<PURPOSE>. Sie könnten also haben SLACK_PROD_ALERTS_WEBHOOK, GCP_DEV_BUILD_SERVICE_ACCOUNT und DB_STAGING_PASSWORDDadurch wird viel deutlicher, welches Geheimnis in welchem ​​Job zum Einsatz kommen sollte.

Schutz vor Script-Injection und Drittanbieterrisiken

Geheimnisse sind nicht nur durch Fehlkonfigurationen gefährdet; sie stellen auch verlockende Ziele für Skripteinschleusungen in Arbeitsabläufen sowie für böswillige oder kompromittierte Aktionen Dritter dar. Ein einziger unachtsamer Schritt kann, wenn man nicht vorsichtig ist, alle für den Job zugänglichen Geheimnisse preisgeben.

Abschwächung der Skriptinjektion in Inline-Schritten

Wenn Sie nicht vertrauenswürdige Daten (wie Pull-Request-Titel, Branch-Namen oder Issue-Kommentare) direkt in Shell-Skripte einfügen, öffnen Sie die Tür für Injection. Beispielsweise könnte ein PR-Titel so gestaltet sein, dass er einen Befehl abbricht und beliebigen Shell-Code in Ihrem Runner ausführt.

Am sichersten ist es, komplexe Logik in selbst bereitgestellten oder gut geprüften JavaScript/TypeScript-Aktionen zu verarbeiten und nicht vertrauenswürdige Werte als Eingaben zu übergeben, anstatt sie in die Shell einzubetten. In diesem Modell empfängt die Aktion Zeichenketten als Argumente und verarbeitet sie, ohne Shell-Skripte zu generieren, die abgefangen werden können.

Wenn Sie unbedingt die Inline-Shell verwenden müssen, speichern Sie nicht vertrauenswürdige Werte zuerst in Umgebungsvariablen und referenzieren Sie diese Variablen dann, vorzugsweise innerhalb von doppelten Anführungszeichen. Auf diese Weise wird der Wert als Daten und nicht als Teil der Skriptstruktur behandelt, wodurch die Wahrscheinlichkeit eines erfolgreichen Einschleusungsversuchs deutlich sinkt.

Aktionen von Drittanbietern anpinnen und überprüfen

Jede Drittanbieteraktion, die Sie in Ihren Workflow einbinden, hat Zugriff auf die Umgebung und die Geheimnisse des Jobs. Daher sollten Sie sie als Codeabhängigkeiten behandeln, die einer genauen Prüfung bedürfen. Durch eine böswillige oder kompromittierte Aktion können Geheimnisse ausgelesen und mit einem einzigen HTTP-Aufruf an einen Angreifer gesendet werden.

Es empfiehlt sich, Aktionen anhand der vollständigen Commit-SHA anstatt nur anhand von Tags oder Branches zu fixieren, da Tags verschoben oder überschrieben werden können. Ein SHA-Wert verweist auf eine exakte Version des Codes, wodurch es für einen Angreifer deutlich schwieriger wird, unbemerkt neues Verhalten einzuschleusen, ohne dass Sie den Workflow aktualisieren müssen.

Bevor Sie eine Aktion verwenden, sollten Sie deren Quellcode (oder zumindest eine Sicherheitsprüfung) überfliegen, um sicherzustellen, dass sie Geheimnisse verantwortungsvoll behandelt und diese weder protokolliert noch an unbekannte Endpunkte sendet. Wenn Sie Marketplace-Aktionen nutzen, überprüfen Sie nach Möglichkeit den Herausgeber und verlassen Sie sich auf Dependabot, um über Sicherheitslücken und Aktualisierungen informiert zu werden.

Gehostete vs. selbstgehostete Läufer und geheime Offenlegung

Wo Ihre Arbeitsabläufe ausgeführt werden, hat einen großen Einfluss darauf, wie sicher Geheimnisse behandelt werden. GitHub-gehostete Runner und selbstgehostete Runner verhalten sich hinsichtlich Isolation und Persistenz sehr unterschiedlich.

Die auf GitHub gehosteten Runner erstellen für jeden Job neue virtuelle Maschinen, führen Ihren Workflow aus und bauen diese anschließend wieder ab. Dadurch erhalten Sie jedes Mal eine saubere Umgebung und es wird sichergestellt, dass alle Dateien oder Umgebungsvariablen (einschließlich auf die Festplatte geschriebener Geheimnisse) nach Abschluss des Auftrags gelöscht werden.

Selbstgehostete Runner hingegen sind langlebige Maschinen, die Sie selbst verwalten. Das bedeutet, dass jeder Code, der Zugriff auf Geheimnisse hat, diese potenziell über die Lebensdauer eines einzelnen Jobs hinaus speichern oder exfiltrieren kann. Bei öffentlichen Repositories stellen selbstgehostete Runner ein besonderes Risiko dar, da nicht vertrauenswürdige Mitwirkende Pull Requests öffnen können, die Workflows auslösen.

Wenn Sie selbstgehostete Runner verwenden, isolieren Sie diese nach Sensibilitätsstufe, beschränken Sie, welche Repositories welche Runner verwenden dürfen, und seien Sie paranoid, was sich sonst noch auf diesen Maschinen befindet (SSH-Schlüssel, Cloud-Zugangsdaten, Netzwerkzugriff auf interne Dienste usw.). Einige Organisationen verwenden „Just-in-Time“- (JIT) selbstgehostete Runner, die über eine API für einen einzelnen Job erstellt und anschließend wieder gelöscht werden. Aber auch dann muss sichergestellt werden, dass Jobs nicht unerwartet denselben Runner verwenden.

Verwendung von OpenID Connect (OIDC) anstelle von langlebigen Cloud-Geheimnissen

Einer der größten Vorteile für die Geheimhaltung von GitHub Actions ist der Ersatz langlebiger Cloud-Zugriffsschlüssel durch kurzlebige Anmeldeinformationen über OpenID Connect. Anstatt AWS-, Azure- oder GCP-Schlüssel als Geheimnisse zu speichern, fordern Ihre Workflows temporäre Token vom Cloud-Anbieter an, indem sie GitHub als Identitätsanbieter verwenden.

Der Ablauf sieht in etwa so aus: Der Job fordert ein signiertes JWT vom OIDC-Endpunkt von GitHub an, Ihr Cloud-Anbieter validiert dieses Token und tauscht es gegen kurzlebige Anmeldeinformationen aus, und der Workflow verwendet diese Anmeldeinformationen für die Dauer des Jobs. Kein statisches Geheimnis muss jemals auf GitHub gespeichert werden.

Bei AWS konfigurieren Sie beispielsweise eine IAM-Rolle, die dem GitHub OIDC-Provider vertraut und einschränkt, welche Repositories/Branches diese Rolle übernehmen dürfen. Dann verwenden Sie in Ihrem Workflow eine Aktion wie zum Beispiel aws-actions/configure-aws-credentials mit aktivierten OIDC-Berechtigungen zum Abrufen von Anmeldeinformationen im laufenden Betrieb.

Dieser Ansatz bietet zahlreiche Vorteile: Innerhalb von GitHub muss nichts rotiert werden, Tokens sind automatisch nur von kurzer Dauer, der Zugriff ist eng begrenzt und Sie erhalten vollständige Audit-Logs auf der Cloud-Seite, die jede Rollenübernahme protokollieren. Für Hochsicherheitsumgebungen sollte OIDC, sofern unterstützt, die Standardeinstellung sein.

Native Tools und externe Geheimnismanager

Die in GitHub integrierten Secrets sind für viele Szenarien hervorragend geeignet, aber irgendwann wünscht man sich vielleicht einen zentraleren, funktionsreicheren Secret Manager, der mehrere Plattformen und Umgebungen umfasst. Tools wie HashiCorp Vault, Infisical oder Doppler werden häufig zusammen mit GitHub Actions zu diesem Zweck eingesetzt.

Diese Systeme können dynamische Geheimnisse verwalten (z. B. die Generierung kurzlebiger Datenbankbenutzer), erweiterte Zugriffskontrollrichtlinien, detaillierte Audit-Protokolle und Rotations-Workflows, die über das hinausgehen, was GitHub allein bietet. GitHub Actions authentifizieren sich dann bei diesen Managern (oft über OIDC oder eine andere Authentifizierungsmethode), rufen die benötigten Geheimnisse zur Laufzeit ab und verwenden sie, ohne jemals langfristige Anmeldeinformationen im Repository zu speichern.

Darüber hinaus gibt es Community-Aktionen und Plugins, die entwickelt wurden, um Geheimnisse von externen Managern direkt in Arbeitsabläufe zu integrieren. Bei der Verwendung dieser Funktionen gilt der gleiche Rat: Überprüfen Sie den Quellcode der Aktion, binden Sie sie an einen Commit-SHA an und beschränken Sie die Berechtigungen, die dem Token oder der Rolle gewährt werden, die zum Erreichen des externen Systems verwendet wird.

Sicheres Geheimnismanagement in GitHub Actions bedeutet, für jedes Geheimnis den richtigen Geltungsbereich zu wählen, das Prinzip der minimalen Berechtigungen durchzusetzen, gegebenenfalls Umgebungen und OIDC zu verwenden, Protokolle und Aktionen von Drittanbietern als potenzielle Angriffsflächen zu behandeln und auf externe Geheimnismanager zurückzugreifen, wenn dies aufgrund des Umfangs oder der Compliance-Anforderungen erforderlich ist. Mit diesen Vorgehensweisen bleiben Ihre CI/CD-Pipelines flexibel und schnell, während gleichzeitig die Wahrscheinlichkeit, dass ein falsch platzierter Token oder ein schlecht geprüfter Workflow zu einem ausgewachsenen Zwischenfall führt, drastisch reduziert wird.