Entwickler hinterlegen API-Token, Passwoerter und Zugangsdaten nach wie vor direkt im Code oder in .env-Dateien und pushen sie nach Git. Das passiert in kleinen Projekten und in Produktionssystemen gleichermassen.
Der Grund ist einfach: Ohne einen sauberen Weg, Geheimnisse in Automatisierungs- und Deployment-Workflows zu uebergeben, wirkt Git wie die einzige zuverlaessige Option. „Wir raeumen das spaeter auf.“ Aber in Git ist nichts wirklich endgueltig weg.
Warum Git fuer Geheimnisse gefaerhrlich ist
Git ist ein Versionskontrollsystem. Alles, was committet wird, geht in die Historie. Sie koennen ein Token aus dem letzten Commit entfernen — aeltere Commits enthalten es weiterhin. Und die Historie kopiert sich ueberall hin: lokale Repos, Automatisierungsagenten, Spiegel, Forks. Sobald ein Geheimnis in einem Commit landet, ist es offengelegt.
Der Zugriff auf Repositories ist oft weiter gefasst als noetig. Externe Dienstleister, temporaere Mitwirkende, Test-Forks — alle koennen potenziell Zugangsdaten sehen, die sie nicht sehen sollten.
GitHub und GitLab scannen aktiv nach Zugangsdaten. Wenn die Plattform ein Token markiert, behandeln Sie es als kompromittiert und widerrufen Sie es sofort.
Was Git ersetzen sollte
Ein Geheimnis ist keine statische Datei. Es ist eine Zugangsberechtigung, die ausserhalb des Codes leben muss, kontrollierte Berechtigungen braucht, Rotation ermoeglicht und pro Umgebung isoliert sein sollte.
Sie koennten Vault oder OpenBao betreiben — das bedeutet aber Infrastruktur, Wartung und Ops-Aufwand.
Semaphore hat einen integrierten Key Store, der direkt in die Automatisierungs-Workflows eingebunden ist. Geheimnisse koennen an einem von zwei Orten liegen:
- Semaphores verschluesselter Datenbank (Standard)
- Ein externer Speicher wie HashiCorp Vault, Devolutions oder OpenBao (PRO-Feature)
Sie waehlen die einfache eingebaute Variante oder binden ein bestehendes Unternehmens-System fuer Geheimnisse an. Es funktioniert ohne grossen Aufwand.
Was der Key Store speichert
- API-Token
- SSH-Schluessel
- Passwoerter
- Umgebungsvariablen
- JSON und andere Konfigurationsdateien
Geheimnisse beruehren nie den Code. Sie werden nur zur Laufzeit des Jobs injiziert. Sie koennen getrennte Zugangsdaten fuer Entwicklung, Staging und Produktion definieren und den Zugriff auf bestimmte Nutzer, Teams oder Workflows beschraenken.
So sieht es in der Praxis aus
Sie erstellen einen Key Store, fuegen ein Geheimnis hinzu und verweisen darauf in Ihrer Workflow-Konfiguration. Semaphore setzt den Wert zur Laufzeit ein.
Bei einem AWS-Deployment existieren Zugangsschluessel nur solange der jeweilige Job laeuft, nur auf dem Agent, der ihn ausfuehrt. Entwickler sehen das Geheimnis nicht. Es beruehrt nie Git.
Beispiel
Legen Sie ein Secret ueber die Oberflaeche an: Secrets → New Secret, und fuegen Sie Ihre Variablen hinzu:
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY
Verweisen Sie im Workflow auf das Secret — Semaphore injiziert die Werte zur Laufzeit als Umgebungsvariablen:
blocks:
- name: Deploy
task:
secrets:
- name: aws-credentials
jobs:
- name: deploy
commands:
- aws s3 sync ./dist s3://my-bucket
Fuer SSH erstellen Sie ein Secret mit Ihrer privaten Schluesseldatei. Semaphore legt sie automatisch unter ~/.ssh/ ab:
blocks:
- name: Deploy via SSH
task:
secrets:
- name: production-ssh-key
jobs:
- name: deploy
commands:
- ssh deploy@production-server "cd /app && git pull"
Key Store im Vergleich
| Methode | Sicher | Sichtbarkeit | Widerrufbar |
|---|---|---|---|
.env in Git |
Nein | Ganzes Team | Nein |
| GitHub Actions Secrets | Teilweise | Haengt ab | Ja |
| Semaphore Key Store | Ja | Eingeschraenkt | Ja |
Darueber hinaus: Token rotieren, ohne Code zu aendern; Zugriff nach Rolle oder Team steuern; unterschiedliche Geheimnisse pro Umgebung.
Fazit
Jedes Token, das in Git committet wurde, sollte als kompromittiert gelten. Die Historie verbreitet sich ueber Mitwirkende, Forks, Spiegel und Automatisierungsagenten — jede Kopie ist ein weiteres Risiko.
Der Key Store haelt Geheimnisse aus Repos heraus, injiziert sie nur zur Laufzeit und gibt Ihnen Kontrolle ueber Rotation und Zugriff. Fuer Teams mit Ansible, Terraform, OpenTofu oder PowerShell-Automatisierung ist das keine optionale Zusatzinfrastruktur — es ist die Grundlage.
Option 1
Geheimnisse in Git = Geheimnisse offengelegt. Fuer immer.
Die Git-Historie repliziert sich ueber Forks, Spiegel und CI-Agenten. Ein committetes Token ist auf unabsehbare Zeit kompromittiert.
Wir erklaeren, warum das immer wieder passiert — und wie Semaphore Key Store das loest.
Option 2
So geht Semaphore Key Store mit Geheimnissen um:
→ Token, SSH-Keys und Umgebungsvariablen ausserhalb des Repos speichern
→ Im Job-Config mit {{ your_secret }} referenzieren
→ Zur Laufzeit auf dem Agent, nur fuer diesen Job, injizieren
Entwickler sehen es nicht. Es beruehrt nie Git.
Ausfuehrliche Erklaerung → [Link]
Wir haben veroeffentlicht, wie Semaphore Key Store funktioniert — und warum es ihn gibt.
Kurz: Geheimnisse gehoeren nicht in Git. Nie. Aber ohne echte Alternative landen sie trotzdem dort.
Key Store ist direkt in Semaphores Automatisierungs-Workflows eingebunden. Der Ablauf:
- Key Store in der UI anlegen
- Geheimnisse hinzufuegen — API-Token, SSH-Keys, Umgebungsvariablen, Config-Dateien
- In der Job-Konfiguration mit
{{ your_secret }}referenzieren - Semaphore injiziert sie zur Laufzeit auf dem Agent, nur fuer diesen Job
Entwickler sehen das Geheimnis nicht. Es beruehrt nie das Repo. Wenn der Job endet, ist es aus der Ausfuehrungsumgebung verschwunden.
Sie koennen Zugriff nach Nutzer, Team oder Umgebung einschraenken. Ein Token rotieren, ohne eine Zeile Code zu aendern. Getrennte Zugangsdaten fuer Dev, Staging und Prod.
Fuer Teams mit Ansible, Terraform oder OpenTofu — das fehlende Stueck zwischen „es laeuft“ und „es ist wirklich sicher“.
Ausfuehrliche Erklaerung →
