Sicherer Tresor
Der Sichere Tresor speichert die Passwörter, Tokens und E-Mail-Konten, die Ihre Szenarien benötigen. Die Werte liegen im Schlüsselbund des Betriebssystems des jeweiligen Rechners – sie werden nie in die Projektdatei geschrieben, sodass ein Projekt in Git committet und mit Kollegen geteilt werden kann, ohne Zugangsdaten preiszugeben.
Jedes Projekt hat seinen eigenen isolierten Tresor: Schlüssel und Werte gelten nur für dieses Projekt.
Öffnen Sie ihn mit der Schaltfläche Tresor in der Hauptsymbolleiste.
Ein Geheimnis in einem Szenario verwenden
Verweisen Sie mit der Platzhaltersyntax auf einen Schlüssel:
{{SECRET:MY_KEY}}
Schreiben Sie ihn in einen beliebigen Textparameter – ein SQL-Passwort, ein Slack-Token, eine Teams-Webhook-URL, eine Befehlszeile. Der Platzhalter wird zur Laufzeit aufgelöst, und der echte Wert erscheint nie in der Projektdatei.
Geheimnisse werden überall aufgelöst, wo einfacher Text akzeptiert wird. {{SECRET:DB_PASSWORD}}
funktioniert daher innerhalb einer längeren Verbindungszeichenfolge genauso gut wie allein in
einem Passwortfeld.
Einträge verwalten
Der Dialog listet jeden Schlüssel mit verborgenem Wert auf. Pro Zeile können Sie:
| Aktion | Wirkung |
|---|---|
| Geheimniswert anzeigen / ausblenden | Zeigt den gespeicherten Wert vorübergehend an. |
| Bearbeiten | Öffnet Geheimnis bearbeiten, um den Wert, den Typ oder den Schlüsselnamen zu ändern. |
| Schlüssel kopieren | Kopiert den Schlüsselnamen zum Einfügen in einen {{SECRET:…}}-Platzhalter. |
| Löschen | Entfernt den Eintrag aus dem Schlüsselbund. Fragt nach einer Bestätigung. |
Hinzufügen öffnet Geheimnis hinzufügen. Dort vergeben Sie für den Eintrag einen Schlüssel, wählen seinen Typ und geben den Wert ein.
Ein Schlüssel kann auch mit leerem Wert angelegt werden. Er wird dann als not yet set angezeigt – nützlich, wenn Sie ein Projekt an einen Kollegen übergeben und die benötigten Schlüssel für ihn zum Ausfüllen auflisten möchten.
Wenn der Schlüsselbund den Schreibzugriff verweigert
Hinzufügen, Bearbeiten und Löschen eines Geheimnisses schreiben jeweils in den Schlüsselbund des Betriebssystems, und dieser Schreibvorgang kann fehlschlagen – ein gesperrter Schlüsselbund, eine Richtlinie, die den Schreibzugriff verbietet, oder gar kein laufender Schlüsselbund-Dienst.
Der Editor meldet das jetzt. Der Vorgang bricht mit einem Dialog Tresor-Fehler ab, der Der Tresor konnte nicht aktualisiert werden anzeigt, gefolgt von dem Grund, den der Schlüsselbund angegeben hat, und die Liste zeigt weiterhin, was der Tresor tatsächlich enthält.
Bis 0.24.0 schlug ein abgelehnter Schreibvorgang stillschweigend fehl: Der Dialog schloss sich einfach, und die Liste wurde neu gezeichnet, als wäre die Änderung übernommen worden. Das Szenario scheiterte dann viel später an einem leeren Geheimnis. Beim Umbenennen eines Schlüssels konnten sogar der alte und der neue Eintrag gleichzeitig verloren gehen.
Auch das Umbenennen ist jetzt sicher – Geheimnis bearbeiten schreibt den neuen Schlüssel, bevor der alte entfernt wird, sodass eine auf halbem Weg fehlgeschlagene Umbenennung das ursprüngliche Geheimnis unversehrt lässt.
Eintragstypen
Passwort
Eine einzelne Zeichenfolge – ein Passwort, ein API-Schlüssel, ein Token, eine Webhook-URL.
| Feld | Beschreibung |
|---|---|
| Schlüssel | Name, auf den Sie mit {{SECRET:KEY}} verweisen. |
| Passwort | Der Wert. Wird bei der Eingabe maskiert. |
Einträge vom Typ „E-Mail-Konto“
Strukturierte Zugangsdaten für die E-Mail-Aktionen. Ein Eintrag kann einen Teil Empfangen (IMAP), einen Teil Senden (SMTP) oder beide enthalten – füllen Sie nur den Teil aus, den Sie benötigen.
Jeder Teil beginnt mit einer Authentifizierungsmethode:
| Authentifizierungsmethode | Wann Sie sie verwenden |
|---|---|
| Basic (username + password) | Standard-IMAP/SMTP mit Passwort oder App-Passwort. |
| Outlook OAuth2 (client secret) | Microsoft-365-Postfächer über eine registrierte Anwendung. |
| Exchange (Exchangelib) | Lokale (On-Premises) oder hybride Exchange-Server. |
Felder für Basic:
| Feld | Beschreibung |
|---|---|
| E-Mail-Adresse | Die Adresse des Postfachs. |
| Benutzername | Anmeldename – meist identisch mit der Adresse. |
| Passwort | Passwort des Postfachs oder App-spezifisches Passwort. |
| Server | IMAP- oder SMTP-Host. |
| Port | Port des Dienstes. Automatisch wählt den Standardport des Protokolls. |
| StartTLS | Stuft die Verbindung per STARTTLS auf eine verschlüsselte Verbindung hoch. (SMTP) |
| SSL-Verifizierung deaktivieren | Überspringt die Prüfung des TLS-Zertifikats. Nur für interne Server mit selbstsignierten Zertifikaten. |
| Absendername | Anzeigename im Feld Von. (SMTP) |
| Absenderadresse (send-as) | Alternative Absenderadresse, um im Namen eines freigegebenen Postfachs zu senden. (SMTP) |
Felder für Outlook OAuth2:
| Feld | Beschreibung |
|---|---|
| E-Mail-Adresse | Postfach, auf das die Anwendung zugreift. |
| Client-ID | Anwendungs-ID (Client-ID) aus Ihrer Azure-App-Registrierung. |
| Client-Secret | Geheimer Wert dieser Registrierung. |
| Authority-URL | OAuth-Authority, z. B. https://login.microsoftonline.com/common. |
Verbindung testen – bzw. IMAP testen / SMTP testen, wenn beide Teile ausgefüllt sind – prüft die Zugangsdaten vor dem Speichern und meldet einen Fehler direkt im Dialog, falls etwas nicht stimmt.
Testen Sie beide Teile, bevor Sie das Szenario aufbauen. Ein Authentifizierungsproblem, das Sie hier finden, ist in einer Minute behoben; dasselbe Problem während eines geplanten Laufs um 03:00 Uhr kostet die Verarbeitung einer ganzen Nacht.
Import und Export
| Schaltfläche | Wirkung |
|---|---|
| Tresor exportieren | Schreibt alle Schlüssel samt ihren Werten in eine .vault-Datei. Dies ist auch die Datei, die Sie einem Headless-Lauf mit --vault-file übergeben. |
| Tresor importieren | Liest Schlüssel und Werte aus einer .vault-Datei in den Tresor des aktuellen Projekts ein. |
So übertragen Sie ein Projekt auf einen anderen Rechner oder auf die VM, die es unbeaufsichtigt ausführen wird.
Eine .vault-Datei enthält die Geheimnisse im Klartext. Behandeln Sie sie genau wie eine
Passwortliste: Übertragen Sie sie über einen sicheren Kanal, committen Sie sie nie in Git und
löschen Sie sie, sobald der Import abgeschlossen ist.
Fehlende Schlüssel
Wenn Sie ein Projekt öffnen, dessen Szenarien auf Schlüssel verweisen, die auf diesem Rechner nicht vorhanden sind, teilt Ihnen der Editor mit, welche fehlen, bevor der Lauf fehlschlägt.
/img/editor/vault/missing-keys.pngAufnehmen: den Dialog für fehlende Schlüssel mit zwei oder drei Schlüsselnamen, die das Projekt benötigt, der lokale Tresor aber nicht enthält. Nicht der Fehler zur Laufzeit: Der gelieferte Screenshot war der Dialog Aktion fehlgeschlagen, der einen undefinierten Namen aus einer Aktion Text eingeben meldet. Das passiert, wenn der Lauf einen fehlenden Schlüssel erreicht – es ist nicht der Dialog, den der Editor beim Öffnen des Projekts anzeigt.
Ergänzen Sie sie mit Hinzufügen, oder übernehmen Sie sie mit Tresor importieren.
Außerhalb des Editors gibt es keinen Dialog, der angezeigt werden könnte. Ein Headless-Lauf, dem ein Geheimnis fehlt, protokolliert eine Warnung und läuft weiter, statt anzuhalten, sodass das Szenario später – und weniger offensichtlich – am leeren Wert scheitert. Lesen Sie beim ersten unbeaufsichtigten Lauf eines Szenarios das Log und nicht nur den Exit-Code.
Bewährte Vorgehensweisen
- Ein Schlüssel, ein Zweck.
PROD_DB_PASSWORDundTEST_DB_PASSWORDstatt eines gemeinsamenDB_PASSWORD– in Kombination mit Aktiviert (Test) / Aktiviert (Prod) an den Aktionen läuft dasselbe Szenario dann in beiden Umgebungen sicher. - Zugangsdaten nie direkt eintragen, auch nicht vorübergehend. Ein in einen Parameter eingegebenes Passwort wird in dem Moment in der Projektdatei gespeichert, in dem Sie Projekt speichern drücken, und bleibt danach in der Git-Historie.
- Reservierte Schlüssel. Einige interne Schlüsselnamen sind reserviert und werden mit der Meldung Eingeschränkter Schlüssel abgelehnt. Wählen Sie einen anderen Namen.
- Der Tresor gilt pro Rechner. Auf Ihrer Arbeitsstation gespeicherte Schlüssel wandern nicht
mit der Projektdatei mit – die VM, die das geplante Szenario ausführt, braucht eine eigene Kopie
oder eine exportierte
.vault-Datei, die dem Lauf mit--vault-fileübergeben wird und auf diesem Rechner überhaupt keinen Schlüsselbund erfordert.