Skip to content

III. Gestion de secrets

Info

Un "secret", c'est une string qui est nécessaire pour que tel ou tel truc fonctionne, mais la sécurité de ce truc repose sur le fait que cette string est protégée (chiffrée, échangée de façon secrète, etc).
Par exemple, le mot de passe de la base de données, c'est un secret.

Dans cette section on va utiliser la faeature Key Vault de Azure.

On peut stocker des secrets dans un Key Vault, et les machines qu'on crée dans Azure pourront les récupérer.

Keep it secret

Note

On aura pas besoin d'écrire à la main le password dans le fichier.
Dans la vie réelle, où on automatise beaucoup, ça évite de devoir stocker le mot de passe quelque part à l'arrache, pour le déposer à distance sur les machines.
Là c'est Azure qui garde nos secrets au chaud, et les machines peuvent les demander et les récupérer si elles y sont autorisées.
Aussi, bah le secret est maintenant stocké dans Azure, donc si on le change là, toutes les machines qui en ont besoin peuvent le récupérer (plutôt que devoir se connecter et l'écrire partout).

⚠️⚠️⚠️ Dans cette partie, on bosse que avec azure1.tp2

1. Un premier secret

Info

Là je donne juste les étapes pour avoir ce qu'on veut.
Documentez-vous pour les clics ou commandes az exacts.
Je précise qu'il sera nécessaire de refaire ça après, alors avec az, ça sera facilement répétable encore une fois, par rapport à la WebUI... wink wink

➜ Créer un Key Vault

  • il lui faut juste un nom, une location, un resource group, la vie quoi !

  • désactiver le RBAC

    • c'est une option à la création du keyvault
    • c'est l'option --enable-rbac-authorization false avec az keyvault create

➜ Créer un secret

  • on s'en fout pour le moment, phase de tests, met ce que tu veux

➜ Activer la "Managed Identity" pour votre VM azure1.tp2

  • c'est pour que ta VM ait une identité, genre qu'elle existe, dans le système d'authentification global d'Azure
  • ta VM aura alors un "Principal ID" : son identifiant unique pour les authentifications Azure

➜ Configurer une Access policy

  • c'genre les droits associés au Key Vault
  • il faut donner à la VM les droits sur le Key Vault, pour qu'elle puisse récupérer des secrets
  • elle n'a pas besoin d'ajouter ou modifier des secrets, juste de consulter

🌞 Récupérer votre secret depuis la VM

  • vous vous connectez en SSH à azure1.tp2
  • téléchargez le CLI az (suivez la doc officielle, y'a un paquet normalement)
  • puis :
# on se log automatiquement avec la Managed Identity
# genre la VM s'authentifie auprès d'Azure
az login --identity --allow-no-subscriptions

# récupération du secret
az keyvault secret show \
  --vault-name <NOM_DE_TA_VAULT> \
  --name <NOM_DU_SECRET>

Didn't expect that

2. Gérer les secrets de l'application

Bon dans l'idéal, faudrait que dès que l'app se lance, le secret soit récupéré, par l'application elle-même (dans le code Python en l'occurrence). Ptet si vous contactez le dév de l'app, il sera motivé à implémenter la feature.
Mais il paraît que c'est un connard 🐈, alors on va le faire avec nos méthodes d'admin : du script et nos ptits .service.

A. Script pour récupérer les secrets

➜ Créer un nouveau secret dans votre Key Vault

  • appelez-le DBPASSWORD (on a pas le doirt à _ dans les noms)
  • le secret c'est donc "meow" (super secret :d)
Note

Vous devriez prendre le temps d'écrire ce script à la main, en checkant des bouts de code à droite à gauche, de la syntaxe, de la doc, me demander, etc.
Zéro ChatGPT là dessus, il te le chiera évidemment en 5 secondes si tu lui demandes.

🌞 Coder un ptit script bash : get_secrets.sh

  • il commence probablement par un az login --identity
  • il récupère le secret DBPASSWORD (commande az, stocke dans une variable)

  • il l'injecte dans le fichier .env

    • commande sed ou autres
    • il remplace la valeur de DB_PASSWORD= par le secret récupéré avec la commande az
Info

Donc ton script il passe une commande az pour récupérer le secret. Il stocke sûrement ça dans une variable, genre $DB_PASSWORD.
Ensuite il passe une commande (un sed ? ou autres) pour écrire DB_PASSWORD=<LE_SECRET>. Il supprime ou remplace l'ancienne ligne, peu importe, du moment que le fichier est valide après.

🌞 Environnement du script get_secrets.sh, il doit :

  • être stocké dans /usr/local/bin sur azure1.tp2 (commande mv)
  • appartenir à l'utilisateur webapp (commande chown)
  • être exécutable (commande chmod)
  • être inutilisable par les "autres" (ni r, ni w, ni x)

➜ Au cas où j'ai besoin de préciser... TU TESTES TON SCRIPT

  • tu changes à la main la ligne DB_PASSWORD dans le .env
  • tu relances ton script
  • tu vérifies que le .env est bien mis à jour

B. Exécution automatique

Dans l'idée, il faut qu'à chaque fois que l'application se lance, le script soit exécuté, pour récupérer les secrets à jour si besoin.

C'est natif dans systemd, avec un .service d'indiquer qu'on doit lancer un truc AVANT que le service soit lancé : ExecStartPre=.

🌞 Ajouter le script en ExecStartPre= dans webapp.service

  • éditer le fichier webapp.service

    • ajouter une ligne ExecStartPre=/usr/local/bin/get_secrets.sh dans la section [Service]

  • exécuter une commande sudo systemctl daemon-reload pour indiquer au système qu'on a modifié un service

  • relancer le service webapp
Note

Ce qu'on indique en ExecStartPre= sera exécuté systématiquement avant ExecStart=.
Euh et au cas où ExecStart= indique la commande à lancer quand tu tapes systemctl start <ton_service>.

🌞 Prouvez que la ligne en ExecStartPre= a bien été exécutée

  • on le voit dans systemctl status <ton_service>
  • tu peux voir le .env mis à jour aussi si tu fais une modif manuelle avant

C. Secret Flask

Info

Flask c'est le nom du framework que j'ai utilisé en Python pour coder l'app.
Il a besoin d'un secret pour fonctionner, c'est comme ça (pour des bails d'authentification étou, mais c'est pas le sujet là).
PS : flask c tro b1

Dans le .env y'a une variable FLASK_SECRET_KEY=... CA SONNE FORT COMME UNE STRING SECRETE CA NON

Push API Key

🌞 Intégrez la gestion du secret Flask dans votre script get_secrets.sh

  • créez un nouveau secret dans le Key Vault pour stocker ça

    • vous en profiterez pour générer un nouveau secret que celui que j'ai mis
    • comme ça il sera vraiment... secret dukoo :d
    • vous utiliserez une commande shell pour générer ce nouveau secret, je la veux dans le compte-rendu

  • votre script doit récupérer ce secret aussi, et l'injecter aussi dans le .env

🌞 Redémarrer le service

  • prouver que le script a été run et que le changement de secret a fonctionné

Stylé non. Du coup si tu crées la même app à l'autre bout du monde, elle peut récupérer le même secret np, de façon sécurisée. Si tu refais ta machine, t'as pas besoin de conserver le secret j'sais pas où poru le remettre après. Si tu dév, tu stockes pas le secret dans ton dépôt git. Etc etc etc.

📁 Dans le dépôt git : votre dernière version de get_secrets.sh