Geheimnisse in GitHub Actions teilen – kein Vault nötig

Du kannst Geheimnisse in GitHub Actions ohne HashiCorp Vault teilen, indem du die GitHub Action von Vaulted verwendest. Sie erstellt verschlüsselte, selbstzerstörende Links ohne jegliche Infrastruktur. Sie nutzt clientseitige AES-256-GCM-Verschlüsselung und funktioniert als einzelner Workflow-Schritt — kein Secrets-Manager-Server, keine Cloud-Konfiguration erforderlich.

CI-Pipelines brauchen ständig temporäre Zugangsdaten. Einen Deploy-Key, der nur für einen einzigen Run existieren soll. Ein Token, das während einer Migration zwischen zwei Repos weitergegeben wird. Eine Zugangsdaten-Rotation in einem Workflow, die in einem anderen konsumiert wird.

Der übliche Rat lautet: "Verwende einen Secrets-Manager." Aber HashiCorp Vault aufzusetzen oder AWS Secrets Manager zu konfigurieren, nur um eine einzige Zugangsdaten zwischen Workflows weiterzugeben, ist wie ein Lagerhaus zu mieten, um einen Brief zu verschicken.

GitHub-Repo-Secrets decken den statischen Anwendungsfall gut ab — langlebige API-Keys, Deploy-Token, Service-Account-Zugangsdaten. Für alles Temporäre oder Dynamische reichen sie jedoch nicht aus.

Die Lücke: temporäres Teilen von Geheimnissen in CI/CD

Repo-Secrets sind für Werte ausgelegt, die sich selten ändern und von einem einzigen Repository konsumiert werden. Sie decken folgende Szenarien nicht ab:

Einmalige Übergaben bei der Schlüsselrotation — Du rotierst eine Zugangsdaten in einem Workflow und ein anderer Workflow (oder ein Team) muss den neuen Wert genau einmal abholen.
Repository-übergreifendes Teilen von Zugangsdaten — Zwei Repos müssen ein kurzlebiges Token austauschen, aber keines sollte es dauerhaft speichern.
Zeitlich begrenzter Auftragnehmer-Zugang — Ein CI-Token, das ablaufen soll, sobald das Deploy-Fenster eines Auftragnehmers geschlossen wird.
Wissen, wann ein Geheimnis konsumiert wurde — Repo-Secrets bieten keinerlei Transparenz darüber, ob oder wann ein Wert gelesen wurde.

Das sind temporäre Probleme, die eine temporäre Lösung brauchen.

Ein leichtgewichtiger Ansatz: verschlüsselte, selbstzerstörende Links

Die Vaulted GitHub Action ermöglicht es dir, verschlüsselte, selbstzerstörende Geheimnisse direkt aus deinen Workflows heraus zu erstellen und abzurufen — keine Infrastruktur zu verwalten.

Ein Geheimnis erstellen:

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

Der Schritt gibt eine URL aus, die das verschlüsselte Geheimnis enthält. Der Verschlüsselungsschlüssel lebt im URL-Fragment und gelangt daher nie auf Vaulteds Server.

Ein Geheimnis abrufen:

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Nach dem Abruf ist der Link verbraucht und der serverseitige Ciphertext wird gelöscht. Das Geheimnis existiert nur für die Dauer des Jobs im Speicher des Runners.

Sicherheitsmodell

Drei Eigenschaften machen dies sicher für den CI/CD-Einsatz:

Zero-Knowledge-Verschlüsselung. Das Geheimnis wird mit AES-256-GCM innerhalb des GitHub-Runners verschlüsselt, bevor es den Prozess verlässt. Der Verschlüsselungsschlüssel ist im URL-Fragment eingebettet, das niemals an den Server gesendet wird. Vaulted speichert ausschließlich Ciphertext, den es nicht entschlüsseln kann. Das ist clientseitige Verschlüsselung angewendet auf CI/CD.
Automatische Log-Maskierung. Die Action ruft core.setSecret vor core.setOutput auf und registriert jede Zeile des Geheimniswerts beim Log-Masker von GitHub. Mehrzeilige Geheimnisse werden zeilenweise maskiert, sodass auch Teilübereinstimmungen aus den Workflow-Logs geschwärzt werden.
Selbstzerstörende Links. Aufruflimits und zeitbasierter Ablauf werden serverseitig durchgesetzt. Ein Geheimnis, das mit views: 1 und expires: 1h erstellt wurde, wird nach dem ersten Abruf oder nach einer Stunde dauerhaft gelöscht — je nachdem, was zuerst eintritt.

Wann du dies statt eines Secrets-Managers verwenden solltest

Szenario	Secrets-Manager	Vaulted Action
Langlebige Produktionszugangsdaten	Ja	Nein
App-Runtime-Konfiguration (DB-URLs, API-Keys)	Ja	Nein
Einmalige Zugangsdaten-Übergabe zwischen Workflows	Überdimensioniert	Ja
Temporäres repository-übergreifendes Token-Sharing	Überdimensioniert	Ja
Zeitlich begrenzter CI-Zugang für Auftragnehmer	Überdimensioniert	Ja
Zugangsdaten-Verteilung nach einer Rotation	Überdimensioniert	Ja

Secrets-Manager sind das richtige Werkzeug für Geheimnisse, die Anwendungen zur Laufzeit konsumieren. Vaulted ist für die Übergabe — den Moment, in dem eine Zugangsdaten von einem Ort zum anderen wandert und nicht persistiert werden soll.

Erste Schritte

Füge die Action zu einem beliebigen Workflow hinzu:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Du findest sie im GitHub Marketplace. Geheimnisse, die von der Action erstellt wurden, sind mit der Web-App und der CLI kompatibel — alles, was in einem erstellt wurde, kann in einem anderen abgerufen werden.

Kein Vault-Server. Keine IAM-Richtlinien. Keine Infrastruktur. Nur verschlüsselte Links, die sich selbst zerstören.

Die Lücke: temporäres Teilen von Geheimnissen in CI/CD

Ein leichtgewichtiger Ansatz: verschlüsselte, selbstzerstörende Links

Sicherheitsmodell

Wann du dies statt eines Secrets-Managers verwenden solltest

Erste Schritte

Verwandte Artikel