Zum Hauptinhalt springen Zur Navigation springen Zur Fußzeile springen
Begrenzte Zeit: Design Partner Programm. BUSINESS Plan kostenlos für immer.

Secrets verwalten

Hinterlegen Sie Deploy-Zeit-Zugangsdaten an einem Ort, den Forks nicht erreichen können. Schreibgeschützt von Grund auf.

Secrets verwalten

Das Wichtigste über Forks: Sie sind Byte-für-Byte-Kopien des verschlüsselten Images, Zugangsdaten und alles. Ein Stripe-Live-Schlüssel, ein Datenbankpasswort, ein API-Token im Repo? Der Fork erbt sie. Ihre Sandbox belastet am Ende echte Kundenkarten.

Der richtige Ort ist rdc repo secret. Zwei Übergabemodi, schreibgeschützt von Grund auf, und der Fork startet mit nichts. In diesem Tutorial setzen wir beide Arten, deployen eine App, die sie verwendet, beweisen, dass die Werte wirklich im Container ankommen, und beobachten dann, wie ein Fork nicht starten kann, weil die Secrets ihm nicht folgen.

Tutorial ansehen

Die Falle: .env im Repo

Eine .env-Datei im Repo-Image wird von jedem Fork geklont

Die meisten Teams legen .env ins Repo. Das liegt auf der Hand.

Dann forken sie.

Der Fork ist eine Byte-für-Byte-Kopie des Parent-Images. Was in .env steht, steht auch in der .env des Forks. Die Container des Forks starten. Sie lesen denselben Stripe-Schlüssel. Sie rufen dieselbe Stripe-API mit Produktionsdaten auf. Aus Sicht von Stripe ist dieser Aufruf Sie.

Das ist kein guter Tag. Das erfahre ich aus eigener Erfahrung.

Schritt 1: Ein Secret im env-Modus setzen

rdc repo secret set --name my-app --key DB_HOST --value postgres.internal --mode env

Zuerst setzen wir ein Secret im Env-Modus. Der Wert landet als Umgebungsvariable im Container. Beim ersten Schreiben braucht man keine Vorbedingungen. Erst das Überschreiben eines vorhandenen Secrets erfordert einen Nachweis.

--mode env lässt den Wert als Umgebungsvariable im Container ankommen. Erstmalige Schreibvorgänge brauchen keine Vorbedingung; beim Überschreiben eines vorhandenen Secrets muss der aktuelle Wert nachgewiesen werden.

Schritt 2: Ein Secret im file-Modus setzen

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_xxx --mode file

Setze jetzt ein Secret im File-Modus. Der File-Modus gibt den Wert nie über die Container-Umgebung preis; er schreibt ihn in eine Datei unter /run/secrets, mithilfe des Docker-Standard-Secrets-Mechanismus. Wähle den File-Modus für alles Sensible.

Der Modus file legt den Wert nie in der Containerumgebung ab. Stattdessen schreibt er ihn nach /run/secrets/stripe_key, über Dockers Standardmechanismus. Bevorzugen Sie dies für alles Sensible.

Schritt 3: Auflisten, was vorhanden ist

rdc repo secret list --name my-app

Schauen wir uns an, was wir haben. Nur Namen und Modi. Die Liste zeigt niemals Werte, egal wer fragt.

Sie sehen Namen und Modi. Keine Werte. Die Liste zeigt nie Werte, egal wer fragt.

In Compose einbinden

Öffnen Sie docker-compose.yml. Referenzieren Sie beide Modi:

services:
  api:
    image: myapp:latest
    environment:
      DATABASE_HOST: ${REDIACC_SECRET_DB_HOST}
    secrets:
      - stripe_key

secrets:
  stripe_key:
    file: /var/run/rediacc/secrets/${REDIACC_NETWORK_ID}/STRIPE_KEY

${REDIACC_SECRET_DB_HOST} ist der Modus env: renets Compose-Wrapper expandiert ihn beim Deployment aus Ihrem Secret-Store.

Der secrets:-Block ist der Modus file, über Dockers Standardmechanismus. Der Host-Pfad verwendet ${REDIACC_NETWORK_ID}, damit dasselbe Compose für Parents und Forks funktioniert. Jeder Fork hat seine eigene Netzwerk-ID.

Es kann nie zurückgelesen werden

Schreibgeschütztes Modell: get gibt einen Digest zurück, nie den Wert

Jetzt der Teil, der Menschen beim ersten Mal überrascht, mich eingeschlossen.

Schritt 4: get gibt einen Digest zurück

rdc repo secret get --name my-app --key STRIPE_KEY

Der Befehl secret get gibt einen Digest zurück, nicht den Wert, und es gibt kein Flag zum Wiederherstellen des Klartexts. Das folgt dem GitHub-Actions-Modell: Secrets sind by design write-only.

Sie erhalten einen Digest. Nicht den Wert. Es gibt kein Flag, das den Wert zurückgibt. Es gibt keinen Befehl irgendwo, der Ihnen den Klartext zurückgibt.

Das ist das GitHub-Actions-Modell: schreibgeschützt. Sie können beweisen, dass Sie ein Secret kennen, indem Sie --current <value> übergeben und die Vorbedingung prüfen lassen. Sie können Rediacc nicht bitten, Ihnen zu sagen, was es ist.

Schritt 5: Rotieren, wenn Sie vergessen

Den Wert verloren? Nicht nachschauen. Rotieren.

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_new --mode file --rotate-secret

Wenn du den Wert eines Secrets verlierst, rotiere es statt zu versuchen, ihn wiederherzustellen. Das Flag rotate-secret überspringt die Voraussetzungsprüfung, und das Audit-Log zeichnet die Änderung als bewusste Rotation auf.

--rotate-secret überspringt die Vorbedingung. Das Audit-Log markiert es als Rotation: laut, absichtlich.

Wenn Sie den alten Wert kennen, beweisen Sie es stattdessen mit --current <old-value>. Das ist der sicherere Weg. Das hat mir mehr als einmal geholfen, wenn ich mich im falschen Terminal oder auf der falschen Maschine befunden habe.

Deployen und Zustellung beweisen

Secrets, die die App nie erreichen, sind nur eine aufwendige Datenbank. Deployen und beide Zustellwege prüfen.

Schritt 6: Mit beiden Secrets deployen

rdc repo up --name my-app --machine <machine-name>

Deploye das Repo. Die Compose-Datei verwendet beide Secrets: den Env-Wert per Interpolation, den Datei-Wert per Docker-Secrets-Mount.

Schritt 7: Das env-Secret kommt an

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app printenv DB_HOST'

Gib die Variable im Container aus: postgres.internal. Das Env-Modus-Secret hat die App beim Deploy erreicht.

Der Container gibt postgres.internal aus. Die App hat den Wert wirklich bekommen, beim Deployment in ihre Umgebung expandiert.

Schritt 8: Das file-Secret kommt an

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app cat /run/secrets/stripe_key'

Lies /run/secrets/stripe_key im Container: der rotierte Wert ist dort eingehängt. Die App erhält den Klartext; nur die CLI weigert sich, ihn anzuzeigen.

Und da ist der rotierte Wert, aus /run/secrets/stripe_key innerhalb des Containers gelesen. Schreibgeschützt gilt für Menschen und die CLI; Ihre App bekommt den echten Klartext dort, wo Docker ihn verspricht.

Die Fork-Pointe

Nach dem Fork ist die Secrets-Liste leer

Erinnern Sie sich an die Falle? Das Repo forken und nachsehen.

Schritt 9: Das Repo forken

rdc repo fork --parent my-app --tag test --machine <machine-name>

Forke das Repo. Der Fork ist eine Byte-für-Byte-Kopie des verschlüsselten Parent-Images.

Schritt 10: Der Fork listet leer

rdc repo secret list --name my-app:test

Das Auflisten der Fork-Secrets gibt eine leere Menge zurück: kein Stripe-Schlüssel, kein Datenbankpasswort, kein API-Token. Der Fork kann sich nicht als Parent ausgeben, und das macht das Klonen der Produktion sicher.

Leer.

Der Fork hat keinen Stripe-Schlüssel. Kein Datenbankpasswort. Kein API-Token. Container im Fork können ${REDIACC_SECRET_STRIPE_KEY} nicht interpolieren. Die Datei unter /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY existiert nicht.

Der Fork kann nicht so tun, als wären Sie es.

Schritt 11: Der Fork kann nicht einmal starten

rdc repo up --name my-app:test --machine <machine-name>

Das Starten des Forks mit dem Parent-Compose schlägt fehl: die Secret-Datei existiert nicht unter der Netzwerk-ID des Forks, daher verweigert Docker den Bind-Mount. Produktions-Credentials folgen einem Fork nie.

Das Deployment schlägt absichtlich fehl: bind source path does not exist: /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY. Die Secret-Datei liegt unter der Netzwerk-ID des Parents, nicht des Forks, also verweigert Docker das Mounten. Der Fehler ist die Demo: Produktionszugangsdaten folgen einem Fork nicht, nicht einmal versehentlich.

Wenn Sie Secrets im Fork zum Testen benötigen, setzen Sie sie explizit mit Sandbox-Werten auf dem Fork, zum Beispiel rdc repo secret set --name my-app:test --key STRIPE_KEY --value sk_sandbox_yyy --mode file. Jetzt spricht der Fork mit der Stripe-Sandbox und startet sauber. Produktionszugangsdaten haben die Produktion nie verlassen.

Zusammenfassung

  • rdc repo secret hinterlegt Ihre Zugangsdaten außerhalb des Repo-Images.
  • Beide Modi erreichen den Container wirklich: env-Interpolation und /run/secrets.
  • get gibt einen Digest zurück, nie den Wert. Rotieren, wenn Sie vergessen; nicht nachschauen.
  • Der Fork listet leer und kann das Compose des Parents nicht einmal starten.

Secrets, denen der Fork nicht folgen kann.


Weiter: Backup und Wiederherstellung.