Gérer les variables d'environnement et les secrets sur nos projets🔗
Introduction🔗
Dans cet article, je vous expliquerai ce que sont les variables d'environnement et les secrets dans nos projets, comment les utiliser et renseigner sur nos environnements de développement, de staging et de production.
Qu'est-ce qu'une variable d'environnement dans un contexte de projet Symfony ?🔗
Les variables d'environnement peuvent être utilisées à tout endroits dans le code de votre projet Symfony.
Elles sont accessibles via la variable globale $_ENV, $_SERVER ou via la fonction getenv().
Les valeurs par défaut sont habituellement définies dans les fichiers .env et .env.[local|dev|test|prod].
Tip
Voici les fichiers possibles, dans leur ordre de chargement, en sachant que les plus spécifiques écrasent les premiers ;
-
.env(chargé en premier) -
.env.local -
.env.[dev|test|prod] -
.env.[dev|test|prod].local(chargé(s) en dernier)
Vous trouverez plus de détails sur la documentation officielle de Symfony.
En effet l'extension des fichiers .env permet de définir dans quel mode (APP_ENV Symfony) les variables seront accessibles.
Cela permet par exemple de définir des fichiers de configuration différents, rangés par dossier,
comme ; config/packages/dev, config/packages/prod, config/packages/test, etc.
Tip
La notion d'environnement mentionnée au-dessus est celle de Symfony, et est uniquement valable dans le contexte d'un projet Symfony et son code exécuté par PHP.
Il ne faut pas confondre avec nos environnements de déploiement, définis avec la variable
APP_RUNTIME_ENV
Le fichier .env.local a le rôle spécifique dans votre application d'overrider (surcharger) les variables du fichier
.env pour celles de votre environnement local, si vous en avez le besoin.
Warning
Il ne faut jamais versionner le fichier .env.local,
car il contient des variables d'environnement spécifiques à votre environnement local,
ce qui vous permet de remplacer une valeur par une autre en fonction de vos contraintes de développement.
D'ailleurs, Symfony fournit déjà à son installation un fichier .gitignore qui contient cette ligne.
Qu'est-ce qu'un secret dans un contexte de projet Symfony ?🔗
Certaines variables d'environnement ne doivent pas être versionnées en clair dans le code source de votre projet. Cela peut concerner par exemple ; une clé d'API, un mot de passe, etc.
Symfony permet de gérer des secrets avec des commandes dédiées.
Tip
Si vous souhaitez plus d'informations concernant la gestion du vault Symfony et les commandes associées ; rendez-vous sur le site officiel de Symfony
Les secrets Symfony utilisent une paire de clés de chiffrement asymétriques (publique et privée) pour être stockés de manière sécurisée.
Gérer les clés de chiffrement🔗
La clé publique est versionnée dans nos projets et la clé privée est stockée dans un coffre-fort, notre 1password, et n'est donc pas versionnée.
Pour pouvoir générer des secrets et les déchiffrer en local, vous devez importer la clé privée dans votre 1password,
et la placer dans le dossier concerné, par exemple : /panneau-pocket/back/config/secrets/local.
Elle porte un nom de type local.decrypt.private.php
Si les clés publiques / privées n'ont pas encore été générées sur votre projet, vous pouvez le faire à l'aide de la commande ;
1 | |
Vous pouvez également rajouter cette ligne dans votre fichier .gitignore
pour ne jamais versionner la clé privée :
1 | |
Gérer les secrets🔗
Vous pouvez générer les fichiers cryptés de vos secrets avec la commande ;
1 | |
Note
La valeur du secret encryptée sera sauvegardée dans un fichier type local.NOM_DU_SECRET.{suite_de_chiffres_random}.php
Symfony CLI mettra aussi à jour le fichier local.list.php qui contiendra la liste des secrets de votre projet.
Pensez à versionner ces fichiers.
Vous pouvez dès à présent utiliser votre variable secrète cryptée, dans votre projet Symfony !!
Warning
Dans la plupart de nos contextes projets (çàd lorsque l'hébergement est géré par Rix),
les secrets sont gérés en staging et production par un Vault Hashicorp
mis à disposition par Rix.
Il ne faut alors renseigner dans le vault Symfony uniquement les valeurs de secrets pour votre environnement local.
Comment déployer une release qui introduit des variables d'environnement et des secrets ?🔗
Se connecter à un Vault Rix🔗
Les variables d'environnement et les secrets sont gérés avec les Vaults Rix, sur nos environnements de staging et de production. Il existe généralement un vault par projet et par environnement, les accès à chacun de ces vaults sont disponibles dans notre 1password, et portent des noms explicites ; comme Vault_MJC_PROD ou Vault_MJC_STAGING.
L'URL est renseignée dans 1password, c'est secrets.rix.fr/ui/vault
Si vous ne vous êtes jamais connecté à un Vault Rix, vous serez redirigé sur la page d'authentification, où vous devez renseigner (avec la method Username) un couple Username + Password liés au projet et à son environnement concerné, que vous trouverez dans 1password.
Warning
Dès que vous vous êtes connecté une fois sur un Vault Rix, vous serez redirigé sur sa page lors que vous accèderez à l'URL secrets.rix.fr/ui/vault
Pour modifier ou obtenir des variables d'environnement d'un autre projet ou contexte,
il faut bien penser à se déconnecter du Vault courant en cliquant sur l'icône avatar en haut à droite
du volet latéral gauche, puis sur le bouton Log out.
Renseigner les variables d'environnement🔗
Lors qu'une release introduit une nouvelle variable d'environnement ou un nouveau secret, ils doivent être renseignés manuellement dans ces Vaults Rix.
Tip
Certaines Pull Requests ont un label qui permet de repérer celles qui introduisent des variables d'environnement ;
(ici sur citopia-jvs/panneau-pocket)
Il est appréciable dans ce cas pour l'auteur·ice de la PR concernée de renseigner le nom de la ou des variable(s) d'environnement introduite(s) dans le corps de la PR, pour faciliter la tâche de la personne qui va créer la release et/ou la déploie.
Si jamais la variable est un secret et que vous ne souhaitez pas le renseigner dans le corps de la PR, vous pouvez donner des indications pour permettre d'en retrouver le contenu en clair.
Par exemple ; Comment récupérer la clé private sur 1password et où la placer dans le projet, et lancer la commande
1 | |
Vous pouvez le faire vous-même en suivant ces étapes ;
- Se connecter au Vault Rix du projet et de l'environnement concerné
- Dans l'arborescence de fichiers affichée, cliquer sur le fichier
{NOM_DU_PROJET+_ENVIRONNEMENT}
- Sélectionner le fichier d'environnement adéquat
- en général
.env, mais si votre projet a plusieurs instances de staging par exemple, il y aura plusieurs fichiers d'environnement (comme.env,.env1, etc.)
- en général
- Cliquer sur le bouton
Create new versionen haut à droite de l'interface
- Vous pouvez alors, soit modifier le nom d'une variable d'environnement, sa valeur, ou rajouter un couple clé/valeur
- Sauvegarder vos modifications
- Attention ! Les modifications de vos variables ne seront prises en compte sur l'environnement concerné que lors du prochain deploy
Warning
Il faut toujours redéployer l'application pour que les variables d'environnement soient prises en compte. via les commandes Make de votre projet local comme :
1 | |
Il est cependant possible de regenérer le fichier .env de votre projet
(lorsque vous êtes sur un serveur distant) avec une commande Make comme ;
1 | |
Cela implique par contre ensuite d'effectuer plusieurs tâches qui seront faîtes lors d'un déploiement, comme vider le cache,
dumper le fichier .env.local.php, restart les services et process consommant l'app PHP (ex: FPM), etc.
Tip
Vous pouvez consulter l'article dans nos Cookbooks sur nos processus de release et deploy si vous souhaitez plus d'informations sur le sujet.