GitHub Actions Secrets verwalten: API-Schlüssel und Kennwörter in Workflows schützen

Von Mirko Peters · 2026-10-26

Erfahren Sie, wie Sie Ihre CI/CD-Pipelines absichern, indem Sie GitHub Actions Secrets richtig einsetzen. Entdecken Sie bewährte Methoden für die sichere Verwaltung von API-Schlüsseln und Zugriffstoken.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Wenn Ihre Automatisierung vollständig unbeaufsichtigt in der Cloud läuft, wird der Schutz Ihrer Anmeldedaten entscheidend. Wenn Sie GitHub Actions Secrets sauber verwalten, bleiben Ihre API-Schlüssel, Bereitstellungskennwörter und Zugriffstoken aus Ihrem Quellcode heraus und stehen den Workflows trotzdem zuverlässig zur Verfügung, die Ihre Projekte erstellen und ausliefern.

Das Wichtigste in Kürze

• Hinterlegen Sie sensible Kennwörter, API-Schlüssel und Zugriffstoken niemals fest im Code Ihrer Workflow-YAML-Dateien.
• GitHub bietet drei Ebenen von Secrets: Repository-Secrets, Organisations-Secrets und Umgebungs-Secrets.
• Secrets werden bereits verschlüsselt, bevor sie GitHub erreichen, und in den Ausführungsprotokollen automatisch maskiert.
• Umgebungs-Secrets können eine manuelle Genehmigung erzwingen, bevor Bereitstellungsanmeldedaten für einen Job verfügbar werden.
• Halten Sie sich stets an das Prinzip der minimalen Berechtigungen und gewähren Sie jedem Secret nur die geringste Anzahl erforderlicher Berechtigungen.

Warum Klartext-Anmeldedaten in CI/CD scheitern

Wer eine neue Pipeline eilig einrichtet, ist versucht, einen API-Schlüssel direkt in die Workflow-Konfigurationsdatei einzufügen. Schließlich: Wenn der Workflow privat ist, wer soll ihn schon sehen? Diese Denkweise schafft gravierende Sicherheitslücken. Workflow-Dateien werden versioniert. Das heißt, jede frühere Revision, jeder Commit und jeder Branch enthält dauerhaft alles, was in diesen YAML-Dokumenten stand.

Hinzu kommt: Repositorys ändern häufig ihre Berechtigungen, werden von privat auf öffentlich umgestellt oder von Mitwirkenden geforkt. Liegen Ihre Anmeldedaten als Klartext in den Konfigurationsdateien, kann eine einzige Fehlkonfiguration Ihre gesamte Produktivumgebung offenlegen. Die Konfigurationsdateien ausschließlich als Anweisungen zu behandeln und sensible Daten in einem verschlüsselten, davon getrennten Tresor abzulegen, ist die Grundregel moderner Cloud-Sicherheit.

Die drei Ebenen der GitHub-Secrets

GitHub berücksichtigt, dass unterschiedliche Anmeldedaten unterschiedliche Geltungsbereiche haben. Damit Sie Zugriffe effizient steuern können, lassen sich Secrets auf drei getrennten organisatorischen Ebenen konfigurieren.

Secrets auf Repository-Ebene

Repository-Secrets gehören ausschließlich zu einem einzelnen Projekt. Wenn Sie eine eigenständige Anwendung oder ein einzelnes Plug-in entwickeln, sichern Repository-Secrets Ihre Verbindungszeichenfolgen und Bereitstellungstoken für genau diesen Arbeitsbereich. Andere Projekte in Ihrer Organisation können nicht darauf zugreifen.

Secrets auf Organisationsebene

Wenn mehrere Repositorys eines Unternehmens auf dieselben gemeinsamen Ressourcen zugreifen müssen, etwa eine zentrale Container-Registry oder ein unternehmensweites Zertifikat zur Codesignatur, ersparen Ihnen Organisations-Secrets doppelte Einträge. Administratoren können Richtlinien definieren und gezielt Repositorys oder Teams festlegen, die diese organisationsweiten Anmeldedaten übernehmen dürfen.

Secrets auf Umgebungsebene

Umgebungs-Secrets binden Anmeldedaten an bestimmte Bereitstellungsziele wie Staging- oder Produktionsumgebungen. Hier hinterlegen Sie die Schlüssel, die für den Zugriff auf Live-Systeme nötig sind. Entscheidend ist: Mit Umgebungs-Secrets können Sie erforderliche Prüfer festlegen. So muss ein Mensch eine Bereitstellung manuell genehmigen, bevor die Produktionsanmeldedaten freigegeben und an den Runner übergeben werden.

Wie GitHub Ihre Daten während der Übertragung schützt

Sicherheit betrifft nicht nur die Frage, wo Geheimnisse gespeichert werden, sondern auch, wie sie während der Ausführung übertragen werden. Geheimnisse werden auf Ihrem lokalen Computer verschlüsselt, bevor sie an GitHub übertragen werden. So ist sichergestellt, dass sie niemals im Klartext über das Netzwerk gesendet werden. Nach dem Speichern bleiben sie in der Oberfläche der Repository-Einstellungen vollständig verborgen.

Wenn ein Workflow ausgeführt wird, müssen Sie ein Geheimnis über seinen Namen explizit an einen Schritt oder eine Aktion übergeben, und zwar mit einer Ausdruckssyntax wie ${{ secrets.DATABASE_URL } }. Dadurch kann sich eine unbeabsichtigt eingebundene oder bösartige Drittanbieter-Aktion aus dem Marketplace nicht automatisch alle Zugangsdaten in Ihrem Repository holen. Sie erhält nur das, was Sie ausdrücklich übergeben.

Zusätzlich durchsucht GitHub die Ausgabeprotokolle von Aufträgen automatisch nach sensiblen Zeichenfolgen und maskiert sie. Gibt Ihr Skript versehentlich einen Geheimniswert in der Konsole aus, versucht GitHub, die Zeichen durch Sternchen zu ersetzen. Da Skripte Zeichenfolgen jedoch vor der Ausgabe verändern oder kodieren können, ist die Maskierung in Protokollen allein kein Ersatz für sicheren Code.

Bewährte Methoden für sichere Automatisierung

Ein robustes Geheimnismanagement für GitHub Actions erfordert bestimmte tägliche Gewohnheiten. Unterscheiden Sie zunächst immer zwischen einer Konfigurationseinstellung und einem Geheimnis. Handelt es sich um eine öffentliche Webadresse, einen Umgebungsnamen oder ein nicht sensibles Feature-Flag, belassen Sie den Wert im Klartext in Ihrer YAML-Datei, damit Ihr Team leicht nachvollziehen kann, wie die Pipeline funktioniert. Verwenden Sie die Geheimnisfunktion ausschließlich für Daten, die vertraulich bleiben müssen.

Zweitens sollten Sie das Prinzip der minimalen Berechtigungen anwenden. Erstellen Sie granulare Zugriffstoken mit möglichst kurzer Gültigkeitsdauer und möglichst engem Berechtigungsumfang. Muss ein Bereitstellungstoken nur in einen bestimmten S3-Bucket schreiben, geben Sie ihm keine Administratorrechte für Ihre gesamte Cloud-Infrastruktur.

Fazit

Wer das Geheimnismanagement von GitHub Actions beherrscht, verwandelt CI/CD-Pipelines von potenziellen Sicherheitsrisiken in robuste Automatisierungsmotoren auf Unternehmensniveau. Indem Sie Zugangsdaten von Ihrem Code trennen und mehrstufige Zugriffskontrollen nutzen, können Sie Software schnell ausliefern, ohne auf Sicherheit zu verzichten.

Um die Grundlagen zum Erstellen automatisierter Workflows zu erkunden, sehen Sie sich die vollständige Folge an. Hören Sie sich die gesamte Diskussion an, um mehr über das Einrichten von Auslösern, Aufträgen und Runnern für Ihre moderne Cloud-Umgebung zu erfahren!

Häufige Fragen

Kann ich ein GitHub-Actions-Geheimnis in einer Pull Request aus einem Fork lesen?

Standardmäßig verhindert GitHub, dass Pull Requests von externen Mitwirkenden (Forks) auf Ihre Repository-Geheimnisse zugreifen. So wird verhindert, dass schädlicher Code ausgeführt wird und Ihre Zugangsdaten stiehlt.

Wie übergebe ich ein Geheimnis von einem Workflow an einen bestimmten Schritt?

Sie übergeben Geheimnisse an Ihren Workflow über den „env“-Kontext innerhalb eines Schritts oder Auftrags, indem Sie das GitHub-Geheimnis einer Umgebungsvariablen zuordnen, zum Beispiel env: API_KEY: ${{ secrets.MY_API_KEY } }.

Sind GitHub-Actions-Geheimnisse in Protokollen garantiert verborgen?

GitHub maskiert bekannte Geheimniswerte in Ausführungsprotokollen automatisch, das ist jedoch keine absolute Garantie. Wird ein Geheimniswert vor der Ausgabe verändert, kodiert oder umgewandelt, können Teile davon möglicherweise offengelegt werden.

Worin unterscheiden sich Repository-Geheimnisse und Umgebungsgeheimnisse?

Repository-Geheimnisse stehen allen Workflows in einem bestimmten Repository zur Verfügung, während Umgebungsgeheimnisse an bestimmte Bereitstellungsumgebungen (etwa Staging oder Produktion) gebunden sind und manuelle Genehmigungen erfordern können.