Verwaltung von Umgebungsvariablen mit SecretsFoundry

Ich habe früher in meinem Artikel über die verschiedenen Arten der Verwaltung von Umgebungsvariablen geschrieben Post hier. Um uns den Umgang mit der Konfiguration in unserem Startup unter zu erleichtern Echte Gießerei, wir haben ein kleines Tool namens SecretsFoundry geschrieben, das es wirklich allen Anwendungsteams ermöglicht hat, ihre Konfigurationen in Git zu verwalten. Wir dachten, es könnte für andere Entwicklerteams nützlich sein und entschieden uns daher quelloffen es

Bevor ich auf die Details eingehe, ist es gut zu verstehen, welches Problem SecretsFoundry löst. Jede Anwendung hat einige unempfindliche und sensible Konfigurationsvariablen, die der Anwendung zur Verfügung gestellt werden müssen, wenn sie ausgeführt wird. Bei den nicht sensitiven Variablen neigen die Leute dazu, die Variablen in eine Datei zu legen und die Variablen dann mithilfe von Bibliotheken wie dotenv in die Anwendung zu laden. Bei nicht sensitiven Variablen speichern die Benutzer die Werte entweder in einigen geheimen Managern wie AWS SecretManager, Hashicorp Vault und schreiben dann Anwendungscode, um die Geheimnisse aus dem Speicher abzurufen. Der andere Ansatz besteht darin, dass ein externes System die Variablen aus dem Secretstore in die Anwendungsumgebung einschleust — in diesem Fall fällt die Domäne der env-Variablen eher in die Verantwortung von DevOps und die Entwickler verlieren die Kontrolle darüber — was zu mehr Bugs und einem schwierigeren Debugging führt, wenn Probleme auftreten.

SecretsFoundry versucht, die oben genannten Probleme wie folgt zu lösen:

Alle sensiblen und nicht sensiblen Schlüssel können in einer Datei gespeichert werden.

Bei nicht sensitiven Variablen können Sie die Variablen direkt eingeben. Bei sensitiven Variablen geben wir den Pfad in den Secretstore als Wert dieser Variablen ein. Auf diese Weise teilen wir Secretsfoundry mit, wie diese Werte abgerufen werden sollen. Ein Beispiel für eine solche Datei wäre:

.env-Datei

NODE_ENV = Entwicklung
HOST = Lokaler Host
DB_NAME = beispiel_app_db
DB_USER = $ {aws-secret: /development/example_app/db_user}
DB_PASSWORD = $ {aws-secret: /development/example_app/db_password}

Im obigen Beispiel werden die tatsächlichen DB_USER und DB_PASSWORD in AWS Secrets Manager gespeichert. Entwickler können den Pfad in der .env-Datei angeben und secretsfoundry wird ihn für Sie abrufen.

Kein anwendungsspezifischer Code zum Abrufen von Umgebungsvariablen

Secretsfoundry funktioniert, indem es die tatsächlichen Werte in die App-Umgebung einfügt, bevor sie gestartet wird, und nicht in der Anwendung. Das hat zwei Vorteile:

1. Keine Abhängigkeiten in der Anwendung und wir müssen keine Bibliotheken für die Vielzahl verschiedener Sprachen hinzufügen.
2. Falls secretsfoundry eine bestimmte env-Variable nicht finden kann, gibt Secretsfoundry selbst einen Fehler aus und sendet ein frühes ungesundes Signal an alle Bereitstellungssysteme wie Kubernetes. Andernfalls ist es Sache der Anwendung, die Validierung durchzuführen und Fehler zu behandeln.

Unterstützung für mehrere Geheimmanager

SecretsFoundry lässt sich in AWS Parameter Store, AWS S3, AWS SecretsManager und Hashicorp Vault für die Verwaltung von Geheimnissen integrieren. Das Hinzufügen eines neuen Secret Stores ist recht einfach und wir planen, die Unterstützung für GCP und Azure Vault in Zukunft zu erweitern.

SecretsFoundry verwenden

Secretsfoundry kann wie folgt verwendet werden:

secretsfoundry run -c „node start.js“

oder wenn Sie mehrere Befehle in Ihrem Startskript haben:

secretsfoundry run -s „Knoten run_migration_script && Knoten start.js“

Wenn wir das tun geheimer Gießereibetrieb, es sucht in diesem Verzeichnis nach einer.env-Datei und druckt die Werte der Variablen aus. Wenn es eine gibt Argument -c oder -s, es fügt sie in die Umgebung dieser Anwendung ein. Wenn Sie also die zuvor geschriebene Datei .env in Betracht ziehen, wird das Ausführen von secretsfoundry run in diesem Verzeichnis Folgendes ausgeben

secretsfoundry run

NODE_ENV = Entwicklung
HOST = Lokaler Host
DB_NAME = beispiel_app_db
DB_USER = Administrator
DB_PASSWORD = Passwort

Wir können eine kleine Beispielanwendung in start.js haben, die ungefähr so aussieht wie folgt:

secretsfoundry run -c „node start.js“

SecretsFoundry kann auch jede andere .env laden. <stage>Datei mit

secretsfoundry run — stage= <stage>

SecretsFoundry kann Konfigurationsdateien aus einem anderen Verzeichnis abrufen mit

secretsfoundry run -p <Pfad zum Config-Verzeichnis, das die .env-Dateien enthält. secretsfoundry run -p

Es kann auch den Eingabepfad zu einer Datei verwenden, die im Format.env/json/yaml vorliegen kann, und die aufgelösten Variablen in eine andere Datei ausgeben. Wir verwenden dies für die Integration mit verschiedenen Kubernetes-Systemen, über die ich in einem anderen Blog schreiben werde.

<Input file containing variables (.env/json/yaml) >secretsfoundry run -i -o <output_file>

SecretsFoundry benötigt Anmeldeinformationen, um die Parameter aus dem SecretStore abzurufen. Sie müssen diese Variablen also manuell für Ihre Umgebung bereitstellen.

Installation und Dokumentation

Sie können secretsfoundry mit npm oder yarn herunterladen (https://www.npmjs.com/package/secretsfoundry)

npm install -g secretsfoundry

SecretsFoundry befindet sich darin Github-Repository und seine Dokumente finden Sie unter https://truefoundry.gitbook.io/secretsfoundry.

Probieren Sie SecretsFoundry aus und teilen Sie uns Ihre Erfahrungen mit. Wir haben es intern ziemlich ausgiebig mit AWS Parameter Store verwendet — die Hashicorp Vault-Integration wurde jedoch nicht gut getestet. Probieren Sie es aus und teilen Sie uns mit, wenn Sie Fehler finden oder Funktionswünsche haben.

Ursprünglich veröffentlicht am Mittel