Système on Zwindler's Reflection

UserNamespaces dans Kubernetes : la feature géniale qui sert (presque) à rien

Tue, 28 Apr 2026 10:00:00 +0200

L’infographie qui m’a trigger

Depuis quelques jours, les infographies se suivent (et se ressemblent) sur Linkedin. Kubernetes 1.36 est sorti et une des features qui fait le plus parler, c’est la sortie en GA des UserNamespaces.

C’est un sujet que je suis depuis 2018 (talk The Route to rootless container à la kubecon EU de 2018) donc je peux dire que je suis content de voir l’aboutissement de ce long chemin. Cependant, je suis “profondément choqué” de voir la façon dont c’est présenté sur LinkedIn, visiblement par des gens qui n’ont aucune idée de comment ça fonctionne (et qui probablement, s’en fichent).

“Kubernetes just made root safer. Just add hostUsers: false to your Pod spec.”

Le visuel : un roi tout-puissant “inside the container” et un mendiant impuissant “outside on the host”. La promesse : “No Host Access. No Privilege Escalation. No Lateral Movement. No Node Takeover.”

C’est accrocheur.

Mais c’est surtout hyper grave de le présenter comme ça, parce que ça occulte des pans entiers de sécurité applicative et opérationnelle. Vendre hostUsers: false comme le remède universel au problème du “root dans les containers”, c’est une simplification dramatique qui va pousser des équipes à ignorer les vraies priorités de sécurité.

Ce que les UserNamespaces font réellement, sans bullshit

Le threat model : le container escape

Avant tout, de quoi parle-t-on exactement ? Un container escape (évasion de container), c’est quand un attaquant réussit à sortir de son container et à accéder directement au kernel ou au système de fichiers de l’hôte, en bypassant complètement les mécanismes d’isolation habituels.

Ce type de vulnérabilité est rare, mais des exemples bien réels existent :

CVE-2019-5736 (runc) : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 (cgroups v1) : escape via unshare dans certaines configurations
CVE-2024-21626 (runc, “Leaky Vessels”) : fuite de file descriptor vers le répertoire de travail de l’hôte

S’il y a une faille de ce type sur votre Node ET qu’un process est compromis ET s’il tourne en root dans le container ET qu’il n’a pas les UserNamespaces, l’attaquant obtient root sur l’hôte, c’est game over. Accès à tous les fichiers du Node, à tous les secrets montés par les autres pods, possibilité d’installer un rootkit ou d’exfiltrer les données de tous les tenants présents sur le Node.

Ca reste possible, mais ça fait beaucoup de “si”. Quoiqu’il en soit, c’est exactement ce scénario que les UserNamespaces adressent. Ils introduisent un mapping d’UID :

L’UID 0 dans le container est mappé vers un UID non-privilégié sur l’hôte (ex: 100000, propre à chaque pod)
Si un attaquant réussit à s’échapper du container via un exploit kernel, il se retrouve nobody sur le node, l’escape réussit, mais l’impact post-escape est dramatiquement réduit

C’est le scénario “Breakouts Lose Impact” de l’infographie, et là-dessus, l’infographie dit vrai. C’est le vrai apport de la feature.

Cas particulier : le multi-tenant même en non-root

Même sans container root, les UserNamespaces apportent aussi quelque chose dans un contexte vraiment multi-tenant (plusieurs clients différents sur le même cluster). Sans UserNamespaces, si deux pods de clients différents tournent tous les deux avec runAsUser: 1000, ils partagent le même UID 1000 sur le node. En cas d’escape sur l’un, l’attaquant peut accéder aux fichiers de l’autre pod qui ont le même propriétaire. Le mapping UID de UserNamespaces, en donnant un offset unique à chaque pod, isole les UID entre pods même à valeur identique dans le container.

Pour les clusters internes où vous contrôlez tous les workloads, ce scénario est théorique. Pour une plateforme SaaS multi-tenant ou un service de build public, c’est une vraie ligne de défense.

Prérequis techniques

Pour pouvoir bénéficier de cette feature, il y a quelques prérequis, mais la majorité des clusters à jour devraient pouvoir se qualifier.

Kernel Linux ≥ 5.19
Runtime compatible (containerd ≥ 1.7, CRI-O ≥ 1.25)
Support des idmapped mounts pour les volumes persistants (XFS, ext4, mais pas NFS dans tous les cas par exemple)
Kubernetes ≥ 1.33 (Beta), ≥ 1.36 (GA)

Ce que l’infographie exagère (et ce qu’elle oublie)

L’infographie a donc raison sur un point précis : UserNamespaces réduit l’impact d’un container escape réussi. C’est réel. Le problème, c’est qu’elle vend la feature comme solution universelle au “root dans les containers”, et là c’est n’importe quoi.

1. L’isolation de l’UID n’est pas une isolation des privilèges applicatifs

L’infographie promet “No Lateral Movement”. C’est faux (et archi faux).

Un container root avec hostUsers: false peut toujours lire le ServiceAccount Token monté dans /var/run/secrets/kubernetes.io/serviceaccount/token. Si ce token a des permissions RBAC étendues (ce qui arrive, on en reparlera peut être dans un autre article prochainement), l’attaquant peut appeler l’API Server, énumérer les ressources du cluster, et se déplacer latéralement, le tout sans jamais toucher le Node hôte.

Le mapping d’UID protège l’hôte. Il ne protège pas le cluster.

2. Un container root reste root dans le container

“Install Anything ✅” — c’est littéralement écrit dans l’infographie, présenté comme un avantage 😖.

Dans un container root (même avec UserNS), un attaquant qui prend la main peut :

Installer nmap, curl, nc pour scanner le réseau interne
Modifier les fichiers de l’application, les binaires, les configurations
Lire tous les fichiers montés en volume
Persister dans le container entre les redémarrages si le filesystem est writable

Les UserNamespaces ne retirent aucun de ces vecteurs d’attaque. Pouvoir ajouter des logiciels, c’est la garantie d’un mouvement latéral rapide (là encore).

3. C’est pas si facile, surtout pour le sto

Activer hostUsers: false casse le stockage existant dans la plupart des cas.

L’UID 0 du container est mappé sur l’UID 100000+ sur l’hôte (chaque container a son propre “offset”). Si un volume persistant (NFS, EBS, Ceph RBD) appartient à l’UID 1000, le container root ne peut ni lire ni écrire dessus. Le résultat : des Permission Denied contre intuitifs, potentiellement complexes à diagnostiquer car l’application n’a probablement pas été conçue, si elle est root, pour ne pas avoir accès à ses propres fichiers.

La solution technique existe (idmapped mounts), mais elle nécessite un kernel récent et un filesystem compatible. Voir la documentation officielle des idmapped mounts pour les détails.

4. Idem, mais pour le réseau

hostUsers: false est incompatible avec hostNetwork: true. C’est un détail, mais il piège les workloads réseau (agents de monitoring, CNI plugins, etc.).

Note : cela dit, avoir des containers en hostNetwork est un autre souci de sécurité, donc bon…

Comparaison sans bullshit : UserNS vs les alternatives existantes

Vecteur d’attaque	UserNS (root inside)	Non-root (UID 1000)	Distroless / Scratch
Impact post-escape si container escape réussi	✅ Nobody sur l’hôte	⚠️ UID 1000 sur l’hôte	⚠️ UID 1000 sur l’hôte
Isolation UID entre pods (multi-tenant)	✅ Offset unique par pod	❌ UID partagé sur le node	❌ UID partagé sur le node
Installation de malwares dans le container	❌ Trivial	❌ Possible	✅ Quasi impossible
Périmètre d’écriture dans le FS éphémère du container	❌ Tout le FS	❌ Répertoire de l’app	✅ Quasi impossible
Mouvement latéral via SA Token	❌ Possible	❌ Possible	⚠️ Potentiellement difficile
Complexité opérationnelle	❌ Parfois élevée	✅ Souvent quasi nulle	✅ Souvent faible
Compatibilité stockage existant	❌ Parfois problématique	✅ Standard	✅ Standard

La lecture de la table révèle la vraie nature d’UserNamespaces, il excelle sur exactement deux lignes :

l’impact post-escape
l’isolation UID en multi-tenant.

Sur tout le reste, non-root + distroless fait mieux, ou aussi bien, sans la complexité opérationnelle. Et ce sont ces “tout le reste” (périmètre d’écriture dans le FS, installation de malwares, mouvement latéral via SA Token) qui représentent la grande majorité des vecteurs d’attaque réels, bien plus fréquents qu’un container escape. On en reparlera dans la section Où investir son budget sécurité.

Les vrais cas d’usage

Ce serait malhonnête de tout rejeter. Il existe trois scénarios où les UserNamespaces ne sont pas une option “fainéante” mais une nécessité technique (et encore, ça se discute).

1. Build-as-a-Service (Buildah, rootless Podman)

Pour construire une image Docker, le moteur de build doit pouvoir faire des chown, chmod et mknod. Ces opérations nécessitent CAP_CHOWN et CAP_FOWNER. Avant les UserNamespaces, la solution était de lancer le pod en --privileged, ce qui est évidemment une porte ouverte sur l’hôte.

Avec hostUsers: false, le moteur de build a l’illusion d’être root pour manipuler ses fichiers, mais il est incapable d’impacter l’hôte. C’est le seul cas où “root inside” est une contrainte technique et non de la dette.

Note : Kaniko, longtemps la référence pour le build in-cluster, est archivé depuis juin 2025 et ne reçoit plus de mises à jour de sécurité. Buildah ou rootless Podman sont les alternatives actives.

Mon avis : ça peut être éventuellement utile pour les plateformes CI/CD mutualisées (GitLab Runners, Tekton) qui refusent les pods privilégiés. Mais si l’isolation est critique (plateforme publique, multi-tenant agressif), les microVMs (Kata Containers, Firecracker) offrent une garantie bien supérieure pour un overhead devenu raisonnable.

2. Multi-tenancy hostile (plateformes de code utilisateur)

Si votre métier est de faire tourner du code fourni par des inconnus (PaaS, éditeur de code en ligne, CI/CD publique), vous savez d’avance que l’utilisateur va essayer d’escalader ses privilèges. Dans ce contexte, l’UserNS est une barrière supplémentaire contre les 0-day kernel.

Mon avis : honnêtement, si l’environnement est vraiment hostile, l’UserNS seul n’est pas suffisant. Les microVMs (Kata Containers, Firecracker) offrent une isolation matérielle réelle et sont le choix correct pour ce cas. L’UserNS peut être un complément, pas un substitut.

3. Legacy “hard-coded” (Postfix, Dovecot, BIND)

Certains vieux démons UNIX démarrent en root pour ouvrir un port < 1024 ou lire des fichiers de config sensibles, puis “drop” leurs privilèges via setuid(). Ce mécanisme échoue dans un container non-root classique.

Les UserNamespaces permettent à ces processus de croire qu’ils peuvent faire leurs appels système de gestion d’identité, car ils sont root dans leur namespace.

Voici un exemple concret écrit par un collègue (thanks Louis 😘) :

apiVersion: v1
kind: Pod
metadata:
 name: postfix
spec:
 hostUsers: false # mapping UID : root dans le container → nobody sur l'hôte
 securityContext:
 runAsNonRoot: false # autorisé en PSS Restricted *uniquement* grâce à hostUsers: false
 fsGroup: 103 # GID postfix
 containers:
 - name: postfix
 image: postfix:latest
 securityContext:
 runAsNonRoot: false # idem, cf. https://kubernetes.io/docs/concepts/workloads/pods/user-namespaces/#integration-with-pod-security-admission-checks
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 seccompProfile:
 type: RuntimeDefault
 capabilities:
 drop: ["ALL"] # d'abord, on drop tout
 add:
 - SETUID  # on ajoute SETUID mais le drop de privilèges via setuid() 
 # est fait par postfix lui-même au démarrage 
 - SETGID  # idem pour les groupes
 - CHOWN  # chown sur les queues au démarrage
 - FOWNER  # opérations sur fichiers sans être propriétaire
 - FSETID  # conserver le setuid bit après écriture
 - DAC_OVERRIDE  # OBLIGATOIRE : root dans UserNS n'est pas "vrai" root,
 # les vérifications DAC ne sont pas contournées automatiquement

Ce manifest illustre plusieurs choses importantes.

D’abord, c’est très pénible de rendre une application legacy secure avec les UserNS, et il faut faire des compromis, notamment sur les capabilities (on est loin de la feature magique qui sécurise les apps root).

Ensuite, on remarque des trucs rigolos. Normalement, la policy Restricted (Pod Security Standard) interdit runAsNonRoot: false. Kubernetes fait une exception quand hostUsers: false est présent. C’est documenté ici. Sans UserNamespaces, ce pod serait rejeté par l’admission controller.

De plus, on doit ajouter la capacité DAC_OVERRIDE, ce qui est contre-intuitif. root dans un UserNS n’est pas un vrai root du point de vue du kernel pour les vérifications DAC (Discretionary Access Control). Quand Postfix essaie de faire set-permissions pour chown ses queues, le kernel vérifie quand même les permissions ; et les refuse si DAC_OVERRIDE n’est pas là. C’est exactement le genre de surprise opérationnelle invisible jusqu’au premier déploiement en production.

On notera malgré tout qu’on a pu garder readOnlyRootFilesystem: true et allowPrivilegeEscalation: false ; le legacy ne justifie pas de tout sacrifier.

Mon avis : c’est le seul cas d’usage où l’UserNS est vraiment acceptable. Pas de code tiers non maîtrisé, pas de plateforme hostile, juste du legacy bien identifié avec un plan de migration ultérieur. Les deux autres cas sont “acceptables sous conditions”, le legacy reste le plus propre des trois.

Quelques contre-arguments

Je vous vois arriver avec quelques contre arguments, donc pour gagner du temps à tout le monde, je vais faire les questions et les réponses :

“C’est de la défense en profondeur.” “Vrai, mais”… La défense en profondeur suppose qu’on a déjà posé les couches de base. Si vous n’avez pas encore migré vos images vers un user non-root, mettre de l’énergie sur l’UserNS est un non-sens. Et une fois en non-root, le gain marginal de l’UserNS est négligeable face à la complexité qu’il introduit.

“On ne contrôle pas les images tierces.” Argument un peu faible, à mon avis : si vous avez une image blackbox de votre éditeur propriétaire, qui est codée pour tourner en root, il y a de fortes chances :

soit qu’elle en ait réellement besoin pour fonctionner (typiquement, le cas pour certains outils de sécurité propriétaires)
soit qu’elle gère mal le mapping d’UID (cf. le problème de stockage). L’UserNS n’est pas une baguette magique qui rend n’importe quelle image tierce compatible et sécurisée.

“C’est un garde-fou contre les erreurs humaines.” Il est aussi facile d’oublier hostUsers: false que d’oublier runAsNonRoot: true. La vraie solution centralisée, ce sont les Pod Security Standards ou un Admission Controller (Kyverno, OPA) qui rejettent purement et simplement les pods root. C’est plus simple, plus fiable, et ça ne casse pas le stockage.

“On en a besoin pour la compliance SOC2/PCI-DSS/…” Si votre compliance exige une isolation stricte entre tenants, l’UserNS sera probablement jugé insuffisant par vos auditeurs. Les VMs ou microVMs restent le standard. Utiliser l’UserNS pour la compliance, c’est choisir l’outil le plus complexe à maintenir pour un résultat discutable.

Où investir son budget sécurité ?

Si on met de côté le marketing, voici où l’effort paye vraiment, du plus impactant au plus niche :

Priorité 1 — Images non-root + nobody (UID 65534) Passer les images en non-root, idéalement vers l’utilisateur nobody (le moins privilégié du système). Si une application est compromise sous nobody, l’attaquant ne peut pratiquement rien faire, même sur le filesystem du container. À combiner avec readOnlyRootFilesystem: true et capabilities: drop: ["ALL"].

spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 65534 # nobody
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: my-app:distroless
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop: ["ALL"]
 readOnlyRootFilesystem: true

Priorité 2 — Pod Security Standards (PSS) en mode Baseline ou Restricted Bloquer le root et les privilèges sans rien casser au niveau infra. Ça nécessite d’avoir déjà fait le point n°1, mais c’est gratuit, standard, et ça s’applique à tout le cluster via un label de namespace (et ça peut s’overrider par namespace si nécessaire). Plus de risque d’oubli possible. C’est déjà configuré par défaut sur plusieurs types de Kubernetes (je pense à Talos, mais ce n’est pas le seul).

Priorité 3 — MicroVMs (Kata Containers, Firecracker) Pour les workloads vraiment non-fiables. Isolation matérielle réelle, overhead devenu raisonnable sur les générations récentes.

Priorité 4 — UserNamespaces When all else fail. Uniquement pour les cas légitimes identifiés ci-dessus (build, legacy, multi-tenancy hostile). C’est vraiment littéralement la dernière chose à faire.

Conclusion

Les UserNamespaces dans Kubernetes 1.36 sont l’aboutissement d’un chantier qui aura pris “officiellement” cinq ans (KEP-127 date de 2021) et dont on parle quasiment depuis la genèse de Kubernetes. Pour les plateformes de build mutualisées et les SaaS multi-tenants qui font tourner du code utilisateur, c’est une brique potentiellement intéressante (notamment pour éviter qu’une app d’un client lise les apps d’un autre en cas de container escape sans élévation de privilège).

Pour le reste (c’est-à-dire 99% des clusters de production) ce n’est pas là que commence la sécurité container — et c’est précisément le problème avec ce genre d’infographie.

Les infographies LinkedIn qui vendent une sécurité sans effort sont dangereuses : “gardez votre image root de 800 Mo pleine d’outils, ajoutez juste hostUsers: false, et vous êtes protégés”. C’est exactement l’inverse de la bonne démarche. La vraie sécurité container se construit dans le Dockerfile, pas dans le PodSpec.

Si vous activez les UserNamespaces pour sécuriser une application dont vous possédez le code source, vous avez probablement raté une étape dans votre cycle de développement sécurisé.

Références

KEP-127 : Support for User Namespaces
Kubernetes docs — User Namespaces
Pod Security Standards
CVE-2019-5736 — runc : écriture dans /proc/self/exe du process hôte depuis le container
CVE-2022-0492 — cgroups v1 : escape via unshare, UserNS aide mais runAsNonRoot aussi
CVE-2024-21626 — runc “Leaky Vessels” : fuite de file descriptor vers le répertoire de travail de l’hôte
Distroless containers — GoogleContainerTools

Installation d'un Alpine Linux en mode 'headless' sur Raspberry Pi

Tue, 23 Dec 2025 08:00:00 +0200

Introduction

Pour un article qui sortira peut-être sur papier (je croise les doigts), j’avais besoin de tester différents types d’OS à installer sur un Raspberry Pi Zero 2 W.

Comme je ne connaissais ni Alpine, ni les spécificités du Pi Zero 2 W, je suis tombé sur pas mal de trucs que je ne connaissais pas.

Même si au final, l’article papier ne traite pas d’installation d’Alpine Linux (ni même ne l’utilise), je me suis dit que c’était dommage de ne pas publier cette expérience Alpine + RPi Zero, donc la voici.

Pourquoi Alpine Linux ?

Principalement pour sa légèreté et sa faible consommation de ressources. Sur un nano-ordinateur avec seulement 512 Mo de RAM, chaque mégaoctet compte. Alpine Linux est connu pour être minimaliste et aussi un peu controversé (notamment dans le monde Docker) pour le remplacement de la glibc par musl (ce qui provoque parfois des surprises).

L’objectif de cet article est d’avoir une installation headless (sans écran ni clavier) accessible en SSH via WiFi, avec une RAM optimisée au maximum.

On va voir plein de détails techniques intéressants, notamment sur la gestion de la RAM du GPU et la configuration du swap avec zswap !

Téléchargement de l’image Alpine Linux pour Raspberry Pi

La première chose à faire est de télécharger l’image, avant de pouvoir la copier sur une carte microSD qui sera insérée dans le rpi avant boot.

Coup de bol, Alpine Linux propose des images spécifiques pour Raspberry Pi, on ne va pas avoir besoin d’ajouter à la main le firmware des RPi.

On va récupérer la dernière version disponible depuis le site officiel. Exemple :

wget https://dl-cdn.alpinelinux.org/alpine/v3.23/releases/aarch64/alpine-rpi-3.23.2-aarch64.tar.gz

Cette image est spécialement compilée pour l’architecture ARM64 (aarch64) des Raspberry Pi récents (donc mon RPi Zero 2 W).

Configuration headless avec le fichier overlay

Une fois l’image flashée sur votre carte microSD (avec Raspberry Pi Imager par exemple), on va préparer le système pour un accès headless.

Alpine Linux supporte ce qu’on appelle des “overlay files” qui permettent de préconfigurer le système avant le premier boot. C’est documenté dans la documentation officielle sur l’installation headless.

Montez le contenu de votre carte microSD sur votre machine et déposez le fichier overlay à la racine de cette carte microSD :

wget https://github.com/macmpi/alpine-linux-headless-bootstrap/raw/469ee440e7d394cca0976c78f357e7a0e1c82cc4/headless.apkovl.tar.gz

Note : c’est assez flippant de monter un fichier aussi sensible provenant d’un repo github tiers (github.com/macmpi), mais Alpine Linux se veut rassurant en nous disant :

Note: The author of above repo macmpi also maintains a number of packages for Alpine Linux.

Je suis pas beaucoup plus rassuré… mais bon, c’est “officiel”

Ce fichier headless.apkovl.tar.gz configure Alpine pour :

Booter en mode DHCP
Activer SSH automatiquement
Permettre la connexion root sans mot de passe (attention à ne pas laisser ça comme ça trop longtemps !)

Pour que le Raspberry Pi se connecte automatiquement à votre réseau WiFi, créez un fichier wpa_supplicant.conf à la racine de la microSD :

cat > wpa_supplicant.conf << EOF
country=FR

network={
 key_mgmt=WPA-PSK
 ssid="mySSID"
 psk="myPassPhrase"
}
EOF

Remplacez évidemment mySSID et myPassPhrase par vos informations WiFi.

Note : Le projet alpine-linux-headless-bootstrap propose d’autres options de configuration très utiles, comme la définition d’un mot de passe root, d’une adresse IP fixe, etc. Plus d’infos dans leur README.

Premier boot et installation permanente

Une fois le premier boot effectué, connectez-vous en SSH :

ssh root@<ip_du_raspberry>

Attention : Par défaut, le mot de passe root est vide ! Mais on n’a pas besoin de changer ça si on réalise immédiatement l’installation qui suit.

À ce stade, Alpine tourne entièrement en RAM (image “live”). Pour l’installer définitivement, nous allons utiliser l’utilitaire setup-alpine dont les options sont décrites dans wiki.alpinelinux.org/wiki/Installation.

setup-alpine

Voici un petit extrait des informations demandées (somme tout assez classiques pour une install d’OS) :

Suivez les instructions, puis rebootez :

reboot

Optimisation de la RAM GPU

Par défaut sur un Raspberry Pi, une (grande) partie de la RAM est allouée au GPU pour le traitement graphique. Sur un serveur headless, ça ne sert strictement à rien.

Vérifions d’abord la RAM disponible avant optimisation :

free -m
 total used free shared buff/cache available
Mem: 417 37 325 0 55 369
Swap: 0 0 0

Seulement 417 Mo disponibles sur les 512 Mo théoriques. Voyons comment récupérer ces précieux mégaoctets.

Idéalement, on va vouloir mettre l’option gpu_mem=16 dans /boot/config.txt pour n’allouer que 16 Mo au GPU (on ne peut pas mettre moins, et il faut des multiples de 16).

Mais attention, il y a un piège !

Lorsque vous réglez gpu_mem à 16 Mo, le bootloader du Raspberry Pi tente de charger des fichiers de firmware allégés :

start_cd.elf
fixup_cd.dat

Sauf que ces fichiers ne sont pas présents sur votre partition de boot. Si on met juste gpu_mem=16 dans /boot/config.txt et qu’on reboot, le Pi refusera de démarrer (LED ACT clignotant généralement 4 fois).

Solutions pour minimiser la RAM GPU

Vous avez deux options :

Option 1 : Mettre gpu_mem=32 dans /boot/config.txt

C’est la solution de facilité (qui a dit fainéant ?), il n’y a rien à faire. Vous récupérez quand même 32 Mo de RAM.

Option 2 : Télécharger les fichiers de firmware allégés (celle que je préfère)

On n’est pas à quelques Mo près sur la carte microSD, ce qui n’est pas le cas de la RAM, où chaque Mo compte.

Si vous voulez vraiment descendre à 16 Mo, récupérez les fichiers manquants :

cd /boot
wget https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/start_cd.elf
wget https://raw.githubusercontent.com/raspberrypi/firmware/master/boot/fixup_cd.dat

Puis modifiez /boot/config.txt :

[...]
gpu_mem=16
start_file=start_cd.elf 
fixup_file=fixup_cd.dat

Après reboot, vérifiez le gain :

free -m
 total used free shared buff/cache available
Mem: 465 37 393 0 35 416
Swap: 0 0 0

On passe de 417 Mo à 465 Mo disponibles ! Soit presque 50 Mo de récupérés, ce qui représente environ 10% de RAM supplémentaire. Sur un système aussi contraint, c’est significatif.

Configuration du swap avec zswap

Sur un système avec seulement 512 Mo de RAM, il est plus que judicieux de configurer du swap. Or, Alpine Linux n’en configure pas par défaut. Je vais ici en configurer un avec zswap, qui compresse les pages de mémoire avant de les écrire sur le disque (ce qui limite la taille des accès à la carte microSD au passage).

Création du swapfile

# Créer un swapfile de 2 Go
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

Configuration persistante

Pour rendre le swapfile et zswap persistants au reboot, créez /etc/fstab :

echo "/swapfile none swap sw 0 0" >> /etc/fstab

Créez un script de démarrage pour Alpine :

cat > /etc/local.d/swap.start << 'EOF'
#!/bin/sh
swapon /swapfile
EOF

chmod +x /etc/local.d/swap.start
rc-update add local default

Enfin, éditez /boot/cmdline.txt et ajoutez à la fin (sur une seule ligne) :

zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20 zswap.accept_threshold_percent=85 zswap.shrinker_enabled=Y

Quelques explications sur ces paramètres :

compressor=lz4 : utilise lz4, rapide et efficace pour la compression
max_pool_percent=20 : zswap n’utilisera pas plus de 20% de la RAM (~93 Mo) comme cache de compression avant d’écrire sur le swapfile disque
accept_threshold_percent=85 : n’accepte de compresser que si le taux de compression attendu est d’au moins 85%
shrinker_enabled=Y : permet de libérer automatiquement la mémoire compressée si nécessaire

Le principe : zswap agit comme un cache rapide en RAM (compressé) devant le swapfile de 2 Go sur disque. Les pages sont d’abord compressées dans zswap, puis évacuées vers le disque si nécessaire.

Conclusion

Pas vraiment de conclusion à cet article, en réalité.

Je me suis pris pas mal de “murs”, ne sachant pas utiliser Alpine (au delà des usages que j’en avais fait avec Docker), et j’ai découvert quelques subtilités liées au firmware du Raspberry Pi Zero avec lequel je fais joujou depuis quelques semaines maintenant.

D’où cet article ;-)

Bon hack !

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Tue, 17 Jun 2025 18:00:00 +0200

NOTE IMPORTANTE : cet article a été généré par un LLM. Ceci va à l’encontre de règles que je me suis fixé pour ce blog (cf l’AI Manifesto).

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Je l’ai fait dans le cadre d’une expérience qui est décrite dans l’article suivant :

Réflexions sur le blogging technique à l’ère des LLMs

Cependant, je ne vous interdit pas de lire cet article ci (les informations qu’il contient sur les SLOs sont correctes), je veux juste que vous le fassiez en connaissance de cause ;-P.

Introduction : quand les devs découvrent le SRE

Suite à plusieurs discussions récentes avec des collègues développeurs, je me suis rendu compte que les concepts SRE comme les SLO, SLI et Error Budget restaient flous pour beaucoup d’entre eux. Pourtant, ces notions sont de plus en plus utilisées dans nos équipes, souvent sans qu’on prenne le temps de bien les expliquer.

C’est donc l’occasion parfaite pour revenir aux fondamentaux et expliquer ces concepts tels qu’ils ont été conçus à l’origine par Google. Car oui, il faut le rappeler : le SRE (Site Reliability Engineering) et tous les concepts associés ont été inventés par Google, plus précisément par Ben Treynor Sloss en 2003, bien avant que DevOps ne devienne populaire !

L’idée de Google était simple : et si on demandait à des ingénieurs logiciel de concevoir une équipe d’exploitation ? De cette approche sont nés des concepts révolutionnaires pour mesurer et gérer la fiabilité des services.

Fun fact : j’avais déjà abordé ces sujets dans mon talk sur le SRE en 2022, mais je me dis qu’un article dédié ne fait pas de mal pour clarifier les choses :-).

SLA vs SLO : ne mélangeons pas tout !

Avant de rentrer dans le vif du sujet, petit aparté important : ne confondez pas SLA et SLO !

Le SLA (Service Level Agreement), c’est un contrat, souvent avec des pénalités financières si pas respecté. Genre “si le service est en panne plus de X heures dans le mois, on vous rembourse Y€”. Le SLO (Service Level Objective), c’est un objectif interne que vous vous fixez pour la fiabilité de votre service.

La différence est importante : les SLA sont souvent moins stricts que les SLO pour avoir une marge de manœuvre. Si votre SLA c’est 99,9% de disponibilité, votre SLO interne sera peut-être à 99,95%.

Bon, maintenant qu’on a éclairci ça, rentrons dans le détail !

Critical User Journey : commencer par ce qui compte vraiment

Est-ce que le client est content d’utiliser le service ?

C’est LA question fondamentale. Et pour y répondre, il faut d’abord identifier les Critical User Journey (CUJ), autrement dit les parcours utilisateurs critiques.

Mais attention, quand on parle d’utilisateur dans le contexte SRE, ce n’est pas forcément l’utilisateur final ! Pour un service backend, l’utilisateur peut être le frontend qui fait les appels API. Pour une plateforme de CI/CD, ce sont les développeurs qui veulent livrer une nouvelle version. Pour une base de données, ce sont les applications qui l’interrogent.

Concrètement, ça veut dire quoi ? Prenons l’exemple d’une plateforme e-commerce. Les CUJ pourraient être : un utilisateur peut rechercher et consulter un produit, il peut ajouter un produit au panier et passer commande, il peut se connecter à son compte.

On ne va pas définir des SLO pour toutes les fonctionnalités (la page “À propos” de votre site, on s’en fiche un peu), mais se concentrer sur celles qui, si elles tombent en panne, vont vraiment énerver vos utilisateurs.

Et c’est là que ça devient intéressant : définir les CUJ, c’est souvent un exercice qui doit impliquer le business, pas seulement les équipes techniques. C’est eux qui savent ce qui rapporte de l’argent !

SLI : mesurer ce qui compte

Une fois qu’on a identifié nos CUJ, il faut les mesurer. C’est là qu’interviennent les SLI (Service Level Indicators).

Un SLI, c’est simplement une métrique qui indique si votre service fonctionne bien du point de vue de l’utilisateur. Les plus classiques sont la disponibilité (pourcentage de requêtes qui réussissent), la latence (temps de réponse du service), le débit (nombre de requêtes traitées par seconde) et la qualité (pourcentage de réponses correctes, sans erreurs de données).

L’idée clé ici, c’est de mesurer depuis le point de vue de l’utilisateur, pas depuis vos serveurs. Peu importe que votre CPU soit à 10% si l’utilisateur voit des erreurs 500 !

Quelques conseils pour choisir vos SLI

Pour vous aider à concevoir des SLI fiables, vous pouvez vous inspirer des méthodes USE et RED. USE (Utilization, Saturation, Errors) se concentre sur les ressources systèmes, tandis que RED (Rate, Errors, Duration) se concentre sur les requêtes. Ces frameworks vous donnent un bon point de départ pour identifier les métriques qui comptent vraiment.

Mais attention, un microservice ne doit pas avoir trop de SLI ! Trois ou quatre SLI bien choisies et qui ont un sens métier valent mieux qu’une dizaine de métriques que personne ne regarde. D’ailleurs, seuls les membres de l’équipe qui fournissent le service peuvent vraiment savoir quelles sont les métriques pertinentes. On ne peut pas imposer des SLI génériques à toute une entreprise !

Exemple concret pour notre CUJ “recherche de produit” : SLI disponibilité pourrait être (requêtes HTTP 200 sur /search) / (total requêtes sur /search) * 100, et SLI latence 95% des requêtes sur /search répondent en moins de X ms.

SLO : se fixer des objectifs réalistes

Maintenant qu’on sait quoi mesurer, il faut se fixer des objectifs. C’est le rôle des SLO (Service Level Objectives).

Un SLO, c’est tout simplement une valeur cible pour vos SLI sur une période donnée. Par exemple : “99,9% des requêtes de recherche doivent réussir sur une période de 30 jours” ou “95% des pages de recherche doivent s’afficher en moins de 500ms sur une période de 7 jours”.

Quelques conseils pour bien définir vos SLO

Commencez par mesurer l’existant. Inutile de viser 99,99% si votre service actuel est à 98%. Regardez vos métriques historiques et fixez-vous des objectifs atteignables mais ambitieux.

Pensez S.M.A.R.T. : vos SLO doivent être Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis. Comme tout bon objectif !

Et n’oubliez pas que 100% c’est mal ! Comme le dit si bien Ben Treynor Sloss (le papa du SRE chez Google) :

100% is the wrong reliability target for basically everything

Plus on veut de “9”, plus ça coûte cher exponentiellement. Et au-delà d’un certain seuil, les utilisateurs ne voient même plus la différence ! Prenez l’exemple d’un site web qui ne charge pas sur un smartphone : au-delà d’un certain niveau de disponibilité, l’utilisateur ne saura pas dire si c’est son smartphone qui a un problème, son navigateur, le réseau 5G ou bien le site web qui rencontre un incident. Si recharger la page une fois de temps en temps suffit et que les utilisateurs ne sont pas plus impactés que ça, inutile d’investir dans plus de fiabilité.

Pour vous aider à calculer ces pourcentages et temps d’indisponibilité, vous pouvez utiliser uptime.is qui fait les conversions pour vous.

Error Budget : retourner le problème

Et là, c’est le moment où ça devient vraiment malin. Au lieu de raisonner en “disponibilité”, les équipes SRE raisonnent en Error Budget (budget d’erreur).

C’est un simple changement de perspective : service accessible 99,9% = service inaccessible 0,1% du temps. Sur 30 jours, ça fait environ 43 minutes d’indisponibilité “autorisée”.

Cette approche change complètement la donne ! Au lieu de voir les pannes comme des échecs, on les voit comme un budget à dépenser intelligemment.

Comment utiliser son Error Budget ?

Contre-intuitivement… IL FAUT L’UTILISER !

Si votre SLO est respecté (utilisateurs contents), vous pouvez “dépenser” votre error budget pour faire des déploiements plus risqués, tester des nouvelles fonctionnalités en prod, faire du chaos engineering, ou réaliser des maintenances disruptives.

À l’inverse, si vous “cramez” votre error budget (SLO pas atteint), alors là, stop : on arrête tout ce qui n’améliore pas la fiabilité du service !

C’est un formidable outil de priorisation entre les équipes produit (qui veulent des nouvelles features) et les équipes ops (qui veulent de la stabilité). Le fameux mur de la confusion :

Exemple concret : une API de recommendation

Bon, assez de théorie, prenons un exemple concret. Imaginons qu’on ait une API de recommandation de produits.

D’abord, on définit le CUJ : “Un utilisateur doit pouvoir récupérer des recommandations personnalisées en moins de 1 seconde”. Ensuite, on choisit les SLI : disponibilité (réponses HTTP 200) / (total requêtes) * 100 et latence P95 du temps de réponse.

Pour les SLO, on pourrait avoir : “99,5% des requêtes sur l’API de recommandation doivent réussir sur 30 jours” et “95% des requêtes doivent répondre en moins de 800ms sur 7 jours”.

Enfin, on calcule l’Error Budget : 99,5% de disponibilité = 0,5% d’indisponibilité autorisée, soit environ 3,6 heures d’indisponibilité “budgetées” sur 30 jours.

Simple, non ?

Les pièges à éviter

Le premier piège, c’est de vouloir mettre des SLO partout. N’essayez pas ! Commencez par 2-3 SLO sur vos CUJ les plus critiques. Vous pourrez étendre ensuite.

Le deuxième piège, c’est de fixer des SLO trop stricts. Si vous mettez la barre trop haut, vous allez passer votre temps en “SLO violation” et personne ne prendra plus ça au sérieux.

Enfin, le troisième piège, c’est d’oublier l’aspect organisationnel. Les Error Budgets ne marchent que si toute l’organisation (business inclus) adhère au principe. Sinon, vous aurez beau être en SLO violation, on vous demandera quand même de déployer la nouvelle feature…

Comment commencer ?

Si vous n’avez jamais fait de SLO, voici un plan d’action simple.

Identifiez d’abord 1-2 CUJ critiques (avec le business !). Regardez ensuite vos métriques actuelles sur ces parcours. Définissez alors des SLO réalistes mais un peu ambitieux. Mettez en place l’alerting quand vous êtes en train de consommer votre error budget. Et enfin, itérez ! Les SLO ne sont pas gravés dans le marbre.

Conclusion

J’espère que cet article vous aura donné envie de creuser ces concepts ! Les SLO/SLI/Error Budget ne sont pas juste des buzzwords, c’est vraiment un changement de paradigme dans la façon d’appréhender la fiabilité.

Et le plus beau, c’est que ça marche autant pour une startup avec 3 développeurs que pour une GAFAM avec 10000 ingénieurs. L’important, c’est de commencer simple et d’itérer.

Pour aller plus loin, je vous recommande chaudement le SRE Book de Google (gratuit !) et leur guide pratique pour définir des SLO.

Et si vous voulez approfondir le sujet SRE en général, n’hésitez pas à jeter un œil aux slides de mon talk de 2022 ;-).

Bon monitoring !

Tutoriel Proxmox VE 8 - SDN en mode VXLAN avec des machines sur Internet

Sun, 30 Mar 2025 12:30:00 +0200

Préambule

Ce tutoriel est un genre de hors série dans ma suite d’articles sur Proxmox VE 8.

Dans la troisième partie qui est sortie il y a quelques jours, on s’est arrêté sur un cluster de machines distantes sur Internet.

Elles ne sont pas dans le même LAN, et pour tout dire, elles sont même distantes d’environ 100ms (et ça marche très bien).

A la fin de l’article, ça fonctionne, on a bien un réseau unique sur nos deux machines, avec un IPAM et un DHCP fonctionnel des deux côtés. Mais pour autant, les machines virtuelles qui sont sur des hôtes différents ne peuvent pas se parler directement et c’est quand même un peu dommage de ne pas avoir été au bout de l’exercice.

Plutôt que de réécrire cette partie, j’ai décidé de faire un petit aparté où je termine le travaille et teste la fonction VXLAN du SDN de proxmox VE, parce que OUI, ça peut fonctionner jusqu’au bout.

Prérequis

Je pars du principe que vous avez déjà deux (ou plus) machines au sein d’un même cluster Proxmox VE 8.

Si ce n’est pas le cas, vous êtes partis pour la lecture de ma suite d’articles (en cours d’écriture) sur le sujet (have fun!) :

Déploiement d’un cluster Proxmox VE 8 sur des serveurs dédiés (1/4)

Ces machines ne sont pas dans le même LAN (sinon pas forcément besoin de s’embêter avec du VXLAN, le SDN Simple peut suffire, comme on a fait dans la partie 3)

Problème

Ce qu’on veut faire, c’est créer un SDN qui passe par Internet, au point que les machines virtuelles croient être sur le même LAN.

On ne peut pas faire ça avec le SDN Simple, les VMs d’un hôte ne peuvent pas contacter les VMs d’un autre hôte distant sur Internet, même en étant dans le même SDN Simple et avec le même plan d’adressage.

Mais si on lit un peu plus loin dans la doc de PVE sur le SDN, on voit que c’est précisément le usecase mis en avant pour l’utilisation des SDN de type VXLAN :

The VXLAN plugin establishes a tunnel (overlay) on top of an existing network (underlay). This encapsulates layer 2 Ethernet frames within layer 4 UDP datagrams… […] You can, for example, create a VXLAN overlay network on top of public internet, appearing to the VMs as if they share the same local Layer 2 network

Petit souci cependant, en vrai, il ne vaut mieux pas le faire, car les trames ne sont pas chiffrées, et sur Internet, ce n’est vraiment pas la meilleure idée du monde…

Warning VXLAN on its own does does not provide any encryption. When joining multiple sites via VXLAN, make sure to establish a secure connection between the site, for example by using a site-to-site VPN.

En alternative, on aurait pu partir directement sur la version la plus complète / complexe du SDN de Proxmox VE : les EVPN Zones

The EVPN zone creates a routable Layer 3 network, capable of spanning across multiple clusters. This is achieved by establishing a VPN and utilizing BGP as the routing protocol.

Mais je n’ai pas envie de tremper avec BGP ici et je veux rester sur un truc simple. Cependant, c’est probablement l’option la plus “propre” pour un setup de production.

VXLAN donc, mais avec un VPN

Je ne vais pas me prendre la tête, on va monter un petit VPN avec wireguard à la mano. Il y a des tonnes d’outils de VPN sur le marché et des tonnes d’outils pour se faciliter la vie. Si vous voulez plus d’info sur Wireguard, je suis sûr que vous en trouverez plein, je mets juste ici le strict minimum pour que ça “juste marche”.

Sur les deux serveurs, installez wireguard, qui devraient être dans les dépôts debian par défaut :

apt update && apt install -y wireguard

Générez un couple de clé sur chaque machine :

wg genkey | tee privatekey | wg pubkey > publickey

Petite gymnastique mentale, on va écrire un fichier de configuration avec pour chaque serveur, la clé privée du serveur (fichier privatekey) sur lequel on est, mais la clé publique (fichier publickey) du serveur distant.

(Quand on y réfléchit, c’est évidement, mais je préfère insister)

Et il faut évidemment changer les adresses et les interfaces réseaux en fonction du serveur sur lequel on est de manière à ne pas avoir de conflit.

vi /etc/wireguard/wg0.conf
[Interface]
Address = 10.10.30.1/24
ListenPort = 51820
PrivateKey = <clé privée du serveur local>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o <nom d'interface réseau> -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o <nom d'interface réseau> -j MASQUERADE
[Peer]
PublicKey = <clé publique du serveur distant>
Endpoint = <IP publique du serveur distant>:51820
AllowedIPs = 10.10.30.2/32

Note : vous pouvez aussi ajouter plus de nodes dans le VPN, il suffit d’ajouter plus de “Peer”.

On termine en démarrant le VPN et en vérifiant que les nodes se parlent entre eux :

systemctl enable wg-quick@wg0 --now

ping 10.10.30.1
ping 10.10.30.2

Configuration du SDN

Normalement, si vous avez suivi les articles précédents, vous avez déjà les prérequis, mais pour ceux qui ne l’auraient pas fait, je remets que dans le fichier /etc/network/interfaces, il est nécessaire d’ajouter en fin de fichier la ligne suivante (suivi d’un petit systemctl restart networking)

source /etc/network/interfaces.d/*

Ensuite, dans le menu Datacenter, ouvrir le sous menu SDN.

Dans le menu SDN/Zones, ajouter une zone de type “VXLan”. Deux points importants ici :

on doit renseigner la liste de tous les “peers”, ici les IPs de nos VPNs donc 10.10.30.1 et 10.10.30.2
on va devoir adapter la MTU. Par défaut, une trame, c’est 1500. Sauf que wireguard pour son encapsulation a diminué la MTU à 1420 et que l’encapsulation VXLAN en prend 50. On doit donc mettre 1370 pour éviter au mieux de la fragmentation, au pire, des paquets dropés

Si vous venez de lire l’article précédent, vous allez remarquer qu’ici, il n’y a pas de “coche” pour activer le DHCP sur la zone. C’est malheureusement parce que ce n’est pas disponible pour l’instant.

Currently only Simple Zones have support for automatic DHCP

Source : pve.proxmox.com/pve-docs/chapter-pvesdn.html#pvesdn_config_dhcp

Une fois que vous avez validé, allez dans le sous menu SDN/VNets, cliquez sur le bouton “Create” pour créer un réseau virtuel, puis le sélectionner une fois créé pour créer un sous réseau.

Une fois de plus, n’oubliez d’aller voir la partie DHCP, pour déclarer le range pour notre futur DHCP.

Une fois qu’on a bien tout validé, on voit qu’à côté de toutes ces nouvelles choses qu’on vient de créer, il y a une icône avec deux flèches jaunes et un statut à “New”.

Pour déployer ces modifications, on doit retourner dans le menu SDN du début, et cliquer sur Apply. Deux lignes “vxlan1” (une pour chaque serveur, en vrai) devraient apparaitre.

C’est tout ?

Et oui, c’est tout, franchement, j’aurai vraiment dû insister un peu avant de poster mon article précédent…

Pour s’en convaincre, il suffit de pop deux containers LXC (sans DHCP 🥲), un sur chaque serveur, et de voir s’ils se pingent.

It works!

Bon, ben… il ne me reste plus qu’à migrer toutes mes machines existantes sur le vnet VXLAN pour avoir enfin un cluster où les VMs se voient entre elles !!

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (3/4)

Tue, 25 Mar 2025 12:30:00 +0200

Note - cet article fait partie d’une suite d’articles :

On reprend de là où on en était : premiers pas dans l’UI

Dans le tutoriel précédent (que je vous invite à lire, si ça n’a pas été fait, sinon ça ne sera pas clair), on a configuré le stockage, le réseau et on a déployé notre première machine virtuelle pour nous assurer que tout fonctionne. Mais il reste encore pas mal de choses à explorer, notamment la mise en cluster, le SDN de proxmox VE, le firewall intégré, les sauvegardes, le monitoring…

On reprend donc de là où on en était, et on va installer un autre serveur (difficile de faire un cluster avec une seule machine).

Ce serveur a été réinstallé avec les mêmes procédures que le serveur dont je vous parle dans les parties 1 et 2, à ceci près que nous n’avons pas besoin de créer le bridge (vmbr0) car nous allons utiliser le SDN !!

Idéalement, il faut que toutes les machines du cluster aient les mêmes pools de storage puisque je le rappelle, cette configuration est censée être commune à tous les serveurs, car gérée au niveau “Datacenter” de notre cluster (même si on peut configurer des exceptions).

Création du cluster

La mise en cluster de machines Proxmox VE est un sujet que j’ai abondamment traité sur le blog, au point qu’il est d’ailleurs surtout connu de certains d’entre vous surtout pour ces articles ;-) :

Je ne vais donc pas y passer trop de temps. Sachez juste que :

c’est plus facile à faire depuis la version 6 parce qu’il n’y a plus besoin de monter un VPN entre les serveurs (corosync v3)
ça peut se faire en ligne de commande
dans tous les cas, il faut se loguer en root avec mot de passe lors de la mise en cluster

Très brièvement donc, on va sur le premier serveur, dans la Server View en haut à gauche, on sélectionne notre Datacenter, puis dans le menu Cluster.

On clique sur le bouton Create Cluster.

Note : ici, c’est simple, je n’ai que ma carte réseau, donc il n’y a pas de doute sur l’interface à utiliser. Cependant, dans le cas d’un serveur avec plus d’interfaces et plus de bridges (ou des VPNs comme on a dû le faire jusqu’en PVE 6), il faut bien choisir quelle interface sert au clustering.

On valide le formulaire :

À partir de ce moment-là, le serveur n’est plus en “standalone” et dispose de services systemd supplémentaires.

On a notamment un dossier /etc/pve qui est synchronisé entre tous les nodes (el famoso Proxmox Cluster File System) avec la configuration de chaque node et les fichiers de configuration des machines virtuelles. On a aussi le logiciel corosync, qui va régulièrement contacter tous les nodes du cluster pour s’assurer que tout le monde est bien vivant / accessible.

Rejoindre le cluster

Si on retourne voir le menu “Cluster”, on a maintenant des informations qui s’affichent sur notre cluster, à savoir son nombre de nœuds (ici un seul, normal). Cliquer sur le bouton Join information.

Une popup s’ouvre avec plusieurs informations à copier-coller qui nous seront demandées dans le menu de l’autre serveur, celui qui va rejoindre le cluster :

On se connecte donc sur l’interface graphique de notre second serveur Proxmox VE (mon Atom dans l’exemple), on va dans le même menu, mais au lieu de créer un nouveau cluster, on clique sur le bouton Join Cluster :

Petit coup de flip normalement, une fois que le node va rejoindre le cluster, vous allez perdre la main sur l’interface web et avoir un message d’erreur “401”. C’est “normal”, quand le serveur rentre dans le cluster, des services sont redémarrés et on passe d’un mode standalone à un mode clusterisé…

Pas de panique, un F5 devrait résoudre l’affaire (ou alors, connectez-vous au “premier” serveur du cluster).

On a maintenant un beau cluster :)

Split brain

Notez par contre que dans mon exemple, on n’a que 2 nodes, ce qui est plus que déconseillé quand on fait un cluster Linux (en vrai, un cluster en général). Si jamais le lien réseau tombe entre nos deux machines, elles n’auront aucun moyen de savoir si c’est un problème réseau (que se apelerio split brain) ou une panne d’un des nodes.

Pour éviter de tout péter en redémarrant des VMs des deux côtés (le cas le plus catastrophique dans un split brain), lorsque le quorum ne sera plus atteint, Proxmox VE passe les nodes qui n’ont pas de majorité en (quasi) “lecture seule”.

Et au cas où ce n’est pas clair, le quorum c’est la moitié des nodes +1, donc ici : 2/2+1 = 2… donc dès qu’on a plus un des deux nodes, on a plus le quorum.

Simple, basique.

Du coup, si jamais on coupe un node ou la communication entre les deux, vos VMs encore actives continueront à fonctionner (j’ai débattu de ça sur LinkedIn il y a quelques jours).

Par contre, il sera impossible de modifier la configuration du cluster, démarrer ou créer des VMs, etc.

La seule chose qu’on peut éventuellement faire qui ne soit pas “read only”, c’est arrêter des VMs, car ça n’induit aucun risque pour la cohérence des données. Mais vous ne pourrez pas les rallumer, vous êtes prévenus…

Pour la petite histoire, le débat sur LinkedIn, c’était “est-ce que ProxmoxVE coupe toutes les VMs en cas de split brain” et la réponse est évidemment non. Par contre, la plupart des actions sont bien bloquées.

Dans tous les cas, pour éviter ça, le mieux est d’avoir un nombre impair de nodes pour que le split brain ne puisse jamais arriver, ou éventuellement d’ajouter un vote complémentaire à l’aide d’une instance servant juste d’arbitre comme c’est expliqué dans mon vieil article de 2019 ou dans la doc officielle :

Configuration du SDN

Bon, c’est cool, on a un cluster de deux machines. Mais dans la configuration actuelle, la VM qu’on a créée dans la partie précédente ne peut pas migrer facilement d’un serveur à l’autre. En effet, on l’a attachée sur un bridge Linux (vmbr0) qui a son propre plan d’adressage réseau.

En cas de migration, il faudrait potentiellement démarrer la machine, changer l’adresse IP, revoir les iptables / règles de firewalling. C’est ce que je faisais jusqu’à présent, et dans le cas d’un PRA pour une infra de lab et un blog perso, c’est “OK”.

Une grosse nouveauté de la version 8.1, est l’activation d’un module “SDN” (Software Defined Network) qui est présent en test par les développeurs et quelques early adopters depuis la version 6.X, qui va nous permettre de gérer ça de manière centralisée depuis l’interface. Si vous voulez aller bouquiner la doc officielle, c’est ici :

pve.proxmox.com/pve-docs/chapter-pvesdn.html

Le seul prérequis qui va nous manquer est dnsmasq pour le DHCP, et la doc nous dit de lancer les commandes suivantes sur nos machines :

apt update
apt install dnsmasq
# disable default instance
systemctl disable --now dnsmasq

Et dans le fichier /etc/network/interfaces, il est aussi nécessaire d’ajouter en fin de fichier la ligne (suivi d’un petit systemctl restart networking)

source /etc/network/interfaces.d/*

Dans le menu Datacenter, ouvrir le sous menu SDN. On remarque qu’il existe déjà des SDNs de déclarés, mais il s’agit en fait des réseaux par défaut qu’on a déclaré dans les articles précédents :

Dans le menu SDN/Zones, ajouter une zone de type “Simple”. Il existe des zones plus complexes qui seront utiles dans des contextes de production avec des LANs non triviaux (VLAN, VXLan) mais dans notre cas, la Simple est suffisante.

Note : ne pas oublier de cocher la case advanced pour pouvoir activer le DHCP. OUI on va enfin avoir du DHCP pour nos machines virtuelles et nos containers.

Une fois de plus, n’oubliez d’aller voir la partie DHCP, pour déclarer le range pour notre futur DHCP.

Une fois qu’on a bien tout validé, on voit qu’à côté de toutes ces nouvelles choses qu’on vient de créer, il y a une icône avec deux flèches jaunes et un statut à “New”.

Pour déployer ces modifications, on doit retourner dans le menu SDN du début, et cliquer sur Apply. Deux lignes “sdn1” (une pour chaque serveur, en vrai) devraient apparaitre.

Fait rigolo, le SDN de Proxmox VE va rajouter des règles iptables qui devraient vous dire quelque chose si vous avez déroulé les précédents articles :

#version:5
auto vnet1
iface vnet1
address 10.10.20.1/24
post-up iptables -t nat -A POSTROUTING -s '10.10.20.0/24' -o vmbr0 -j SNAT --to-source 203.0.113.1
post-down iptables -t nat -D POSTROUTING -s '10.10.20.0/24' -o vmbr0 -j SNAT --to-source 203.0.113.1
post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
bridge_ports none
bridge_stp off
bridge_fd 0
ip-forward on

Et si maintenant, je recrée une autre machine virtuelle, mais que cette fois-ci au lieu de vmbr0, je choisis vnet1, je n’ai pas besoin de saisir l’adresse IP (puisque j’ai le SDN qui sert le DHCP) et elle a accès à Internet sans configuration supplémentaire.

Avec cette configuration cependant (SDN en mode Simple Zone), il ne sera toujours pas possible de faire communiquer les machines virtuelles entre elles. Ça sera possible avec des configurations plus complexes :

You can, for example, create a VXLAN overlay network on top of public internet, appearing to the VMs as if they share the same local Layer 2 network

Note : j’ai exploré les VXLAN depuis, et j’ai écrit un article complémentaire ici.

Conclusion

Je n’ai toujours pas terminé cette série, car j’ai encore des choses à dire sur la réplication SDN et le firewalling de Proxmox VE, les sauvegardes, le monitoring, mais une fois de plus, je dépasse déjà les 12000 signes. Il est donc temps de publier l’article et de commencer à écrire le suivant.

Et en attendant, have fun :)

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (2/3)

Mon, 17 Feb 2025 10:30:00 +0200

Note - cet article fait partie d’une suite d’articles :

On reprend de là où on en était : premiers pas dans l’UI

Dans le tutoriel précédent (que je vous invite à lire, si ça n’a pas été fait, sinon ça ne sera pas clair), on a choisi un serveur physique dédié chez un provider type OVHCloud ou Hetzner. On a ensuite installé Proxmox VE dans la dernière version (8.x), configuré quelques options de sécurité de base, ajouté des utilisateurs et des groupes.

On peut maintenant essayer de se connecter à l’UI. La première chose qui devrait vous frapper (💥 aïe !) c’est que la page d’administration est en HTTPS avec un certificat autosigné. On va commencer par régler ça.

Un truc assez frustrant avec Proxmox VE (mais c’est probablement pour de “bonnes raisons” que j’ignore) c’est que certaines opérations ne sont pas possibles à réaliser dans l’UI si vous vous connectez avec le compte admin zwindler@pve que nous avons créé dans le blog post précédent.

C’est typiquement vrai pour les mises à jour, la mise en cluster et la configuration et… pour la configuration des certificats (liste non exhaustive). Ici, on va donc devoir pour l’instant se connecter en root@pam et non pas en zwindler@pve…

Notez bien qu’il y a (pour l’instant) 2 “realms”, Linux PAM (pour root) et Proxmox VE Auth (pour l’admin).

Dans la barre de droite, on retrouve notre serveur, qui est pour l’instant tout seul dans son datacenter (on y reviendra plus tard). Il y a plusieurs vues dans l’UI de Proxmox VE, certaines choses sont difficiles à trouver quand on n’a pas ça en tête. Ici, je suis dans la “server view”, probablement la plus classique si vous venez du monde VMware. Dans ce menu, vous trouverez vos hyperviseurs et on pourra interagir avec chacun d’entre eux, comment ils sont configurés.

Une fois notre serveur sélectionné, on a donc le menu principal qui affiche de nombreux menus. Sélectionner System / Certificates.

On a de la chance, Proxmox VE est livré avec un module pour commander tout seul des certificats Let’s encrypt. Si vous avez votre propre certificat ça fonctionne aussi (bouton Upload Custom Certificate), bien entendu, mais je vais partir du principe que vous n’en avez pas, comme moi.

Dans la partie ACME, cliquer sur Add ACME Account pour enregistrer votre email et accepter les Terms Of Service (TOS) de Let’s Encrypt.

À partir de là, ajouter le FQDN de notre serveur en cliquant sur le bouton Add sous ACME. Le bouton était grisé tant que nous n’avions pas ajouté de compte.

Maintenant, on peut enfin commander le certificat en cliquant sur Order Certificates Now. Si tout se passe bien, le certificat sera correctement livré par Let’s Encrypt, et le serveur pve-proxy (qui sert le frontend de l’UI de Proxmox VE) devrait redémarrer, et votre page web se rafraîchir, avec un bon certificat cette fois-ci :).

Stockage / ZFS

Si vous lisez souvent mon blog et que je vous dis que je suis un fan inconditionnel de ZFS, vous ne serez pas surpris.

Et si vous avez bien lu l’article précédent, vous vous rappellerez que nous avons réduit la partition par défaut du template OVHcloud en LVM pour pouvoir faire une belle partition ZFS. Sauf que si on va dans la vue stockage, elle n’est malheureusement pas visible.

Petite subtilité de l’UI, le menu pour ajouter du stockage se retrouve au niveau du Datacenter et non de la configuration du serveur lui-même. En théorie, la gestion du stockage doit être identique sur tous les serveurs d’un même DC dans Proxmox VE, même si on peut passer outre ce principe et mettre en place des exceptions depuis de nombreuses versions déjà.

Dans Datacenter / Storage, cliquez sur Add, puis ZFS dans le menu déroulant qui s’affiche :

Sur les stockages de type ZFS, on ne peut stocker que les “Disk images” et les “Containers”, ce qui ne va pas nous arranger si nous voulons aussi stocker des ISOs, des templates ou des backups.

On pourra se contenter de les stocker sur le stockage par défaut “local”.

Mais on peut aussi “tricher” en se connectant sur le serveur en SSH, et en créant un dossier (/tank/data dans mon exemple), puis en créant un nouveau stockage de type Directory qui n’a pas de restriction sur les types de données.

Parlons un peu de ZFS

Je me suis pris la tête un nombre incalculable de fois avec des gens qui persistent raconter n’importe quoi sur ZFS, même après leur avoir expliqué.

C’est faux. Et archifaux. Euh…

non, il n’y a pas besoin d’avoir de la RAM ECC pour stocker des choses sur ZFS. D’abord, c’est une préconisation (un peu zélée probablement) faite par des gens qui ont conçu un filesystem extrêmement robuste. De très nombreuses prods fonctionnent avec ZFS sans RAM ECC. Ensuite, c’est surtout vrai si vous faites de la déduplication, car la perte d’un bloc peut avoir des conséquences catastrophiques dans ce genre de cas…
non, ZFS ne nécessite pas 1 Go de RAM par To de disque, là encore, c’est uniquement si vous activez la déduplication (pour stocker les tables de correspondance entre les hashes et les blocs).

En revanche, ce qui est exact, c’est que par défaut, ZFS va essayer d’utiliser 50% de la RAM disponible sur votre serveur et de s’en servir comme cache. Dans beaucoup de logiciels d’administration, y compris Proxmox VE, cette valeur va être beaucoup trop haute pour nous, car la RAM est une ressource précieuse sur un hyperviseur.

Ça ne veut pas dire que cette fonctionnalité est inutile. Avoir du cache quand on a de la RAM qui ne sert à rien, c’est toujours bien. Donc, on va réduire cette valeur pour éviter des conflits de ressources entre l’optimisation des performances de notre stockage et la quantité de VMs qu’on peut héberger.

# Restrict to 512MB
echo 536870912 | sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

# Restrict to 4GB
echo 4294967296 | sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

Note : cette commande sera à persister d’une manière ou d’une autre

Du réseau

Bon… j’ai essayé de repousser au maximum le moment où on arrive au réseau (parce que je déteste ça) mais à un moment, il va bien falloir s’y mettre…

Par défaut, notre serveur Proxmox VE est installé avec un bridge Linux qui va nous permettre de partager du réseau entre l’interface physique de notre serveur et nos machines virtuelles.

Ce setup fonctionne bien sur votre réseau local avec un DHCP et votre propre LAN IPv4 local ou si vous disposez d’une plage d’IP (que ce soit v6 ou v4) et de quoi les affecter aux machines virtuelles.

Malheureusement dans mon cas, je n’ai qu’une IPv4 (je pourrais activer l’IPv6 mais j’aurais d’autres problématiques et je préfère rester simple ici). Si je crée des VMs et que je les affecte sur le bridge, elles ne récupèreront pas d’IP et n’auront pas accès à Internet.

Il existe plusieurs façons de connecter les machines virtuelles au réseau extérieur. Si vous avez du temps, je vous conseille de lire avec attention le Wiki de Proxmox VE qui a une très bonne page qui liste les différentes possibilités.

pve.proxmox.com/wiki/Network_Configuration

Dans les précédents articles sur Proxmox VE 5 puis Proxmox VE 6, on avait fait des trucs compliqués à base de plusieurs bridges, de DMZ, de firewalling pfSense, et d’un script iptables de l’enfer.

Rien que d’y penser, je suis déjà épuisé.

Heureusement, il existe depuis plusieurs versions déjà un firewall intégré à Proxmox VE, ainsi qu’un SDN que je n’ai jamais pris le temps de découvrir et je pense que c’est le bon tuto pour le faire :).

On va donc se référer à la documentation officielle, et choisir le mode “Masquerading (NAT) with iptables”, mais avec un setup plus simple par rapport à précédemment.

Danger zone

La configuration de l’interface réseau peut en théorie se faire directement depuis l’UI plutôt qu’en allant modifier les fichiers de configuration (/etc/network/interfaces). Dans la vue du serveur, allez dans le menu System / Network :

Ici, on voit que je ne vous ai pas raconté de carabistouilles, et qu’on a bien un bridge avec notre interface physique (ici enp1s0).

(On a même une plage IPv6, oh là là 🙈 je n’ai aucune excuse… BREEEF, on va faire comme si on n’avait pas vu.)

On arrive maintenant au moment rigolo où on peut se couper la chique assez facilement. Je l’ai fait assez souvent et passer en rescue…

fun fun fun fun

L’idée ici, c’est donc de retirer l’interface du bridge, de configurer le réseau directement dessus, et de donner un réseau local pour nos VMs sur le bridge, tout en ajoutant les règles iptables pour faire le masquerading.

Tant qu’on ne cliquera pas sur le bouton Apply Configuration, on ne “risque” rien.

Le problème de l’UI est que nous n’allons pouvoir modifier QUE les IP, les gateway et les interfaces sur le bridge ou non. Sauf que pour réaliser le masquerading et que nos machines virtuelles accèdent à Internet, nous devons ajouter les fameuses règles iptables dont je vous parle juste avant et on ne peut pas le faire depuis l’UI.

Il va falloir rajouter les cinq dernières lignes dans la configuration du vmbr0…

cat /etc/network/interfaces
[...]
auto vmbr0
iface vmbr0 inet static
 address 10.10.10.1/24
 bridge-ports none
 bridge-stp off
 bridge-fd 0

 # à ajouter pour que le masquerading fonctionne
 post-up echo 1 > /proc/sys/net/ipv4/ip_forward
 post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o enp1s0 -j MASQUERADE
 post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
 post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

Attention : le point le plus important est de bien vérifier que l’interface de sortie (-o) a bien le bon nom. Ici, mon interface physique connectée à Internet est enp1s0, mais si la vôtre a un autre nom, il faut adapter.

De mon point de vue, l’UI n’est tout de même pas complètement inutile, car elle nous permet de faire le changement le plus délicat (échange des IP) avec le diff visuel et le bouton “apply config”. Les scripts post-up ont peu de chances de nous couper l’accès.

Premier test

On est loin d’avoir fini (ça ne rentrera pas dans cet article, de toute façon, donc autant brûler les étapes…). Mais je suis sûr que vous êtes impatients de lancer une VM et on devrait avoir quelque chose de fonctionnel, bien qu’incomplet.

On va donc faire un petit test rapide de notre setup pour vérifier qu’on a bien un hyperviseur fonctionnel a minima (c’est-à-dire sans clustering, sans SDN, sans firewall, sans monitoring, sans sauvegarde… sans rien, en fait).

J’ai commencé à faire joujou avec Talos Linux comme distribution Linux pour Kubernetes. Pour faire simple, je vais donc lancer l’install d’un Node Talos. Si elle arrive à s’enrôler dans l’interface Omni, ça veut dire que j’ai un hyperviseur fonctionnel, réseau inclus.

Une fois l’ISO généré sur le site de mon Omni (le control plane SaaS de Sidero Labs, l’éditeur de Talos Linux), on peut le pousser sur notre Proxmox VE.

Pour le faire, depuis notre serveur (donc pas au niveau Datacenter), on sélectionne un pool de stockage qui accepte les images ISO (si vous vous souvenez bien, notre pool ZFS ne le supporte pas par défaut), on choisit ISO Images, et on clique sur Upload pour téléverser l’ISO (comme on dit en bon français).

Une fois uploadé, on peut maintenant cliquer sur le bouton bleu en haut à droite Create VM.

À partir de là, le wizard de création de VM devrait vous prendre la main. Ça va être un peu verbeux, mais tous les menus sont utiles, quand on commence à bien connaître Proxmox VE. Je vous donne quand même le minimum :

Dans le premier menu, on ne va pas choisir sur quel nœud on installe la VM puisque pour l’instant, on n’en a qu’un… En revanche, on va devoir lui donner un ID (100 par défaut) unique pour tout le cluster. Idéalement, on lui donne aussi un petit nom. Moi, j’ai opté pour talos02 (car j’ai déjà un talos01 sur un autre serveur, vous avez vu comme je suis original ?).

Enfin, j’ai coché la case “Start at boot”, c’est le genre de truc relou quand on a oublié de le mettre et que l’hyperviseur redémarre (ça arrive)…

On peut donner des tags à nos VMs, elles auront de jolies pastilles de couleurs pour les distinguer :)

Dans le second menu (OS), on doit indiquer deux choses. D’abord, qu’on veut utiliser l’ISO qu’on vient de récupérer / uploader pour booter notre machine (il faut choisir le bon pool de stockage, par défaut, c’est “local” qui est sélectionné). On doit aussi donner le type d’OS pour des histoires de compatibilité de pilotes pour les périphériques virtuels. Ça fait belle lurette qu’on n’a plus trop besoin de ça, “6.X - 2.6” fonctionne pour tous les Linux récents (la sortie du kernel 2.6, c’est 2003 !).

Je saute System, dans Disks, on ajoute un disque sur le bon pool (donc pas local, mais bien celui en ZFS). Pour ma VM Talos 32 Go, c’est largement suffisant… À noter qu’il existe beaucoup d’options importantes ici pour tout ce qui est “optimisation” des lectures / écritures, mais on est largement au-delà du scope de cet article.

Je saute CPU et memory, l’important, c’est de surtout lui donner au moins 2 cores et 2 Go de RAM (au moins). On peut là aussi optimiser les performances CPU en activant les bons flags, mais là encore, on n’est plus dans le but de l’article donc je n’insiste pas.

Dans la partie network, on s’assure juste qu’on est bien branché sur le bon bridge (normalement si vous avez suivi l’article, on en a qu’un, vmbr0, donc on ne peut pas se tromper).

Et on vérifie que tout est OK. Protip, pour gagner cinq secondes dans votre vie, cliquez sur “Start after created”, ce qui permettra de démarrer la VM au plus vite après sa création.

It’s alive?

À ce stade, la VM devrait automatiquement booter sur le CD Talos et l’OS devrait s’installer sur le disque. Une fois prête, la machine va essayer de s’enrôler sur mon control plane Omni.

Et là, c’est le drame…

Car oui, je n’ai pas configuré de DHCP ni de SDN. Il faut donc aller configurer à la main la carte réseau virtuelle (ce qui n’est pas foufou), en appuyant sur F3 dans la console.

(Et en subissant un peu de QWERTY, mais c’est à ça qu’on reconnaît un bon sysadmin normalement : il sait faire du QWERTY dans les consoles)

Une fois le réseau configuré, la machine devrait quasiment instantanément commencer à se configurer…

… et à s’enrôler dans Omni :

Victoire !!

Enfin bon…

Enfin bon… oui, on a une VM fonctionnelle. Mais j’ambitionne qu’on aille quand même un peu plus loin avant de vraiment crier victoire.

Comme je l’ai dit plus haut, on a dû configurer le réseau de notre VM à la main, et on n’a encore ni clustering, ni firewalling, ni SDN, ni monitoring, ni sauvegarde… Mais on chatouille allègrement les 16 000 signes pour ce blog post, il est donc temps de raccrocher pour se dire “à la prochaine fois”.

Et en attendant, have fun :)

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (1/2)

Mon, 27 Jan 2025 20:00:00 +0000

Note - cet article fait partie d’une suite d’articles :

Introduction

Ceux qui suivent un peu le “lore” de ce blog savent que je suis un peu connu dans la communauté des bidouilleurs du dimanche pour avoir rédigé (ou co-rédigé) plusieurs tutos sur Proxmox VE. Je pense en particulier à deux suites d’articles sur Proxmox VE 5, puis Proxmox VE 6, pour créer de zéro un cluster de virtualisation avec Proxmox VE (et pfSense à l’époque).

C’est une nouvelle itération de ces tutos, basée cette fois-ci sur Proxmox VE 8, avec pas mal de choses qui changent et de nouvelles approches.

Le but ultime de cette suite d’articles est de disposer d’une plateforme de virtualisation avec Proxmox VE. Cette plateforme sera composée de plusieurs machines (idéalement 3, mais 2 ça fonctionne aussi), sécurisée, supervisée, hautement disponible, sauvegardée.

Il faudra suivre plusieurs articles pour y parvenir.

Postulats de départ

1- Je pars du principe que vous n’avez pas de machines pour le faire à la maison et que vous n’avez pas envie ou les moyens d’investir dans un homelab (même si ça peut être très rigolo, ça demande de l’investissement). Cependant, si vous avez des machines à la maison, une grande partie de l’article reste valide, une fois les machines installées.

2- Comme Proxmox VE est une plateforme de virtualisation, je pars aussi du principe que vous voulez disposer de machines dédiées (physique) et pas de machines virtuelles, pour justement pouvoir virtualiser des OS entiers sans trop de problèmes (même si on a toujours l’option “nested virt”, c’est moins glop).

Note : si vous n’avez pas besoin de virtualisation (exemple : pas de Windows ou d’OS un peu particulier), Proxmox VE est une super plateforme de containérisation, notamment grâce à LXC, qui permet de créer des containers Linux avec un OS entier, que vous pourrez gérer exactement comme une VM mais avec des performances bien meilleures (et quelques limitations dues au partage de kernel, mais c’est souvent suffisant). Vous pouvez aller lire mes articles sur LXC si ça vous intéresse.

3- J’aimerais attirer votre attention sur le fait que de nombreuses actions auraient pu être scriptées ou gérées via de “l’infrastructure as code”. C’est plus dans l’air du temps, car plus robuste et plus fiable. Cependant, l’intérêt de cet article est de faire “à la main” pour comprendre ce qu’on fait, pas à pas, pas juste vous fournir une infrastructure “clé en main” que vous ne saurez pas gérer au premier pépin.

Si vous cherchez des méthodes plus industrielles pour déployer des clusters de virtualisation, vous en trouverez sûrement plein sur Internet, de la part d’autres blogueurs (certains français, certains sont même des copains).

J’ai d’ailleurs moi-même plusieurs fois fait l’exercice avec Ansible ou Rudder par le passé, par exemple ici (note : ce code est obsolète) :

Maintenant que l’objectif et le contexte est clair pour tout le monde, on peut commencer :)

Choix des machines

Comme on a dit qu’on n’auto-héberge pas, il faut trouver un hébergeur qui propose des machines physiques. Idéalement, quelque chose de pas trop cher, ça serait bien pour commencer.

On va donc plutôt viser à trouver des machines peu onéreuses MAIS avec le support des instructions VT-x / AMD-v, ce qui est à peu près tous les CPUs qui fonctionnent encore aujourd’hui SAUF les Atom et les machines ARM type Raspberry.

Grosso modo, ça nous laisse les Kimsufi chez OVHCloud, les dédibox chez Scaleway et les machines chez Hetzner.

Chez Hetzner pour 45€, vous avez un i5 gen13, 64 Go de RAM et 2 SSD NVMe.

Chez OVHcloud, avec un peu de chance, vous pourrez tomber sur des machines autour des 15 - 20€ par mois avec du matériel plus ancien, mais largement suffisant pour ce qu’on va en faire.

Chez Scaleway, l’offre d’entrée de gamme est centrée sur les Atom Avoton ou de très vieux Xeon. L’Avoton C2750 reste une option valable, car c’est un octo-cores qui supporte le VT-x (contrairement au C2350, attention !). Mais bon, c’est du matoss de 2013 💀…

Pour les besoins de cet article, j’ai optimisé les coûts et je suis parti sur le serveur OVHcloud que je présente juste au-dessus (KS-GAME-LE), malheureusement uniquement disponible au Canada :(. Mais 8 threads et 16 Go de RAM pour 12€ TTC par mois, ce n’est vraiment pas cher payé.

Deux points noirs :

le stockage ridiculement petit pour de la virtualisation (seulement 240 Go, un seul disque)
la latence - presque 100 ms depuis chez moi, contre 11 ms pour mon autre machine chez Scaleway

64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=1 ttl=53 time=98.0 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=2 ttl=53 time=97.5 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=3 ttl=53 time=97.6 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=4 ttl=53 time=97.7 ms
64 bytes from proxmox.example.org (203.0.113.78): icmp_seq=5 ttl=53 time=97.7 ms

Installation de l’OS

Une fois commandé, le serveur est relativement rapidement disponible dans votre “manager OVH”. On a un menu relativement intuitif pour installer directement Proxmox VE 8, quasiment à jour (les images fournies sont reconstruites très régulièrement avec toutes les mises à jour).

Pour lancer l’installation, on clique sur les “…” dans la partie Système d’exploitation (OS), puis on sélectionne l’install depuis un template OVH

On déroule la liste des types d’OS, on sélectionne Virtualisation, puis proxmox VE 8 (tant qu’à faire). J’ai aussi coché la case “Personnaliser la configuration des partitions”, parce que par défaut, l’installation d’OVH utilise du stockage de type “LVM thick” pour la majorité de l’espace disque, alors qu’on va utiliser les fonctionnalités avancées de ZFS pour la suite :

Avant de valider l’installation, n’oubliez pas de modifier son nom (Custom hostname) pour éviter d’avoir besoin de le faire post install, puis d’ajouter une clé publique SSH :

Premières tâches post-installation : upgrade et reboot

Il y a toute une petite série de trucs à faire quand on vient d’installer une machine, en particulier sur Proxmox VE, et on va essayer de se retenir de “vite vite” se connecter à l’interface graphique.

De toute façon, on ne pourra pas s’y connecter, à l’interface graphique de Proxmox VE…

Ah bon ???

Oui, car si on peut normalement se connecter avec l’utilisateur root de notre Linux, on ne va pas pouvoir dans le cas d’OVHcloud, tout simplement parce qu’on n’a PAS le mot de passe root. Heureusement qu’on a mis une clé SSH ;)

On y reviendra plus tard, on a plus urgent à faire.

La première chose que moi, j’ai faite, c’est d’ajouter tout de suite un record DNS de type A pour que l’IP de ma machine corresponde à un FQDN. Pour cet article, j’y ferai référence de la manière suivante :

hostname: myPVEhost
FQDN: proxmox.example.org
IP: 203.0.113.159

On se connecte donc sur l’IP de notre machine fraichement installée en SSH (root@IPmachine) et on va en profiter pour faire un peu de ménage.

La première chose à faire est de mettre à jour le serveur, idéalement suivi d’un reboot :

apt update && apt upgrade -y && reboot

Une fois le serveur revenu à la vie, on se reconnecte et active d’une manière ou d’une autre un système de mise à jour automatiques. Le plus simple c’est d’utiliser unattended-upgrades s’il n’est pas installé par défaut (il est possible qu’il y soit déjà) mais il existe des outils plus perfectionnés.

apt install unattended-upgrades

C’est pour la sécurité

Une fois que c’est fait, je vous conseille d’installer tout de suite CrowdSec. Ici, je me suis simplement basé sur la documentation officielle de crowdsec, pour ajouter le moteur de détection, le composant de remédiation (ici via iptables) :

CrowdSec.net - Installation Linux

curl -s https://install.crowdsec.net | sudo sh
apt install crowdsec

# vérifier que le service crowdsec fonctionne
systemctl status crowdsec
● crowdsec.service - Crowdsec agent
 Loaded: loaded (/lib/systemd/system/crowdsec.service; enabled; preset: enabled)
 Active: active (running) since Sun 2025-01-26 21:04:26 UTC; 1min 56s ago
 Process: 73830 ExecStartPre=/usr/bin/crowdsec -c /etc/crowdsec/config.yaml -t -error (code=exited, status=0/SUCCESS)
 Main PID: 73862 (crowdsec)
 Tasks: 13 (limit: 19059)
 Memory: 33.1M
 CPU: 2.571s
 CGroup: /system.slice/crowdsec.service
 ├─73862 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml
 └─73877 journalctl --follow -n 0 _SYSTEMD_UNIT=ssh.service

Jan 26 21:04:23 myPVEhost systemd[1]: Starting crowdsec.service - Crowdsec agent...
Jan 26 21:04:26 myPVEhost systemd[1]: Started crowdsec.service - Crowdsec agent.

# installer le moteur de remédiation
apt install crowdsec-firewall-bouncer

Une fois que Crowdsec est opérationnel, on peut lui ajouter la collection “fulljackz/proxmox”, qu’il va falloir modifier (merci le super article de Julien Louis sur son blog slash-root.fr), qui va écouter les logs de la webUI pour détecter tout brute force et bannir ceux qui tenteraient de le faire :

cscli collections install fulljackz/proxmox
[...]
INFO Enabled fulljackz/proxmox
INFO Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.

Le pattern écouté par le parser proxmox n’est pas/plus bon avec les nouvelles versions

Jan 26 21:23:14 myPVEhost pvedaemon[1250]: authentication failure; rhost=::ffff:203.0.113.159.78 user=coucou@pve msg=no such user ('coucou@pve')

On voit ici que Julien a rajouté le préfixe “::ffff:” dans la variable PVE_AUTH_FAIL du fichier /etc/crowdsec/parsers/s01-parse/proxmox-logs.yaml, mais quand je vois les cas de tests prévus dans la collection, j’ai l’impression que ce n’est pas nécessaire…

Dans tous les cas, on va créer un fichier /etc/crowdsec/acquis.d/proxmox.yaml pour que CrowdSec puisse commencer à analyser nos logs :

mkdir -p /etc/crowdsec/acquis.d/
cat > /etc/crowdsec/acquis.d/proxmox.yaml <<EOF
journalctl_filter:
 - _SYSTEMD_UNIT=pvedaemon.service
labels:
 type: syslog
EOF

On termine par recharger crowdsec et on regarde ~~le monde brûler~~ les scripts kiddies se faire bloquer.

systemctl reload crowdsec

cscli alerts list
╭────┬────────────────────┬───────────────────────────┬─────────┬──────────────────────────────────────────────────────────────┬───────────┬─────────────────────────────────────────╮
│ ID │ value │ reason │ country │ as │ decisions │ created_at │
├────┼────────────────────┼───────────────────────────┼─────────┼──────────────────────────────────────────────────────────────┼───────────┼─────────────────────────────────────────┤
│ 2 │ Ip:203.0.113.222 │ crowdsecurity/ssh-slow-bf │ IR │ 202468 Gloubi Bo ulgua Co. ( Private Joint Stock) │ ban:1 │ 2025-01-26 22:31:15.366187524 +0000 UTC │
╰────┴────────────────────┴───────────────────────────┴─────────┴──────────────────────────────────────────────────────────────┴───────────┴─────────────────────────────────────────╯

Dans la liste des petits trucs pénibles livrés de base avec Proxmox VE, il y avait avant le fait que Proxmox VE avait les dépôts apt entreprise sur toutes les installations, et il était nécessaire de préalablement les désactiver à la main avant de pouvoir faire les mises à jour.

C’était super pénible et les développeurs de Proxmox VE ont entendu (un peu) leur communauté et retiré cette obligation… pour la remplacer par une popup.

Alors, une popup, je veux bien ! C’est important de récompenser le travail des développeurs et de les soutenir. Mais est-ce que c’est vraiment nécessaire de le faire à chaque login ET à chaque fois qu’on rafraîchit la liste des packages à mettre à jour ?

C’est bien entendu une question rhétorique.

Évidemment, de nombreuses personnes ont trouvé plusieurs méthodes pour désactiver le code JS responsable. Big up à fabio pour sa version qui fonctionne bien.

sed -Ezi.bak "s/(function\(orig_cmd\) \{)/\1\n\torig_cmd\(\);\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Note : si comme moi vous vous êtes déjà connecté une fois, il faudra aussi nettoyer le cache sinon la popup restera…

Création de groupes et d’utilisateurs pour l’interface graphique

Ok ok, on a fait plein de trucs, est-ce qu’on peut se connecter maintenant ???

Mais ouiiii, on peut. De toute façon, j’en suis déjà à presque 15000 signes, cet article est beaucoup trop long, il faut abréger.

Dernière étape dans cet article, on va créer un administrateur pour se connecter à l’UI et un utilisateur qui nous servira plus tard pour le monitoring.

# vous n'êtes pas **vraiment** obligé d'appeler l'admin "zwindler" vous savez ?
pveum group add admin -comment "System Administrators"
pveum acl modify / -group admin -role Administrator
pveum useradd zwindler@pve
pveum usermod zwindler@pve -group admin
pveum passwd zwindler@pve

# notre utilisateur de monitoring
pveum groupadd monitoring -comment 'Monitoring group'
pveum aclmod / -group monitoring -role PVEAuditor
pveum useradd pve_exporter@pve
pveum usermod pve_exporter@pve -group monitoring
pveum passwd pve_exporter@pve

Allez, c’est bon, vous avez assez patienté, vous pouvez vous connecter à votre Proxmox VE ! Rendez-vous sur :

https://@IPmachine:8006 ou
https://proxmox.example.org:8006

Note : pour l’instant, le certificat est autosigné et le navigateur va nous remonter une erreur. On peut accepter d’ignorer le problème pour l’instant.

N’oubliez pas de changer le “realm” de PAM (les utilisateurs unix, qu’on n’utilise pas ici) à “Proxmox” pour pouvoir utiliser l’administrateur qu’on vient de créer.

À bientôt pour la suite. Et en attendant, have fun!

Sauvegarder des dashboards Grafana dans Kubernetes, en s’amusant (j’explique les RBAC, Job et les CronJob)

Tue, 01 Oct 2024 18:00:00 +0200

Note : Pour les allergiques à Kubernetes, cet article peut être vu comme une entrée en la matière, car je vais progressivement explorer certains concepts, de manière très progressive.

Note 2 : par convention dans cet article, j’ai essayé de nommer tous les objets Kubernetes avec une majuscule à tous les mots (exemple : ServiceAccount) pour que ce soit plus clair.

Grafana

Je ne vous ferai pas l’affront de vous présenter Grafana, l’outil de visualisation open source de la société éponyme. C’est un outil que j’utilise depuis un moment et qui est quasiment incontournable dans toutes les solutions de monitoring modernes (ou non ? xD).

D’ailleurs, j’ai écrit déjà quelques articles sur Grafana au fil des années, c’est un outil aussi simple qu’irremplaçable (jusqu’à ce qu’on trouve mieux, bien entendu).

Si vous avez déjà utilisé au moins une fois Grafana, vous savez donc que les visualisations sont organisées comme suit :

des dossiers
dans lesquels on range des dashboards
qui contiennent des panels (nos visualisations)

On peut donc créer des dashboards à gogo en fonction du besoin, les cloner, les modifier, les importer depuis un magasin sur grafana.com (assez inutilisable maintenant, mais bon) et en afficher le code JSON.

Et ça, c’est super cool, parce que si mon Grafana brûle (mes machines persos ne sont pas hébergées dans les conditions les plus pros possibles… 😱), je n’ai pas envie de tout perdre. Mais aller régulièrement copier / coller le code JSON de chaque dashboard, c’est pénible.

Because I’m API

Un truc qui est cool avec Grafana, c’est que comme tout logiciel un peu pro qui se respecte, il dispose d’une API. Je ne vais pas juger de sa qualité globale d’API (vous connaissez peut-être bien mieux que moi), mais elle a le mérite d’exister.

Récemment, je me suis donc demandé quelle quantité d’effort, il faudrait déployer pour sauvegarder de manière automatisée des dashboards Grafana avec l’API et Kubernetes (oui hein, vous n’allez pas y couper).

Partons donc du principe que j’ai un cluster Kubernetes sur lequel j’ai déployé la chart Helm officielle de Grafana (rappel, Helm, c’est à la fois un package manager et un moyen de déployer des applications dans Kubernetes).

À partir de là, de quoi j’ai besoin ?

Je suis le roi des fainéants, je ne veux pas avoir à aller créer les accès dans Grafana moi même (via 3 clics clics). Il faut donc que j’automatise la création d’un token pour communiquer avec l’API
Une fois que j’ai mon token, je veux créer une tâche périodique qui va se connecter à l’API, lister les dashboards disponibles et les sauvegarder sur un bucket s3 chez Scaleway (il y a 75 Go gratuit dans le free-tier, ça suffira largement)

Se préparer à créer un token

Bon, là en apparence, on se retrouve face à un problème d’œuf / poule. Comment je fais pour me connecter à l’API si je n’ai pas un accès à l’API ?

Heureusement, on va tricher… grâce à Kubernetes 😏

Quand on déploie Grafana dans Kubernetes, la chart officielle va créer un Secret (au sens Kubernetes du terme) qui contient le login / password du compte local administrateur de Grafana.

apiVersion: v1
kind: Secret
metadata:
 creationTimestamp: "2024-10-01T13:11:48Z"
 name: grafana
 namespace: grafana
 resourceVersion: "1234567"
 uid: deadbeef-dead-cafe-baba-123456789012
data:
 admin: YWRtaW4=
 password: TmV2ZXJHb25uYUdpdmVZb3VVcAo=
type: Opaque

S’il est déconseillé de l’utiliser au jour le jour (mieux vaut utiliser des comptes nominatifs, idéalement via un Identity Provider), c’est super pratique ici !

Il suffit de créer un Job Kubernetes avec suffisamment de droits pour lire ce Secret, qui va se connecter (une seule fois) sur l’API avec le compte admin, créer un token, le récupérer, et le stocker dans un autre Secret !

Sans rentrer à fond dans les détails de comment fonctionne le RBAC (Role Based Access Control) dans Kubernetes, voilà à quoi ça ressemble :

---
apiVersion: v1
# le compte de service (ServiceAccount) qui va être utilisé par le Job et qui a besoin de droits particuliers
kind: ServiceAccount
metadata:
 name: grafana-backup-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
# le rôle, c'est la politique de sécurité qui va nous permettre de faire des trucs
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-role
rules:
# ici je n'autorise qu'à lire le secret contenant l'admin/password de grafana, pas plus
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana"]
 verbs: ["get"]
# ici, je vais autoriser le fait de modifier un secret qui s'appelle grafana-backup
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup"]
 verbs: ["get", "update", "patch"]
# ici, je vais autoriser le fait de créer des secrets
- apiGroups: [""]
 resources: ["secrets"]
 verbs: ["create"]
---
# ici, je lie simplement ServiceAccount à un Role pour lui donner les droits dont j'ai besoin
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-role
 apiGroup: rbac.authorization.k8s.io

Note : vous aurez remarqué que je n’ai pas autorisé la création ET la modification du Secret grafana-backup en une seule étape, mais en deux. Ceci est dû à une limitation de l’API de Kubernetes, qui ne permet pas de limiter la création d’un objet via son “ressource name”. Je vous laisse aller lire la doc officielle si ça vous intéresse.

Sachez que je me suis un peu “embêté” à gérer la politique de droits et qu’on aurait pu faire bien plus simple. Mais c’est pour respecter le principe en sécurité informatique du moindre privilège (c’est important).

Bon… on va le créer, ce token ??

Maintenant qu’on a géré les aspects de sécurité (ça limitera les possibilités d’un attaquant qui réussirait à prendre la main sur notre Pod / container), on peut créer la tâche qui va créer le token.

Ici, il n’y a pas de raison de laisser tourner un container ad vitam une fois que le token est créé, on peut l’éteindre. Pour ça, il existe un objet dans Kubernetes qui s’appelle le Job (avec une gestion d’erreur et de retry intégré). Voilà à quoi il va ressembler :

---
apiVersion: batch/v1
kind: Job
metadata:
 name: grafana-backup-api-token-job
 namespace: grafana
spec:
 template:
 spec:
 # on lui donne bien le bon ServiceAccount sinon on a fait tout ce RBAC pour rien T_T
 serviceAccountName: grafana-backup-sa 
 containers:
 - name: grafana-create-api-token
 # une petite astuce pour de la bidouille, merci Jérôme :-*
 image: nixery.dev/shell/curl/jq/kubectl:latest
 # on "monte" le Secret Kubernetes comme des fichiers dans notre container
 volumeMounts:
 - name: grafana-secret-volume
 mountPath: /etc/grafana-secret
 readOnly: true
 command:
 - /bin/sh
 - -c
 - |
 # Comme on a monté le secret dans notre container, c'est super facile de récupérer
 # l'utilisateur et le mot de passe admin sans avoir à le stocker nulle part (surtout pas sur github)
 GRAFANA_ADMIN_USER=$(cat /etc/grafana-secret/admin)
 GRAFANA_ADMIN_PASS=$(cat /etc/grafana-secret/password)

 # On peut maintenant faire une requête HTTP via curl sur l'API de Grafana
 GRAFANA_API_TOKEN=$(curl -s -X POST http://@IPgrafana:80/api/auth/keys \
 -u "$GRAFANA_ADMIN_USER:$GRAFANA_ADMIN_PASS" \
 -H "Content-Type: application/json" \
 -d '{
 "name": "Kubernetes Backup Token",
 "role": "Admin",
 "secondsToLive": 31536000
 }' | jq -r '.key')

 # On termine par stocker le token dans le nouveau Secret grafana-backup
 kubectl create secret generic grafana-backup \
 --from-literal=GRAFANA_API_TOKEN=$GRAFANA_API_TOKEN \
 --dry-run=client -o yaml | kubectl apply -f -
 restartPolicy: OnFailure
 volumes:
 - name: grafana-secret-volume
 secret:
 secretName: grafana

Normalement, avec ce bon script code BASH, j’ai réconcilié les amateurs de bash avec Kubernetes.

Comment ça, “non” ?

Il ne me reste plus qu’à appliquer le manifest YAML sur mon cluster Kubernetes et le Secret grafana-backup contenant la clé d’API devrait apparaitre sur notre cluster :

kubectl apply -f job.yaml

kubectl get secrets
NAME TYPE DATA AGE
grafana-backup Opaque 1 1m

kubectl describe secret grafana-backup
Name: grafana-backup
Namespace: grafana
Labels: <none>
Annotations: <none>

Type: Opaque

Data
====
GRAFANA_API_TOKEN: 104 bytes

Première victoire :)

RBAC, again

On peut s’attaquer à la deuxième partie du problème : comment récupérer puis sauvegarder les JSON ?

Ben, avec une nouvelle couche de moindres privilèges, pardi !!

Vous connaissez la musique maintenant. On crée un ServiceAccount, on ne lui donne le droit qu’à lire les Secrets qui nous intéressent via un Role / RoleBinding pour ne pas faciliter le travail d’un attaquant qui aurait compromis mon Pod.

---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: grafana-backup-cron-sa
 namespace: grafana
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: grafana
 name: grafana-backup-cron-role
rules:
- apiGroups: [""]
 resources: ["secrets"]
 resourceNames: ["grafana-backup", "grafana-backup-s3-credentials"]
 verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: grafana-backup-cron-rolebinding
 namespace: grafana
subjects:
- kind: ServiceAccount
 name: grafana-backup-cron-sa
 namespace: grafana
roleRef:
 kind: Role
 name: grafana-backup-cron-role
 apiGroup: rbac.authorization.k8s.io

Petite subtilité, ici, je vais aussi devoir créer un Secret supplémentaire pour que mon container puisse s’authentifier sur le bucket S3 sur lequel je vais déposer mes JSONs. Je ne rentre pas dans les détails, on sort du cadre de l’article, vous pouvez aller lire la doc officielle de scaleway qui est plutôt bien faite (Using Object Storage with the AWS-CLI).

Voilà à quoi ressemble le Secret grafana-backup-s3-credentials :

apiVersion: v1
kind: Secret
metadata:
 name: grafana-backup-s3-credentials
 namespace: grafana
type: Opaque
stringData:
 # le Secret se compose de 2 entrées, qui seront montés comme des fichiers textes 
 # dans le container ; pratique pour des fichiers de config avec des secrets !!
 credentials: |
 [default]
 aws_access_key_id=SCxxxxxxxxxxxxxxxxxx
 aws_secret_access_key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 config: |
 [default]
 region = fr-par
 output = json
 services = scw-fr-par
 [services scw-fr-par]
 s3 =
 endpoint_url = https://s3.fr-par.scw.cloud

Et pour finir, on veut donc créer une tâche planifiée, qui va s’occuper de réaliser notre sauvegarde régulièrement. Dans Kubernetes, il s’agit de l’objet CronJob, qui va lancer périodiquement des Job (le même qu’on a vu précédemment).

---
apiVersion: batch/v1
kind: CronJob
metadata:
 name: grafana-backup-cronjob
 namespace: grafana
spec:
 schedule: "0 */2 * * *"
 jobTemplate:
 spec:
 template:
 spec:
 serviceAccountName: grafana-backup-cron-sa
 containers:
 - name: grafana-backup
 image: nixery.dev/shell/curl/jq/awscli:latest
 volumeMounts:
 - name: grafana-backup-s3
 mountPath: /.aws/credentials
 subPath: credentials
 - name: grafana-backup-s3
 mountPath: /.aws/config
 subPath: config
 restartPolicy: OnFailure
 env:
 - name: GRAFANA_API_TOKEN
 valueFrom:
 secretKeyRef:
 name: grafana-backup
 key: GRAFANA_API_TOKEN
 command:
 - /bin/sh
 - -c
 - |
 # Ici, on récupère un gros JSON listant les dashboards et on utilise jq pour extraire l'identifiant unique "uid"
 dashboards=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" 'http://@IPgrafana:80/api/search?query=&type=dash-db' | jq -r '.[] | .uid')

 # On boucle ensuite sur la liste des uid
 for uid in $dashboards; do
 # On récupère le JSON qu'on copie en local
 dashboard_json=$(curl -s -H "Authorization: Bearer $GRAFANA_API_TOKEN" http://@IPgrafana:80/api/dashboards/uid/$uid)
 echo "$dashboard_json" > /tmp/dashboard-$uid.json

 # Puis on utilise aws-cli pour uploader le fichier sur notre bucket s3
 aws s3 cp /tmp/dashboard-$uid.json s3://grafana-backup/grafana-backups/dashboard-$uid.json --profile default
 done
 volumes:
 - name: grafana-backup-s3
 secret:
 secretName: secret-grafana-backup-credentials

Toutes les deux heures, nos dashboards seront tous sauvegardés sur notre bucket chez Scaleway. Si la fonction de versioning a été activé sur le bucket, on pourra même garder un historique des versions.

Deuxième victoire :)

Conclusion

Ok, écrire ces scripts et les manifests qui vont avec a surement pris un peu plus de temps que d’aller manuellement créer un token dans l’UI de Grafana, puis de le donner en dur dans un gros script bash.

Cependant, il y a quand même quelques différences avec cette approche :

A part pour les crédentials du bucket S3 (et encore on aurait pu utiliser minIO dans Kubernetes), on a manipulé aucun identifiant. Toute cette gestion des Secrets est déléguée à Kubernetes, loin de l’admin (avec les limitations que ça peut avoir). On n’aura pas de leaks sur github de secrets git-és par erreur et si on gère son RBAC correctement, seuls les Pods qui sont habilités à lire ses Secrets pourront le faire.
Tout est géré “as-code” et automatisé. Le faire une fois à la main va plus vite. Le faire 100 fois, car on a 100 clusters identiques, c’est quand même dommage.
On profite des fonctions de Kubernetes de gestion des erreurs et de retries des Jobs et des Cronjobs. C’est du code (bash ou autre) en moins à gérer si on veut fiabiliser l’outil dans une utilisation plus “industrielle”.

Que je vous aie convaincu ou pas, au-delà de l’exemple, le but était surtout d’introduire quelques concepts de Kubernetes (le RBAC et les Jobs, comment on construit des manifests, …) et j’espère que ça vous a plu.

Bonus

Si vous trouvez ces scripts trop limités pour vos besoins, vous pouvez aller voir les outils suivants, plus poussés. Attention cependant, certains ne sont pas/plus maintenu, et je n’ai pas audité le code. A vos risques et périls donc :

Système on Zwindler's Reflection

UserNamespaces dans Kubernetes : la feature géniale qui sert (presque) à rien

L’infographie qui m’a trigger

Ce que les UserNamespaces font réellement, sans bullshit

Ce que l’infographie exagère (et ce qu’elle oublie)

Comparaison sans bullshit : UserNS vs les alternatives existantes

Les vrais cas d’usage

1. Build-as-a-Service (Buildah, rootless Podman)

2. Multi-tenancy hostile (plateformes de code utilisateur)

3. Legacy “hard-coded” (Postfix, Dovecot, BIND)

Quelques contre-arguments

Où investir son budget sécurité ?

Conclusion

Références

Installation d'un Alpine Linux en mode 'headless' sur Raspberry Pi

Introduction

Pourquoi Alpine Linux ?

Téléchargement de l’image Alpine Linux pour Raspberry Pi

Configuration headless avec le fichier overlay

Premier boot et installation permanente

Optimisation de la RAM GPU

Solutions pour minimiser la RAM GPU

Configuration du swap avec zswap

Création du swapfile

Configuration persistante

Conclusion

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Introduction : quand les devs découvrent le SRE

SLA vs SLO : ne mélangeons pas tout !

Critical User Journey : commencer par ce qui compte vraiment

SLI : mesurer ce qui compte

Quelques conseils pour choisir vos SLI

SLO : se fixer des objectifs réalistes

Quelques conseils pour bien définir vos SLO

Error Budget : retourner le problème

Comment utiliser son Error Budget ?

Exemple concret : une API de recommendation

Les pièges à éviter

Comment commencer ?

Conclusion

Tutoriel Proxmox VE 8 - SDN en mode VXLAN avec des machines sur Internet

Préambule

Prérequis

Problème

VXLAN donc, mais avec un VPN

Configuration du SDN

C’est tout ?

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (3/4)

On reprend de là où on en était : premiers pas dans l’UI

Création du cluster

Rejoindre le cluster

Split brain

Configuration du SDN

Conclusion

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (2/3)

On reprend de là où on en était : premiers pas dans l’UI

Stockage / ZFS

Parlons un peu de ZFS

Du réseau

Danger zone

Premier test

It’s alive?

Enfin bon…

Déploiement d'un cluster Proxmox VE 8 sur des serveurs dédiés (1/2)

Introduction

Postulats de départ

Choix des machines

Installation de l’OS

Premières tâches post-installation : upgrade et reboot

C’est pour la sécurité

Nagging popup

Création de groupes et d’utilisateurs pour l’interface graphique

Sauvegarder des dashboards Grafana dans Kubernetes, en s’amusant (j’explique les RBAC, Job et les CronJob)

Grafana

Because I’m API

Se préparer à créer un token

Bon… on va le créer, ce token ??

RBAC, again

Conclusion

Bonus