Gestion des variables d'environnement avec SecretsFoundry

J'ai écrit sur les différentes manières de gérer les variables d'environnement plus tôt dans mon poste ici. Pour nous faciliter la gestion de la configuration dans notre startup à Véritable fonderie, nous avons écrit un petit outil appelé SecretsFoundry qui a vraiment simplifié la gestion de leurs configurations dans Git par toutes les équipes chargées de l'application. Nous avons pensé que cela pourrait être utile pour d'autres équipes de développeurs et avons donc décidé de open source ça.

Avant d'entrer dans les détails, il serait bon de comprendre quel est le problème résolu par SecretsFoundry. Chaque application possède une variable de configuration sensible et non sensible qui doit être fournie à l'application lors de son exécution. Pour les variables non sensibles, les utilisateurs ont tendance à placer les variables dans un fichier, puis à les charger dans l'application à l'aide de bibliothèques telles que dotenv. Pour les variables non sensibles, les utilisateurs stockent les valeurs dans certains gestionnaires de secrets tels qu'AWS SecretManager, Hashicorp Vault, puis écrivent du code d'application pour extraire les secrets du magasin. L'autre approche consiste à faire en sorte qu'un système externe infuse les variables du magasin de secrets dans l'environnement de l'application. Dans ce cas, le domaine des variables d'environnement relève davantage de la responsabilité des DevOps et les développeurs en perdent le contrôle, ce qui entraîne davantage de bogues et un débogage plus difficile en cas de problème.

SecretsFoundry essaie de résoudre les problèmes ci-dessus en procédant comme suit :

Toutes les clés sensibles et non sensibles peuvent être stockées dans un seul fichier.

Pour les variables non sensibles, vous pouvez placer les variables directement. Pour les variables sensibles, nous plaçons le chemin dans le secretstore comme valeur de ces variables. De cette façon, nous indiquons à secretsfoundry comment récupérer ces valeurs. Voici un exemple d'un tel fichier :

fichier .env

NODE_ENV = développement
HÔTE = hôte local
DB_NAME = exemple_app_db
DB_USER = $ {aws-secret : /development/example_app/DB_User}
DB_PASSWORD = $ {aws-secret : /development/example_app/DB_password}

Dans l'exemple ci-dessus, les fichiers DB_USER et DB_PASSWORD réels sont stockés dans AWS Secrets Manager. Les développeurs peuvent mentionner le chemin dans le fichier .env et secretsfoundry le récupérera pour vous.

Aucun code spécifique à l'application pour récupérer les variables d'environnement

Secretsfoundry fonctionne en infusant les valeurs réelles dans l'environnement de l'application avant son démarrage plutôt que dans l'application. Cela présente deux avantages :

1. Aucune dépendance dans l'application et nous n'avons pas besoin d'ajouter de bibliothèques dans la multitude de langues différentes.
2. Si secretsfoundry n'est pas en mesure de trouver une certaine variable d'environnement, secretsfoundry lui-même génère des erreurs et envoie un signal précoce de mauvaise qualité à tous les systèmes de déploiement tels que Kubernetes. Sinon, c'est à l'application de procéder à la validation et de gérer les échecs.

Prise en charge de plusieurs gestionnaires de secrets

SecretsFoundry s'intègre à AWS Parameter Store, AWS S3, AWS SecretsManager et Hashicorp Vault pour la gestion des secrets. L'ajout d'un nouveau magasin secret est assez simple et nous prévoyons d'étendre la prise en charge de GCP et d'Azure Vault à l'avenir.

Utilisation de SecretsFoundry

La façon d'utiliser SecretsFoundry est la suivante :

secretsfoundry run -c « node start.js »

ou si votre script de démarrage contient plusieurs commandes :

secretsfoundry run -s « node run_migration_script && node start.js »

Quand nous le faisons Secrets Foundry Run, il recherche un fichier .env dans ce répertoire et imprime les valeurs des variables. S'il existe un argument -c ou -s, il les intègre dans l'environnement de cette application. Donc, si vous considérez le fichier .env que nous avons écrit plus tôt, l'exécution de secretsfoundry run dans ce répertoire produira

SecretsFoundry Run

NODE_ENV = développement
HÔTE = hôte local
DB_NAME = exemple_app_db
DB_USER = administrateur
DB_PASSWORD = mot de passe

Nous pouvons avoir un petit exemple d'application dans start.js qui ressemble à ceci :

secretsfoundry run -c « node start.js »

SecretsFoundry peut également charger n'importe quel autre fichier .env. <stage>fichier utilisant

secretsfoundry run — stage= <stage>

SecretsFoundry peut récupérer les fichiers de configuration d'un autre répertoire en utilisant

secretsfoundry run -p <Chemin vers le répertoire de configuration contenant les fichiers .env. >

Il peut également prendre le chemin d'entrée vers un fichier qui peut être au format .env/json/yaml et sortir les variables résolues dans un autre fichier. Nous l'utilisons pour intégrer différents systèmes Kubernetes, dont je parlerai dans un autre blog.

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

SecretsFoundry a besoin d'informations d'identification pour obtenir les paramètres du SecretStore. Vous devrez donc fournir ces variables manuellement à votre environnement.

Installation et documentation

Vous pouvez télécharger secretsfoundry en utilisant npm ou yarn (https://www.npmjs.com/package/secretsfoundry)

npm install -g secretsfoundry

SecretsFoundry réside dans ce Dépôt Github et ses documents peuvent être consultés sur https://truefoundry.gitbook.io/secretsfoundry.

Essayez SecretsFoundry et faites-nous part de votre expérience. Nous l'utilisons assez largement en interne avec AWS Parameter Store, mais l'intégration de Hashicorp Vault n'a pas été bien testée. Essayez-le et dites-nous si vous trouvez des bugs ou si vous avez des demandes de fonctionnalités.

Publié à l'origine le Moyen