HashiCorp Vault
Zugangsdaten aus Ihren vorhandenen Vault-KV-Geheimnissen beziehen.
Zugangsdaten an einem Ort verwalten
Speichern Sie Schlüssel, Passwörter und Tokens im integrierten Key Store oder binden Sie Ihren Vault an. Verwenden Sie benannte Zugangsdaten jobübergreifend, halten Sie Geheimnisse aus dem Code fern und aktualisieren Sie sie an der Quelle.
Den integrierten Key Store nutzen oder Ihren Vault anbinden
Speichern Sie Zugangsdaten getrennt vom Code. Verwenden Sie benannte Schlüssel über Repositories, Inventare und Jobs hinweg mit der zu Ihrer Infrastruktur passenden Geheimnisquelle.
Integrierter Key Store
Speichern Sie SSH-Schlüssel, Kombinationen aus Benutzername und Passwort sowie Textgeheimnisse im verschlüsselten Key Store von Semaphore. Verwenden Sie sie für Git-Zugriff, Host-Verbindungen und Ansible-Vault-Passwörter wieder.
OpenBao
OpenBao als Quelle für wiederverwendbare Zugangsdaten verwenden.
AWS Secrets Manager
In AWS Secrets Manager verwaltete Zugangsdaten anbinden.
Azure Key Vault
Vault-Geheimnisse mit der Geheimnissynchronisierung in den Key Store importieren.
Devolutions Server
In Devolutions Server verwaltete Zugangsdaten verwenden.
CyberArk
Ihre mit CyberArk verwalteten Geheimnisse an die Automatisierung anbinden.
Benötigen Sie eine andere Quelle? Lesen Sie Zugangsdaten aus Umgebungsvariablen oder Dateien des Servers, synchronisieren Sie Vault-Geheimnisse in den Key Store oder verwenden Sie Geheimniswerte neben gemeinsamer Konfiguration in Variable Groups.
Zugangsdaten erstellen, anbinden und wiederverwenden
Speichern Sie einen benannten Schlüssel oder Zugangsdaten aus Benutzername und Passwort im integrierten Key Store. Verwenden Sie den Eintrag wieder, ohne den Wert in Ihren Automatisierungscode aufzunehmen.
Verbinden Sie einen externen Vault über seine Adresse und Authentifizierungseinstellungen. Wählen Sie Lesezugriff, wenn Semaphore ausschließlich Secrets abrufen soll.
Wählen Sie die zu importierenden entfernten Pfade, legen Sie ein Namenspräfix fest und wählen Sie ein automatisches Synchronisierungsintervall. Halten Sie die importierten Key-Store-Einträge mit ihrer Quelle synchron.
Nutzen Sie die benötigten Zugangsdaten über Repository-, Inventar- und Ansible-Vault-Verweise des Jobs. Die Vorlage hält die Einrichtung für die nächste Ausführung bereit.
Hinterlegen Sie API-Tokens und Passwörter auf der Registerkarte Secrets der Gruppe. Verknüpfen Sie die Variable Group mit den Task Templates, die sie benötigen.
Die Herkunft der Job-Zugangsdaten wählen
Benannte Zugangsdaten, auf die die Vorlage über ihren Namen verweist
Der Key Store enthält die für einen Vorgang tatsächlich benötigten Zugangsdatenarten: SSH-Schlüssel und Anmeldedaten für verwaltete Hosts, Zugriff auf private Git-Repositories, sudo-Passwörter und Ansible-Vault-Passwörter. Eine Vorlage verweist auf den Eintrag. Verantwortliche konfigurieren und lesen damit einen Namen, während der Wert außerhalb des Repositories und des Task-Formulars bleibt. Lokale Werte werden bei konfigurierter Zugriffsschlüssel-Verschlüsselung in der Datenbank verschlüsselt. Diese Konfiguration und ihre Wiederherstellung gehören deshalb zum Sicherungsverfahren und sind keine optionale Einstellung.
Einen Wert zur Ausführungszeit vom Server auflösen
Umgebungs- und Dateiquellen ermöglichen einem Key-Store-Eintrag, seinen Wert bei Bedarf vom Semaphore-Server zu lesen, statt eine Kopie in der Datenbank zu speichern. Nutzen Sie diesen Weg, wenn ein anderer Prozess bereits aktualisierte Zugangsdaten auf dem Host ablegt: Nach der Rotation der Quelle verwendet der nächste Task den neuen Wert, ohne dass jemand eine Vorlage bearbeiten muss. Der Semaphore-Server löst diese Quellen auch auf, wenn ein entfernter Runner den Task ausführt; die Datei muss daher nicht auf dem Runner liegen. Dateiquellen verwenden das konfigurierte Geheimnisverzeichnis und das dokumentierte JSON-Format. Auch SSH- und Anmeldeeinträge benötigen dieses Format anstelle einer reinen Schlüsseldatei.
Key-Store-Zugangsdaten in Variable Groups verwenden
Variable Groups verbinden gemeinsame Konfiguration mit Geheimniswerten. Referenzieren Sie für eine geheime Eingabe gespeicherte Zugangsdaten, statt sie in jedem Job zu duplizieren. Übergeben Sie die Gruppe an Ansible, Terraform, OpenTofu oder ein Skript mit den vom jeweiligen Tool erwarteten Variablennamen.
Ihren bestehenden Secret Manager anbinden
Verwenden Sie mit Pro Geheimnisse aus HashiCorp Vault oder OpenBao. Enterprise ergänzt unterstützte Anbindungen wie AWS Secrets Manager, CyberArk und Devolutions Server. Belassen Sie das Geheimnis im verantwortlichen System und stellen Sie es Ihrer Automatisierung über die dokumentierte Provider-Konfiguration bereit.
Was der Ausführungsweg weiterhin ausgeben kann
Eine gute Speicherung kontrolliert nicht, was Ihr Code mit einem Wert tut. Ein Playbook oder Skript kann ein Geheimnis durch einen Debug-Task, ein Befehlsargument oder eine API-Antwort ausgeben; es gibt keine Garantie, dass jeder solche Wert aus dem Task-Log entfernt wird. Nutzen Sie die Funktionen des Tools selbst, etwa no_log in Ansible, prüfen Sie Fehlerausgaben ebenso wie Erfolgsausgaben und behandeln Sie Zugriff auf Logs und Exporte als Zugriff auf alles, was sie enthalten.
Kurzlebige Task-Identität verwenden, wenn ein Dienst sie unterstützt
Task-JWTs stellen eine signierte Identität für eine einzelne Ausführung bereit. Ein empfangender Dienst kann Aussteller, Zielgruppe und Claims prüfen, statt jedem Job ein langlebiges Token zu geben. Konfigurieren Sie das Vertrauensverhältnis auf beiden Seiten; gewöhnliche SSH-Schlüssel, Passwörter und Vault-Verweise bleiben für Systeme verfügbar, die sie benötigen.
Dokumentation und verwandte Funktionen
FAQ
Was gehört in den Key Store statt ins Repository?
Nutzen Sie benannte Key-Store-Zugangsdaten für private Repositories, verwaltete Hosts und Ansible-Vault-Passwörter. Halten Sie Automatisierungscode und nicht sensible Konfiguration in Git, während die Vorlage auf die benötigten Zugangsdaten verweist. Ein Verweis erleichtert Wiederverwendung und Rotation gegenüber eingebetteten Skriptwerten. Er ersetzt nicht die Kontrolle darüber, wer ausführbaren Quelltext bearbeiten darf, da dieser Code mit dem bereitgestellten Zugriff läuft.
Ist Ansible Vault dasselbe wie die Geheimnisspeicherung in HashiCorp Vault?
Nein. Ansible Vault schützt verschlüsselte Ansible-Inhalte; ein Task Template kann ein Vault-Passwort aus dem Semaphore Key Store zum Entschlüsseln verwenden. HashiCorp Vault ist eine separate externe Speicheroption für Key-Store-Geheimnisse in Pro. Die aufgezeichnete Vorabprüfung auf dieser Seite zeigt den Weg über ein Ansible-Vault-Passwort, keine Verbindung zu HashiCorp Vault. Prüfen Sie diesen externen Speicher separat mit temporären Zugangsdaten, bevor Sie ihn im Betrieb verwenden.
Wie werden lokal gespeicherte Zugangsdaten geschützt?
Lokale Key-Store-Werte werden mit dem konfigurierten Zugriffsschlüssel-Verschlüsselungsmechanismus in der Datenbank gespeichert. Richten Sie die Verschlüsselung korrekt ein, schützen Sie ihre Konfiguration und berücksichtigen Sie die Voraussetzungen zur Wiederherstellung in Ihrem Sicherungsverfahren. Verschlüsselung ruhender Daten ist ein Teil des Konzepts: Eine autorisierte Ausführung muss die Zugangsdaten weiterhin nutzen können. Schützen Sie Server, Laufzeitumgebung, administrativen Zugriff und Logs, statt einen verschlüsselten Datenbankwert als für jeden Code oder Verantwortlichen unzugänglich zu betrachten.
Welche Komponente liest Geheimnisse aus Umgebungsvariablen oder Dateien?
Die dokumentierten Umgebungs- und Dateiquellen werden vom Semaphore-Server aufgelöst, wenn ein Task den Schlüssel benötigt, auch bei Ausführung auf einem entfernten Runner. Dateiquellen müssen der Konfiguration des erlaubten Geheimnisverzeichnisses und dem dokumentierten Werteformat entsprechen. Ein späterer Task kann einen rotierten Quellwert verwenden, ohne seine Vorlage zu ändern. Eine reine Schlüsseldatei auf dem Runner implementiert diesen serverseitigen Quellenmechanismus nicht.
Kann ich HashiCorp Vault oder OpenBao anbinden?
Ja. Pro unterstützt HashiCorp Vault und OpenBao als externe Geheimnisquellen. Enterprise ergänzt weitere unterstützte Geheimnisverwaltungsanbindungen. Konfigurieren Sie den Provider und referenzieren Sie die Zugangsdaten über den Key Store, statt ihren Wert in Git zu speichern. Folgen Sie der Provider-Anleitung für Authentifizierung und Geheimnispfade und testen Sie den Job anschließend mit den vorgesehenen Zugangsdaten.
Was ändert sich bei der Rotation von Zugangsdaten?
Vorlagen verweisen auf benannte Zugangsdaten, statt in jedem Job ein eigenes Passwort oder einen Schlüssel zu hinterlegen. Aktualisieren Sie die Zugangsdaten oder ihre konfigurierte Quelle und prüfen Sie anschließend die referenzierenden Repositories und Inventare. Testen Sie nach der Rotation einen repräsentativen Task, damit Authentifizierungsfehler vor der nächsten geplanten Produktionsausführung auffallen.
Verhindert Semaphore, dass jedes Geheimnis in der Task-Ausgabe erscheint?
Verlassen Sie sich nicht auf eine allgemeine Maskierungsgarantie. Ein Playbook oder Skript kann sensible Variablen, Befehlsargumente oder API-Antworten ausgeben. Protokollieren Sie bewusst, nutzen Sie die geeigneten Funktionen des Tools zum Schutz von Geheimnissen und prüfen Sie typische Fehlerausgaben ebenso wie Erfolgsausgaben. Beschränken Sie den Zugriff auf Logs und exportierte Datensätze entsprechend ihrem Inhalt. Eine sichere Speicherung kontrolliert nicht automatisch alles, was der ausgeführte Code ausgibt.
Können mehrere Jobs denselben SSH-Schlüssel oder dasselbe Vault-Passwort verwenden?
Ja. Geben Sie den Zugangsdaten im Key Store einen Namen und wählen Sie sie überall aus, wo Repository, Inventar oder Vorlage diesen Zugangsdaten-Typ benötigt. Jobs referenzieren den konfigurierten Eintrag statt einer eigenen Kopie in Git. Verwenden Sie getrennte Zugangsdaten, wenn Zielsysteme unterschiedliche Identitäten benötigen. Task Templates ansehen.