Les fuites de données sont devenues presque quotidiennes. (Sympa l’ambiance)
Et dans la majorité des cas, elles ne viennent pas d’un hack sophistiqué, mais d'un simple secret mal protégé et en regardant mes serveurs et ses .env de partout, je me suis dis que je n’étais pas mieux.
Il est nécessaire, d'une part, d'éviter l'escalade de privilèges sur nos serveurs, mais également d'empêcher qu’un hacker puisse facilement récupérer nos clés en copiant un simple fichier ou en affichant nos variables d’environnement en ligne de commande.
Le but c'est aussi de mieux structurer son serveur. Personnellement, j'en avais marre de voir des fichiers sensibles se balader un peu partout, de ne plus savoir où chercher entre les environnements de développement et de production, etc.
Et Infisical, c'est typiquement le genre de solution facile à mettre en place qui se charge de toute cette partie.
Infisical est aux serveurs ce que Bitwarden est aux humains.
Il va gérer nos secrets de façon centralisée et sécurisée, comme un gestionnaire de mots de passe, mais pour un usage côté serveur.
1. Installation
// Docker compose
curl -o docker-compose.prod.yml [https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml](https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml)
// Env
curl -o .env [https://raw.githubusercontent.com/Infisical/infisical/main/.env.example](https://raw.githubusercontent.com/Infisical/infisical/main/.env.example)-o permet de renommer le fichier directement
Dès le début tu peux changer les deux secrets les plus importants dans ton .env :
Puis dans ton docker-compose, persiste le volume sinon au prochain redémarrage de ton container, tu n'auras plus rien et ce serait embêtant.
Et par la suite en prod tu feras une copie d'une part de tes deux clés et de ta base de données ! (Et pas sur le même serveur s'il te plait !!!!).
2. Configuration
On démarre tout ça : docker compose -f ./docker-compose.prod.yml up -d puis on se rend sur localhost au port définit dans le docker-compose.
Tu peux aussi le faire via port forwarding comme je l'explique dans l'article les backups.
Pas besoin d'un dessin : on renseigne les champs du super admin.
On se dirige ensuite vers la partie "admin" de Infisical et on va bloquer l'inscription des nouveaux utilisateurs.
Pour ça dans tu te rends dans Général ⇒ "Allow User signups" et tu switch sur "disabled" pour éviter que n’importe qui puisse y avoir accès.
Dans le dashboard, il y a 2 grosses zones :
La zone verte c'est la partie de l’organisation qui par défaut lors de la création du premier user s'appelle "Admin Org". On pourra le changer par la suite.
La zone bleue c'est la zone où l'on a atterrit à notre première connexion, où on règle les paramètres lié à la solution, le SSO si activé depuis "Server Console" etc …
Il y a pléthore de fonctionnalités qui sont bloquées par la version free mais rien de nécessaire pour un usage perso ou freelance. Quand l'équipe commencera à devenir conséquente oui il faudra prévoir d'upgrade vers un plan suivant.
Pour changer le nom de l’organisation, on se rend dans Settings. Et on change directement le nom.
Pour continuer on va créer un projet où y stocker nos secrets. Pour ça on va dans "Overview" ⇒ "Add New Project".
Ensuite dans Project Name et Description tu mets ce que tu veux mais l'important c’est de sélectionner "Secrets Management".
On a maintenant une organisation avec un projet à l'intérieur que l'on peut voir ici :
Si on clique dessus, on rentre dans notre coffre avec des menus propres à lui :
Si tu te rends dans "Settings" ⇒ "Secrets Management", tu peux t’apercevoir que par défaut Infisical crée 3 environnements pour un projet :
- Développement
- Staging
- Production
Dans "Approvals", si tu bosses en équipe, tu peux aussi y mettre des règles comme sur Github avec des Pull Requests et des process de validation afin qu'il n’y ait pas de modification de secrets sans vérification par exemple.
Enfin bref, je te laisserai bidouiller dans l'interface, elle est super fluide et bien pensée (même si comme je l'ai déjà mentionné plus en haut : on est pas forcément au courant qu'une feature est en premium jusqu’à ce que l'on clique dessus).
L'avantage d'Infisical en plus de son interface web, c’est évidement sa CLI que l'on retrouve sur notre machine afin d'avoir accès à nos secrets.
Car oui on peut utiliser Infisical uniquement pour son interface graphique, le stockage des secrets etc … mais l'énorme intérêt c’est que l'on va pouvoir avoir accès à nos secrets avec un terminal pour les utiliser dans nos commandes.
3. La CLI
Pour ça, on l'installe sur notre machine où l'on souhaite pouvoir accéder à nos secrets.
Quasiment tous les OS sont représentés ici.
Une fois installé, on se connecter à notre instance Infisical avec infisical login .
On choisit Self-Hosting puis on renseigne le domaine (pour nous c’est localhost:port).
A partir de là on va avoir besoin de fournir un token de connexion en se rendant sur le navigateur.
On clique sur notre organisation et hop ! On est connecté !
Si tu testes Infisical à distance sur un serveur et que tu n'as pas accès à une page web, alors Infisical te permettra aussi de te connecter en CLI avec infisical login -i et tu seras invité à rentrer tes credentials.
Tu pourras retrouver les infos stockées sur ta machine dans ton répertoire perso ~/.infisical/infisical-config.json.
{
"loggedInUserEmail": "tonemail",
"LoggedInUserDomain": "http://localhost:9090/api",
"loggedInUsers": [
{
"email": "tonemail",
"domain": "http://localhost:9090/api"
}
],
"domains": [
"http://localhost:9090"
]
}Maintenant connecté, on va pouvoir utiliser notre vault créé précédement.
Pour ça : infisical init et on sélectionne notre projet.
La commande infisical secrets on a accès nos secrets enregistrés :
Par défaut, c'est l'environnement de dev mais on peut rajouter un flag pour sélectionner un autre environnement : infisical secrets --env prod .
Pour enregistrer un nouveau secret, c'est avec la commande suivante : infisical secrets set KEY=VALUE .
On peut enchainer les secrets les uns à lui suite des autres si on veut en enregistrer plusieurs dans la même commande : infisical secrets set KEY=VALUE KEY=VALUE .
On rajoute --env nomDeLenv pour l'enregistrer dans un autre environnement.
Quand tu fais une commande infisical secrets le problème c'est qu'elle reste dans l'historique. Pense à supprimer l'entrée de ton terminal sinon ça ne sert à rien.
On vérifie que les secrets sont bien enregistrés : 
Et dans l'interface web, c’est encore plus visuel :
A présent on a nos secrets dans notre coffre et on va pouvoir les utiliser à notre guise dans nos commandes.
Si j'ai besoin d'un secret durant l'utilisation d'un script bash, je peux faire référence à une variable d'environnement et lancer un wrapper avec infisical pour hydrater ponctuellement celle-ci.
On crée un script avec nano ./script.sh:
#!/bin/bash
echo "Affichage de mon token $API_BACKEND_TOKEN"chmod +x ./script.sh et éxecutons le.
$API_BACKEND_TOKEN ne fait référence à aucune variable d'environnement nommée API_BACKEND_TOKEN sur mon système (pas dans Infisical, mais sur mon système).infisical run -- ./script.sh.
Infisical a wrappé avec infisical run -- la commande sur sa droite pour hydrater les variables d'environnement du projet.
Je rajoute l'env de prod au besoin infisical run --env prod -- ./script.sh si j'ai besoin des variables de prod.
On peut maintenant utiliser des secrets dans des scripts de backup ou d'authentification etc sans à stocker nos secrets à l'air libre.
Si tout de suite après dans mon terminal je fais echo API_BACKEND_TOKEN, il ne va rien trouver car le wrapper injecte uniquement la variable le temps de la durée du script.
Sur certaines commandes on peut parfois avoir besoin de recharger les variables si jamais leurs valeurs changent mais que le script est encore en cours. Pour ça on a une sorte de watchdog mis à dispo : infisical run --watch -- ./script.sh.
Pour ça, il nous faut un script qui tourne en boucle donc on va le modifier :
#!/bin/bash
while true; do
echo "Affichage de mon token $API_BACKEND_TOKEN"
sleep 5
donePuis on lance le watch avec infisical run --watch -- ./script.sh.
Pendant ce temps, on modifie le secret : infisical secrets set API_BACKEND_TOKEN=MaSuperValeur
Automatiquement le watchdog va détecter le changement et venir récupérer la nouvelle valeur pour l'injecter dans le script sans l'arrêter.
Cette technique peut être super utile quand on lance un service systemd par exemple ou un serveur nodeJS.
Par contre il faudra y aller avec parcimonie sur cette commande car le watch prend dans la ram de la machine pour rester éveillé !
Pour terminer sur une dernière petite pépite de Infisical, c'est le scan de dossier Git pour trouver des secrets en clair.
Qui ne s'est pas déjà retrouvé avec une alerte de Github Guardian parce qu'un secret était commité en clair dans un dépôt …
Et baaaah avec Infisical ça n’arrivera plus !!!
Démonstration !
On se met dans un projet où l’on a un dépôt Git puis on lance le scan avec infisical scan -v : 
Sans faire gaffe … j’avais oublié dans mon gitignore un .env.dev sur un projet. Une erreur d'inattention ça peut arriver (A l'époque j'avais été alerté par Github Guardian et c'était juste un APP_SECRET de .dev donc sans aucun stress).
C'est ce genre de petit tool que l'on peut inclure en CI/CD afin d’éviter de push un truc par erreur et qui pourrait s'avérer lourd de conséquences si jamais on ne s'en rend pas compte tout de suite ! Grâce à lui c'est de l’histoire ancienne.
Pour la découverte on l'a installé en local, mais bien entendu que l'intérêt d’un tel outil c'est qu'il soit disponible pour les clients qui vont le consommer.
Par conséquent, on l'installera plus tard sur une machine accessible via un réseau privé type VPN au vu de la sensibilité du contenu.
De mon point de vue l'énorme intérêt à utiliser Infisical c’est d'arrêter d'utiliser des .env dans mes docker-compose.yaml.
Dans un article précédent j'avais présenté le Vault de Symfony pour gérer les .env.
Evidément tu peux aussi l'héberger ailleurs que chez toi pour y avoir accès sur un serveur.
On pourrait se dire au premier abord qu'Infisical fait doublon mais il n'en est rien. Quand on travaille pour un client en tant que freelance, on va avoir besoin de commiter les secrets chiffrés pour que si jamais un autre nous remplace, il soit opérationnel dès le Git tant qu'il possède la clé de déchiffrement obtenu par un autre canal.
Maintenant j'ai un serveur beaucoup plus rangé et sécurisé !
