Omgevingsvariabelen beheren met SecretsFoundry

Ik schreef eerder over de verschillende manieren om omgevingsvariabelen te beheren in mijn post hier. Om het voor ons eenvoudig te maken om met configuratie om te gaan in onze startup bij Truefoundry, hebben we een kleine tool geschreven genaamd SecretsFoundry die het voor alle applicatieteams heel gestroomlijnd heeft gemaakt om hun configuraties in Git te onderhouden. We dachten dat het nuttig zou kunnen zijn voor andere ontwikkelaarsteams en hebben daarom besloten het te open-sourcen.

Voordat ik op de details inga, is het goed om te begrijpen welk probleem SecretsFoundry oplost. Elke applicatie heeft niet-gevoelige en gevoelige configuratievariabelen die aan de applicatie moeten worden geleverd wanneer deze draait. Voor de niet-gevoelige variabelen hebben mensen de neiging om de variabelen in een bestand te plaatsen en de variabelen vervolgens in de applicatie te laden met behulp van bibliotheken zoals dotenv. Voor gevoelige variabelen slaan mensen de waarden op in secret managers zoals AWS SecretManager, Hashicorp Vault en schrijven vervolgens applicatiecode om de secrets uit de store op te halen. De andere aanpak is om een extern systeem de variabelen vanuit de secretstore in de applicatie-omgeving te laten injecteren — in welk geval het domein van env-variabelen meer een devops-verantwoordelijkheid wordt en ontwikkelaars er de controle over verliezen — wat leidt tot meer bugs en moeilijker testen wanneer er problemen optreden.

SecretsFoundry probeert de bovenstaande problemen op te lossen door het volgende te doen:

Alle gevoelige en niet-gevoelige sleutels kunnen in één bestand staan.

Voor niet-gevoelige variabelen kun je de variabelen rechtstreeks plaatsen. Voor gevoelige variabelen plaatsen we het pad in de secretstore als de waarde van die variabelen. Op deze manier vertellen we secretsfoundry hoe deze waarden moeten worden opgehaald. Een voorbeeld van zo'n bestand is:

.env-bestand

NODE_ENV = development
HOST = localhost
DB_NAME = example_app_db
DB_USER = ${aws-secret:/development/example_app/DB_USER}
DB_PASSWORD = ${aws-secret:/development/example_app/DB_PASSWORD}

In het bovenstaande voorbeeld zijn de daadwerkelijke DB_USER en DB_PASSWORD opgeslagen in AWS Secrets Manager. Ontwikkelaars kunnen het pad vermelden in het .env-bestand en secretsfoundry haalt het voor je op.

Geen applicatiespecifieke code om env-variabelen op te halen

Secretsfoundry werkt door de werkelijke waarden in de app-omgeving te injecteren voordat deze opstart, in plaats van binnen de applicatie. Dit heeft twee voordelen:

1. Geen afhankelijkheden in de applicatie en we hoeven geen bibliotheken toe te voegen aan de verscheidenheid aan verschillende talen.
2. In het geval dat secretsfoundry een bepaalde env-variabele niet kan vinden, geeft secretsfoundry zelf een foutmelding en geeft een vroegtijdig ongezond signaal aan alle deployment-systemen zoals Kubernetes. Anders is het aan de applicatie om de validatie uit te voeren en fouten af te handelen.

Ondersteuning voor meerdere secret managers

SecretsFoundry integreert met AWS Parameter Store, AWS S3, AWS SecretsManager en Hashicorp Vault voor secret-beheer. Het toevoegen van een nieuwe secret store is vrij eenvoudig en we zijn van plan om in de toekomst ondersteuning voor GCP en Azure Vault uit te breiden.

SecretsFoundry gebruiken

De manier om secretsfoundry te gebruiken is:

secretsfoundry run -c "node start.js"

of als je meerdere opdrachten in je opstartscript hebt:

secretsfoundry run -s "node run_migration_script && node start.js"

Wanneer we secretsfoundry run uitvoeren, zoekt het naar een .env-bestand in die map en drukt het de waarden van de variabelen af. Als er een -c of -s argument is, injecteert het deze in de omgeving van die applicatie. Dus als je het .env-bestand bekijkt dat we eerder hebben geschreven, levert het uitvoeren van secretsfoundry run in die map het volgende op:

secretsfoundry run

NODE_ENV = development
HOST = localhost
DB_NAME = example_app_db
DB_USER = admin
DB_PASSWORD = password

We kunnen een kleine voorbeeldapplicatie hebben in start.js die er ongeveer zo uitziet als hieronder:

secretsfoundry run -c “node start.js”

SecretsFoundry kan ook elk ander .env.<stage>-bestand laden met behulp van

secretsfoundry run — stage=<stage>

SecretsFoundry kan configuratiebestanden uit een andere map ophalen met behulp van

secretsfoundry run -p <Pad naar de configuratiemap, die de .env-bestanden bevat.>

Het kan ook een invoerpad naar een bestand accepteren dat het formaat .env / json / yaml kan hebben en de opgeloste variabelen naar een ander bestand uitvoeren. We gebruiken dit voor integratie met verschillende Kubernetes-systemen, waarover ik in een ander blog zal schrijven.

secretsfoundry run -i <Invoerbestand met variabelen (.env/json/yaml)> -o <uitvoerbestand>

SecretsFoundry heeft referenties nodig om de parameters uit de SecretStore te halen — je zult die variabelen dus handmatig aan je omgeving moeten opgeven.

Installatie en documentatie

Je kunt secretsfoundry downloaden met npm of yarn (https://www.npmjs.com/package/secretsfoundry)

npm install -g secretsfoundry

SecretsFoundry bevindt zich in deze Github repository en de documentatie is te vinden op https://truefoundry.gitbook.io/secretsfoundry.

Probeer SecretsFoundry uit en laat ons je ervaringen weten. We hebben het intern erg intensief gebruikt met AWS Parameter Store — de integratie met Hashicorp Vault is echter nog niet goed getest. Probeer het uit en laat het ons weten als je bugs vindt of functieverzoeken hebt.

Oorspronkelijk gepubliceerd op Medium