L’un des défis les plus frustrants du développement d’applications aujourd’hui est la parité des environnements. Alors que ces dernières années ont montré que les outils de virtualisation et de conteneurisation comme Vagrant et Docker (et le propre outil d’état d’ActiveState) peuvent garantir que les systèmes d’exploitation et les dépendances qui alimentent l’infrastructure d’une application sont cohérents entre les environnements, les dépendances externes sont pratiquement impossibles à reproduire dans un environnement de non-production.
Dans un monde où les dépendances tierces sont devenues irréversiblement entrelacées avec la logique métier de base de presque tous les projets logiciels, il devient de plus en plus difficile de garder les environnements de développement, de mise en scène et de production cohérents entre eux. Alors que certains produits avec des sosies auto-hébergés – tels que Minio à Amazon S3 – soulagent la douleur de la gestion des déploiements multiples d’un seul service, cela ne facilite guère le défi de la gestion de la configuration à travers les environnements.
Lorsque la production, la mise en scène, le développement, la machine locale de Bob et l’environnement QE nécessitent tous un déploiement différent d’un service donné, passer des fichiers de configuration dans les deux sens, ou s’appuyer sur des conditionnels complexes pour déterminer à quel déploiement un environnement donné doit parler, devient de moins en moins pratique. Le besoin de flexibilité souligne également la difficulté de ces solutions dans un environnement à grande échelle. Que faire si, par exemple, la machine locale de Bob a besoin de parler temporairement à un service qui est réservé à l’environnement Staging ?
Variables d’environnement en Python
La configuration inter-environnements est une douleur, mais heureusement, les problèmes décrits ci-dessus sont devenus assez courants ces dernières années pour être pratiquement résolus. Grâce au soutien de la communauté open source, et à l’évangélisation des meilleures pratiques comme l’application à 12 facteurs, on est passé ces dernières années d’une gestion de la configuration des applications basée sur les fichiers à une gestion de la configuration basée sur les variables d’environnement.
Disponibles dans tous les principaux OS, les variables d’environnement sont – comme leur nom l’indique – des variables mises en œuvre au niveau de l’environnement pour définir la façon dont les applications qui s’exécutent en dessous doivent se comporter. En termes plus simples, ce sont des variables indépendantes de l’application qui sont gérées en dehors du contexte d’un processus donné. Le principal avantage de l’utilisation des variables d’environnement est que cela permet aux développeurs de définir la façon dont une application doit s’exécuter sans modifier une ligne de code.
Par exemple, si la machine locale de Bob doit parler au service CDN qui est réservé à l’environnement Staging, il peut modifier la variable d’environnement CDN_URL pour refléter ce qui est défini dans Staging sans avoir à toucher au code géré. Plus important encore, cela permet à Bob de définir des services fictifs ou internes à utiliser avec des tests unitaires et d’intégration, le tout sans avoir à écrire une seule ligne de code supplémentaire.
Définir des variables d’environnement
Bien que l’acte de définir des variables d’environnement dépende généralement du système d’exploitation, la grande majorité des langages de programmation ont abstrait ces différences grâce à l’utilisation de paquets de développement comme le projet dotenv de Python. Par exemple, plutôt que d’avoir à définir une variable d’environnement API_USER au niveau du système d’exploitation, un fichier .env gitignoré localement peut maintenir les variables d’environnement à travers les environnements de développement. Cela permet aux développeurs d’utiliser un fichier de configuration géré localement pour définir les variables d’environnement, tout en permettant la configuration via de « vraies » variables d’environnement dans les environnements de non-développement.
À titre d’exemple, voici un simple fichier .env qu’un développeur peut utiliser dans son environnement local:
APP_ENVIRONMENT=localAPP_NAME=localhostQUEUE_DRIVER=syncAPI_USER=bob
D’un autre côté, l’environnement de production peut définir ses variables d’environnement dans un Dockerfile, qui sont tous deux des méthodes valides pour maintenir les variables d’environnement.
Récupération des variables d’environnement
Qu’importe la façon dont les variables d’environnement sont définies, elles peuvent toujours être récupérées en Python en utilisant la méthode os.getenv():
import os# Get environment variablesUSER = os.getenv('API_USER')
Prenez note que, dans le cas où la variable d’environnement est indéfinie, la valeur sera par défaut None.
Démarrer avec les secrets
Maintenant, bien que les variables d’environnement soient une excellente solution pour gérer des configurations disparates entre les environnements, elles ne sont pas une solution miracle. Dans le climat de développement actuel, la sécurité doit être une priorité absolue, et les données sensibles doivent être conservées de manière sécurisée.
Malheureusement, les variables d’environnement en elles-mêmes ne sont pas sécurisées. Bien qu’elles fassent un excellent travail pour stocker les données de configuration, la façon dont nous définissons des données plus sensibles comme les mots de passe, les clés API et les clés de chiffrement devrait nécessiter plus de soin. C’est là que les secrets entrent en jeu. Cryptés au repos, les secrets ne doivent être récupérés qu’en une seule fois, selon les besoins, afin de réduire les risques de violation des données. De cette façon, même si votre hébergeur est compromis, vous pouvez être assuré que vos secrets sensibles sont bien verrouillés.
Créer &Gérer les secrets avec l’outil State
Alors, comment créer et gérer les secrets ? Bien qu’il existe un certain nombre de façons différentes d’aborder ce problème, l’outil State Tool d’ActiveState est une excellente solution pour le langage Python. Similaire à virtualenv ou pipenv, le State Tool est une interface de gestion d’environnement virtuel qui empêchera la contamination croisée des installations et des configurations Python entre les projets. Ce qui le distingue des autres outils de gestion d’environnement virtuel est son intégration à la plateforme ActiveState, permettant une interface centrale pour la gestion des configurations d’environnement et, oui, des secrets.
Avant de pouvoir profiter des capacités de gestion des secrets de l’outil State, nous devons d’abord utiliser l’outil State pour configurer un environnement virtuel dans notre répertoire de projet. Pour ce faire, identifiez d’abord le projet ActiveState avec lequel vous allez travailler (pour ce tutoriel, vous pouvez utiliser mon projet zachflower/envs-vs-secrets-demo tant que vous avez un compte gratuit ActiveState Platform, ou vous pouvez créer le vôtre). Ensuite, exécutez la commande state activate pour votre projet donné :
$ state activate zachflower/envs-vs-secrets-demo Where would you like to checkout zachflower/envs-vs-secrets-demo? /home/zach/Projects/miscellaneous/activestate-variables/zachflower/envs-vs-secrets-demoActivating state: zachflower/envs-vs-secrets-demoThe State Tool is currently in beta, we are actively changing and adding features based on developer feedback.Downloading required artifactsDownloading 1 / 1 Installing 0 / 1 0 %You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system.Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory.To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo.To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'
Comme vous pouvez le voir, la commande activate met en place l’environnement virtuel tel que défini dans votre projet ActiveState. Dans le cas où le projet n’a pas encore été configuré, un projet simple sera ensemencé avec des paramètres par défaut pour vous fournir un exemple de la façon dont tout doit s’assembler. Cette configuration est stockée dans un fichier à la racine de votre répertoire de projet appelé activestate.yaml.
Fichier de configuration pour les secrets &plus
Le activestate.yaml fichier définit un runtime de développement sous lequel votre application s’exécutera. Par exemple, celui par défaut définit un script simple qui utilise un secret, ainsi que quelques écouteurs d’événements qui exécutent des actions chaque fois qu’un événement défini se produit :
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demoscripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}events: # This is the ACTIVATE event, it will run whenever a new virtual environment is created (eg. by running `state activate`) # On Linux and macOS this will be ran as part of your shell's rc file, so you can use it to set up aliases, functions, environment variables, etc. - name: ACTIVATE constraints: os: macos,linux value: | echo "You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system." echo "" echo "Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory." echo "" echo "To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo." echo "" echo "To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'"
Bien qu’il n’y ait rien de particulièrement révolutionnaire ici, la puissance potentielle de ce fichier devrait être immédiatement évidente. Par exemple, le script suivant fournit un exemple de base de la façon d’utiliser les secrets dans le fichier de configuration:
scripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}
Lorsque la commande helloWorld est exécutée (à partir d’un état activé), elle renverra la valeur du secret user.world et, dans le cas où ce secret n’est pas encore défini, demandera une valeur :
$ helloWorldThe action you are taking uses a secret that has not been given a value yet.Name: worldDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Utilisation des secrets
Bien que l’exemple soit relativement simpliste, la véritable valeur des secrets provient des événements d’activation. Au lieu de récupérer une valeur secrète dans le contexte d’un script, les variables d’environnement peuvent être définies en utilisant les secrets récupérés sans jamais exposer ces secrets en dehors de cet environnement sécurisé :
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demo?commitID=5fd1c161-c5a4-480c-8aba-29d8ab361b42events: - name: ACTIVATE constraints: os: macos,linux value: | export WORLD=${secrets.user.world}
Maintenant, si le secret user.world est défini, alors la variable d’environnement WORLD sera définie et pourra être récupérée comme n’importe quelle autre variable d’environnement:
$ echo $WORLDworld!
En revanche, si elle n’est pas définie, alors l’utilisateur sera invité à la définir lors de l’activation de l’environnement virtuel ActiveState:
The action you are taking uses a secret that has not been given a value yet.Name: helloDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Pretty cool, non ?
Pour aller plus loin
La gestion de la configuration dans le développement d’applications est, pour la plupart, un problème résolu, mais la gestion des secrets ne l’est tout simplement pas encore. Le nombre de projets qui ont vérifié des données sensibles dans un référentiel de contrôle de version est stupéfiant, et c’est quelque chose que même des entreprises très respectées ont fait, mais grâce à l’utilisation d’une hygiène de sécurité appropriée et de produits comme State Tool d’ActiveState, garder les données de configuration sensibles en sécurité devient plus facile de jour en jour.
- Essayez-le par vous-même en créant un compte gratuit ActiveState Platform et en téléchargeant l’outil State Tool pour simplifier la gestion des secrets.
- Vous pouvez également regarder notre webinaire sur la gestion des secrets partagés à l’aide de l’outil State
Blogs associés:
Le secret de la gestion des secrets partagés
Les développeurs peuvent partager des secrets rapidement et facilement sans sacrifier la sécurité
.