Umgebungsvariablen und Secrets auf Dockup

Umgebungsvariablen und Secrets verbinden den Anwendungscode mit der Produktionskonfiguration, unterliegen aber unterschiedlichen Anforderungen an Offenlegung und Lebenszyklus. Eine öffentliche API-Basis-URL kann gefahrlos in Logs erscheinen; ein Datenbankpasswort oder ein Signaturschlüssel nicht. Dockup bildet diesen Unterschied ausdrücklich ab und maskiert gespeicherte Secret-Werte in der Ausgabe von Lesevorgängen.

Konfigurationsänderungen erfordern außerdem einen Redeploy. Beim Setzen eines neuen Werts wird die gewünschte Service-Konfiguration aktualisiert, der bereits laufende Prozess behält jedoch die Umgebung, die er beim Start erhalten hat.

Was ist der Unterschied zwischen einer Variable und einem Secret?

Beide Werte gelangen als Umgebungsdaten in den Anwendungsprozess, werden operativ jedoch unterschiedlich behandelt.

Typ	Beispiel	Darf in der Ausgabe von Lesevorgängen erscheinen?	Empfohlene Handhabung
Plain-Variable	NODE_ENV=production	Ja	Überprüfbare Konfiguration
Plain-Variable	PUBLIC_API_URL=https://...	Ja	Kann in dockup.yaml liegen
Secret	DATABASE_URL=postgres://...	Gespeicherter Wert nicht sichtbar	Secret-Befehl oder CI-Store
Secret	JWT_SIGNING_KEY=...	Gespeicherter Wert nicht sichtbar	Rotieren und Zugriff beschränken
Secret	DOCKUP_TOKEN=...	Niemals als App-Konfiguration speichern, sofern nicht erforderlich	Authentifizierung auf Prozessebene

Markiere einen Wert als Secret, wenn seine Offenlegung Zugriff, Identitätsvortäuschung, Entschlüsselung, Signaturen oder laterale Bewegungen ermöglichen würde. „Das Frontend enthält den Wert bereits“ ist ein Hinweis darauf, dass es sich um öffentliche Konfiguration und nicht um ein Secret handelt.

Lege Secrets nicht in die Versionsverwaltung, in dockup.yaml, Beispielausgaben, Screenshots, Agent-Prompts oder Issue-Beschreibungen. Ein redigierter Platzhalter ist sicherer als ein realistisch aussehendes Token, da kopierte Beispiele leicht zur Produktionspraxis werden.

Wie setzt und überprüft man die Umgebungskonfiguration?

Liste die aktuellen Schlüssel für ein genau bestimmtes Ziel auf:

dockup env list -s production/api --json

Die Antwort enthält jeden Schlüssel, die Information, ob es sich um ein Secret handelt, sowie den Wert, sofern dieser nicht geschützt ist.

Setze eine gewöhnliche Variable:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

Setze ein Secret aus der Umgebung der aktuellen Shell:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Entferne einen veralteten Wert:

dockup env remove OLD_FEATURE_FLAG \
  -s production/api \
  --json

Importiere eine Datei im .env-Format gesammelt:

dockup env import .env.production \
  -s production/api \
  --json

Verwende --secret beim Import nur, wenn jeder importierte Wert als Secret behandelt werden soll. Gemischte Dateien lassen sich schwerer überprüfen und führen häufig dazu, dass harmlose Konfiguration überklassifiziert oder Zugangsdaten nicht als Secret klassifiziert werden. Trenne sie nach Möglichkeit.

Die genaue Befehlsoberfläche wird in der Dockup CLI-Referenz gepflegt.

Warum ist nach Konfigurationsänderungen ein Redeploy erforderlich?

Umgebungsvariablen werden beim Start eines Prozesses gelesen. Durch die Aktualisierung der Plattformkonfiguration wird der Speicher eines laufenden Node.js-, Python-, Go- oder anderen Prozesses nicht verändert. Der Service muss einen neuen Container mit der neuen Umgebung starten.

Die korrekte Reihenfolge lautet:

dockup env set FEATURE_FLAG=on \
  -s production/api \
  --json

dockup deploy production/api --wait --json

--wait macht den zweiten Schritt überprüfbar. Das Standard-Timeout beträgt 900 Sekunden, Exit 0 bedeutet Erfolg, und Fehler liefern einen Wert ungleich null mit strukturierten Codes zurück.

Dockups Blue-Green-Prozess ohne Ausfallzeit startet die neue Version, wendet das Health Gate an und verschiebt erst danach den Traffic. Dadurch wird verhindert, dass der aktuelle Container vor Ort mit einer nicht überprüften Konfiguration neu gestartet wird.

Wenn eine Secret-Rotation sowohl Producer als auch Consumer ändert, muss die Kompatibilität geplant werden. Wird ein Datenbankpasswort rotiert, bevor die Anwendung den neuen Wert erhält, kann es zu einem Ausfall kommen. Verwende eine Übergangsphase, die Unterstützung für zwei Schlüssel oder eine geordnete Änderung, sofern das externe System dies zulässt.

Die Bereitstellungsmechanik wird in Deployments ohne Ausfallzeit erklärt.

Wie senkt Secret-Maskierung das Risiko durch Agents?

Coding-Agents fassen die Ausgabe von Befehlen häufig zusammen. Ein Tool, das gespeicherte Secrets zurückgibt, macht aus einer harmlosen Anfrage wie „aktuelle Konfiguration anzeigen“ die Offenlegung von Zugangsdaten.

Dockup maskiert Secret-Werte. Der Agent kann sehen, dass DATABASE_URL existiert und als Secret markiert ist, aber die gespeicherte Verbindungszeichenfolge nicht auslesen. Er kann den Wert ersetzen, wenn der Benutzer über eine sichere Umgebung einen neuen Wert bereitstellt.

Das ermöglicht eine sicherere Anweisung:

Bestätige, dass die erforderlichen Secret-Schlüssel vorhanden sind, gib ihre Werte jedoch niemals aus. Wenn ein Wert geändert werden muss, lies ihn ausschließlich aus der Prozessumgebung und gib nur den Namen des Schlüssels zurück, nicht das Secret.

Die Secret-Maskierung sollte sich auch auf Diagnosedaten erstrecken. Vermeide:

printenv

in einem Agent-Transcript, obwohl der PRO-Befehl exec einmalige Container-Befehle ausführen kann. Bevorzuge eine gezielte Anwendungsprüfung, die das Vorhandensein, eine Längenkategorie oder einen erfolgreichen Verbindungsaufbau meldet, ohne den Wert offenzulegen.

Der Leitfaden zu Produktionsleitplanken für AI-Agents behandelt Prompt- und Tool-Grenzen gemeinsam.

Wie sollten Secrets rotiert und geprüft werden?

Rotation ist eine kontrollierte Produktionsänderung und keine Textbearbeitung. Verwende diese Reihenfolge:

1. Erstelle oder beschaffe die neuen Zugangsdaten im zuständigen System.
2. Speichere sie in der freigegebenen CI- oder Operator-Umgebung.
3. Setze das neue Secret in Dockup, ohne es auszugeben.
4. Führe einen Redeploy mit --wait durch.
5. Überprüfe Health und Anwendungsverhalten.
6. Widerrufe die alten Zugangsdaten, sobald die neue Version aktiv ist.
7. Prüfe das Dockup-Audit-Log.
8. Dokumentiere Rotationsdatum und Verantwortlichen, ohne den Wert zu dokumentieren.

dockup audit --writes --json

Die Audit-Nachweise sollten zeigen, dass die Konfiguration geändert wurde und anschließend ein Deployment erfolgte. Sie dürfen den Secret-Wert nicht enthalten.

Berücksichtige bei Datenbankzugangsdaten Connection Pools. Bestehende Verbindungen können nach der Rotation weiterhin authentifiziert sein, während neue Verbindungen das neue Passwort verwenden. Die Überprüfung sollte eine neue Verbindung einschließen und sich nicht nur auf Anfragen stützen, die über einen alten Pool verarbeitet wurden.

Bei APIschlüsseln mit Berechtigungen solltest du den generierten Wert während der Erstellung sicher erfassen. Speichere ihn sofort im freigegebenen Secret-System, beschränke ihn auf die erforderlichen Berechtigungen und rotiere ihn, ohne ihn in der Deployment-Ausgabe erneut zu reproduzieren.

Welche Konfigurationsrichtlinie verhindert Drift?

Definiere, welche Werte in welche Quelle gehören:

Quelle	Geeigneter Inhalt
Repository-Code	Defaults, die nicht umgebungsspezifisch sind
dockup.yaml	Überprüfbare, einfache Deployment-Konfiguration
Dockup-Secret-Variablen	Zugangsdaten zur Laufzeit
CI-Secret-Store	Deployment-Token und injizierte Rotationswerte
Ausgabe der verwalteten Datenbank	Verbindungsdaten für den konsumierenden Service
Lokale .env	Nur für Entwickler bestimmte Werte, von Git ausgeschlossen

dockup.yaml apply ist standardmäßig additiv. Einfache Umgebungswerte, die nicht in der Datei enthalten sind, bleiben bestehen, bis ausdrücklich --prune verwendet wird; Secrets werden über diesen Pfad niemals entfernt. Lies dockup.yaml als Configuration as Code, bevor du mit dem Bereinigen von Manifesten beginnst.

Verwende in allen Umgebungen konsistente Schlüsselnamen, gehe jedoch nicht davon aus, dass die Werte austauschbar sind. Ein Staging-Schlüssel sollte keinen Zugriff auf die Produktion gewähren. Preview-Deployments in einem Projekt mit privatem Networking erhalten automatisch einen schreibgeschützten Datenbankbenutzer für den Zugriff auf Produktionsdaten; sie sollten standardmäßig keine Schreibzugangsdaten übernehmen.

Incident Response bei einem geleakten Secret

Wenn ein Secret in einem Transcript, Log, Commit oder Screenshot erscheint, reicht es nicht aus, es nachträglich zu maskieren. Behandle es als kompromittiert:

1. Widerrufe oder rotiere es im Quellsystem.
2. Aktualisiere das Dockup-Secret.
3. Führe einen Redeploy durch und überprüfe ihn.
4. Entferne das offengelegte Material, soweit möglich.
5. Durchsuche Audit- und Zugriffslogs nach Missbrauch.
6. Dokumentiere die Ursache und die Änderung zur Vermeidung eines erneuten Auftretens.

Das Umschreiben der Git-Historie kann die künftige Auffindbarkeit verringern, aber nicht beweisen, dass ein kopiertes Zugangsmittel verschwunden ist. Der Widerruf ist die entscheidende Maßnahme.

Checkliste für die Umgebungsprüfung

Überprüfe vor jedem Produktionsrelease, dass die erforderlichen Schlüssel vorhanden und Secret-Schlüssel als Secrets markiert sind, kein Secret committed wurde, einfache Werte zur vorgesehenen Umgebung passen und ein Redeploy Teil der Änderung ist. Prüfe anschließend Status und Uptime:

dockup status production/api --json
dockup uptime production/api --hours 24 --json

Das Monitoring läuft minütlich und umfasst die Antwortzeit im p95-Perzentil. Auch ein erfolgreiches Konfigurationsdeployment sollte auf Regressionen zur Laufzeit überwacht werden.

Für die Erstellung eines Services und die Ersteinrichtung folge Vom Git-Repository in die Produktion.

Konfiguration prüfen, ohne sie offenzulegen

Anwendungen sollten eindeutig fehlschlagen, wenn ein erforderlicher Schlüssel fehlt, Diagnosedaten dürfen den Wert jedoch nicht ausgeben. Eine Startprüfung kann beispielsweise eine Liste wie missing: ["DATABASE_URL"] oder invalid format: ["PUBLIC_URL"] melden und anschließend mit einem Exit-Code ungleich null beendet werden.

Definiere bei einem optionalen Wert den Fallback im Code und dokumentiere, ob dieser Fallback in der Produktion sicher ist. Stille Entwicklungs-Defaults – lokale Datenbank-Hosts, Debug-Modi, permissives CORS oder Testzugangsdaten – sollten nicht allein deshalb aktiviert werden, weil ein Produktionsschlüssel fehlt.

Durch diese Validierung werden Umgebungsvariablen und Secrets beobachtbar, ohne dass Logs zu einem Verzeichnis von Zugangsdaten werden.

Mehrere Services und gemeinsam verwendete Zugangsdaten bewusst verwalten

Wenn ein Secret in mehrere Services kopiert wird, entsteht eine Rotationsabhängigkeit. Bevorzuge servicespezifische Zugangsdaten, sofern das externe System dies unterstützt. Ein kompromittiertes Worker-Token sollte nicht denselben Zugriff gewähren wie die öffentliche API.

Wenn ein gemeinsamer Wert unvermeidbar ist, führe eine Liste der Verantwortlichen und Consumer. Rotiere alle Consumer in einem koordinierten Zeitfenster und überprüfe nach jedem Redeploy neue Verbindungen. Bitte einen Agent nicht, anhand von Namensähnlichkeiten „jeden Service zu finden, der diesen Schlüssel wahrscheinlich verwendet“; verwende stattdessen ein explizites Inventar und Audit-Nachweise.

Privates Networking kann die Angriffsfläche für Datenbankverkehr verringern, macht Zugangsdaten jedoch nicht überflüssig. Interne Hostnamen steuern den Pfad; die Authentifizierung steuert, wer die Datenbank verwenden darf.

Mit einem überprüfbaren Deployment starten

Klassifiziere jeden Schlüssel vor dem Setzen, überprüfe, dass Secret-Lesevorgänge maskiert werden, und nimm den erforderlichen Redeploy in dieselbe geprüfte Änderung auf.

Kostenlos bei app.dockup.ai starten. Der Free-Tarif kostet 0 $ pro Monat, umfasst ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Gibt Dockup gespeicherte Secret-Werte zurück?

Nein. Secret-Werte werden in der Ausgabe von Lesevorgängen maskiert. Schlüssel und Secret-Markierungen bleiben sichtbar, damit Operatoren überprüfen können, ob die erforderliche Konfiguration vorhanden ist.

Warum muss ich nach der Änderung einer Umgebungsvariablen einen Redeploy durchführen?

Der laufende Prozess hat seine Umgebung beim Start erhalten. Ein neues Deployment erstellt einen neuen Container mit den aktualisierten Werten und überprüft ihn über das Health Gate.

Kann ich Secrets in dockup.yaml ablegen?

Nein. Verwende dockup.yaml für einfache, überprüfbare Konfiguration und Secret-Umgebungsbefehle oder die Injektion von CI-Secrets für Zugangsdaten.

Wie importiere ich mehrere Umgebungsvariablen?

Verwende dockup env import mit einer Datei im .env-Format und dem genau angegebenen Service-Ziel. Verwende die Option import --secret nur, wenn alle importierten Werte Secrets sind.

Was soll ich tun, wenn ein Secret in einem Log offengelegt wurde?

Widerrufe oder rotiere es sofort, aktualisiere das Dockup-Secret, führe einen Redeploy durch, untersuche die Zugriffslogs und behebe den Prozess, der die Offenlegung ermöglicht hat.