⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Dans ce troisième chapitre, on va transformer notre “Passoire-Stack” en un système plus robuste en appliquant le principe de Séparation des Responsabilités.

1. Le “Coffre-Fort” local : Le fichier .env

La première étape du hardening, c’est d’extraire tout ce qui est sensible vers un fichier d’environnement. Sur macOS ou Linux, ce fichier commence par un point (.env), ce qui le rend masqué par défaut.

Création et verrouillage (Le moment “Cyber”)

Ouvrez votre terminal dans votre dossier monitoring-stack :

1
2

touch .env
chmod 600 .env

Décomposition des commandes :

  1. touch .env : Crée un fichier vide nommé .env.

  2. chmod 600 .env : C’est la commande vitale.

    • chmod (Change Mode) modifie les permissions.

    • 6 (Lecture + Écriture pour vous).

    • 00 (Aucun droit pour le groupe et les autres utilisateurs du système).

    • Pourquoi ? Si un autre utilisateur ou un processus malveillant tente de lire ce fichier, il se fera jeter. C’est le principe du moindre privilège.

Contenu du fichier

Voici à quoi ressemble mon .env (évidemment, les valeurs ci-dessous sont des exemples) :

1
2
3
4
5
6

# Identifiants Grafana
GRAFANA_ADMIN_PASSWORD=MonMotDePasseTresLongEtComplexe123!

# Configuration Alertes Mails (Posteo)
SMTP_USER=votre.email@gmail.com
SMTP_PASS=votre-mot-de-passe-application

2. Injection dans Docker Compose : L’Interpolation

Maintenant que nos secrets sont au chaud dans le .env, il faut dire à Docker d’aller les chercher. On utilise pour cela la syntaxe ${VARIABLE}.

Voici l’extrait de mon docker-compose.yml modifié :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

services:
  grafana:
    image: grafana/grafana-enterprise:latest
    container_name: grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD}
      - GF_SMTP_ENABLED=true
      - GF_SMTP_HOST=posteo.de:587
      - GF_SMTP_USER=${SMTP_USER}
      - GF_SMTP_PASSWORD=${SMTP_PASS}
      - GF_SMTP_FROM_ADDRESS=monitoring@votre-domaine.com
      - GF_SMTP_SKIP_VERIFY=false # On ne rigole pas avec le SSL

L’analyse technique :

  • ${GRAFANA_ADMIN_PASSWORD} : au moment du docker compose up, Docker va scanner le fichier .env, trouver la valeur correspondante et l’injecter dans le conteneur. Le YAML reste “propre” et peut être partagé sans risque.

  • GF_SMTP_SKIP_VERIFY=false : en cybersécurité, on évite de sauter la vérification des certificats. Si cette valeur était à true, un attaquant pourrait intercepter vos mails d’alerte via une attaque Man-in-the-Middle (MitM).

3. Le cas d’école : Alertes SMTP et Identités

Lors de la mise en place de mes alertes mail via Posteo, j’ai rencontré un défi intéressant lié à l’IAM (Identity & Access Management).

Posteo (comme beaucoup de serveurs mail sécurisés) distingue l’utilisateur qui se connecte (SMTP_USER) de l’adresse qui s’affiche sur le mail (FROM_ADDRESS).

Ce que j’ai appris :

  1. On utilise un mot de passe d’application et non le mot de passe maître. C’est une règle d’or : si votre stack de monitoring est compromise, l’attaquant n’aura accès qu’à l’envoi de mails, pas à l’intégralité de votre boîte de réception.

  2. Le SMTP_USER doit être votre adresse principale (ex: clément@pgmail.com), mais vous pouvez “signer” vos alertes avec un alias plus pro (ex: soc-alert@homelab.com).

4. La dernière barrière : Le .gitignore

C’est l’erreur classique qui a coûté des millions à certaines entreprises : oublier de dire à Git d’ignorer le fichier .env.

Créez un fichier .gitignore à la racine de votre projet :

1
2
3

.env
prometheus/data/
grafana/data/

Pourquoi c’est important ? Si un jour vous décidez de pousser votre projet sur GitHub pour montrer votre travail, Git ignorera royalement votre fichier .env. Vos secrets resteront sur votre machine, et uniquement là.

5. Vérification post-déploiement

Une fois la stack lancée avec docker compose up -d, comment savoir si nos secrets ont bien été injectés sans les afficher à l’écran ?

1

docker exec -it grafana env | grep GF_SECURITY

Décomposition :

  1. docker exec -it grafana : “Entre” dans le conteneur Grafana en mode interactif.

  2. env : Affiche toutes les variables d’environnement internes au conteneur.

  3. | grep GF_SECURITY : Filtre le résultat pour ne voir que ce qui nous intéresse.

    • Vérification : Si vous voyez votre mot de passe s’afficher ici, c’est que l’injection a réussi. Note : Dans un environnement de production ultra-sensible, on utiliserait des “Docker Secrets” pour que même cette commande ne révèle rien.

Conclusion

Le Hardening, ce n’est pas installer un logiciel miracle, c’est une somme de petits réflexes : un chmod bien placé, une variable d’environnement au lieu d’un texte en clair, et une surveillance constante des flux (SMTP).

Ma stack est désormais un peu plus “propre” d’un point de vue architectural.