Zwindler's Reflection

zeropod v0.12.0 : un an après, le scale-to-zero tient-il ses promesses ?

Sat, 30 May 2026 12:00:00 +0200

Qu’est-ce que zeropod ?

Il y a un peu moins d’un an, j’avais publié un premier article sur un projet open source qui s’apelle zeropod.

Zeropod is a Kubernetes runtime (more specifically a containerd shim) that automatically checkpoints containers to disk after a certain amount of time of the last TCP connection.

While in scaled down state, it will listen on the same port the application inside the container was listening on and will restore the container on the first incoming connection.

À l’époque, la version stable était la v0.6.x, et j’avais testé sur un cluster k3s. Les résultats étaient mitigés : ça marchait dans les grandes lignes, mais avec des limitations rédhibitoires pour une utilisation un peu sérieuse (probes impossibles, comportement flaky sous charge, temps de checkpointing un peu élevés à mon gout).

Entre temps, le projet a pas mal évolué (maintenant v0.12.0), avec des promesses de corrections et d’améliorations. J’ai donc remis le couvert pour voir où on en est vraiment.

Autre changement : j’ai abandonné k3s pour cette série de tests, pour des raisons que je détaillerai au fil de l’article.

Prérequis

Cette fois-ci, j’ai utilisé un serveur fraîchement provisionné chez mon hébergeur préféré :

Un serveur Ubuntu 24.04.3 LTS (Noble), kernel 6.17.0-35 HWE, 7.7 Gi RAM, 100G disk
Un cluster Kubernetes monté avec kubeadm, flannel comme CNI
containerd vanilla
local-path-provisioner (Rancher) pour avoir un stockage local
Pas de cert-manager ni d’Ingress, on va au plus simple cette fois

Installation

J’ai déjà installé kubeadm plein de fois et certainement que vous aussi donc je ne vous fait pas l’affront de refaire un énième tuto.

# Installer kubeadm, kubelet, kubectl + containerd
sudo kubeadm init --pod-network-cidr=10.42.0.0/16
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Une fois le cluster fonctionnel, l’installation de zeropod est triviale :

# Appliquer le kustomize générique
kubectl apply -k https://github.com/ctrox/zeropod/config/generic

# Ajouter un label à notre unique node
kubectl label node <votre-node> zeropod.ctrox.dev/node=true

# Vérifier que le pod tourne
kubectl -n zeropod-system wait --for=condition=Ready pod -l app.kubernetes.io/name=zeropod-node

C’est tout. Pas de flag spécial, pas de configuration supplémentaire. Sur kubeadm, kubelet est un binaire natif (/usr/bin/kubelet) détecté automatiquement par zeropod.

Note sur k3s : sur k3s, la documentation de zeropod est un peu différente puisque la config à utiliser est config/k3s. Le kustomize ajoute un flag -probe-binary-name=k3s sur l’initContainer pour que le shim sache que le kubelet est embarqué dans le binaire k3s. Lors de mes tests, j’ai constaté que même avec ce flag, le comportement n’était pas celui attendu (le socket tracker ne filtrait pas correctement les probes). Avec la config par défaut, le flag est sur l’initContainer mais pas sur le manager. J’avais suspecté qu’il y avait un autre composant à patcher, mais je n’ai pas creusé plus que ça.

Le DaemonSet déploie les images suivantes :

ghcr.io/ctrox/zeropod-manager:v0.12.0
ghcr.io/ctrox/zeropod-installer:v0.12.0
ghcr.io/ctrox/zeropod-criu:v4.2 (CRIU a été mis à jour depuis v0.6.x)

Vérifions que la runtimeClass zeropod est bien disponible :

kubectl get runtimeclass
NAME HANDLER AGE
zeropod zeropod 30m

Premier test : nginx

Comme la dernière fois, commençons par un test simple avec nginx. On déploie un pod tout bête :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 labels:
 app: nginx
 spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 ports:
 - containerPort: 80

Le passage important, c’est l’annotation zeropod.ctrox.dev/scaledown-duration: 10s et runtimeClassName: zeropod.

Peu après le déploiement, zeropod détecte l’absence de trafic. Le container est checkpointé. Si on regarde les logs du manager :

{"time":"2026-05-29T14:26:37.269453861Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"RUNNING","duration":"0s"}

Puis 10 secondes plus tard :

{"time":"2026-05-29T14:26:47.465510937Z","level":"INFO","msg":"status event","container":"nginx","pod":"nginx-bench-7c65c8874-6pts7","phase":"SCALED_DOWN","duration":"191.259383ms"}

Le champ duration dans le log SCALED_DOWN correspond au temps de checkpoint : 191ms. C’est déjà nettement mieux que les ~400ms de v0.6.x sur k3s (probablement grâce à une mise à jour, peut être CRIU 4.2 ?).

Restauration

Quand on envoie une requête HTTP, le container se réveille :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 200 (0.101s)

real 0m0.101s
user 0m0.003s
sys 0m0.003s

101ms pour restaurer nginx et servir une page. C’est comparable aux ~92ms de l’article original.

Petite nouveauté : sous v0.6.x, kubectl top pods retournait une erreur pour les pods checkpointés :

# v0.6.x
kubectl top pods
error: Metrics not available for pod default/php-xxx

Ce bug a été corrigé dans la v0.9.0. Désormais, les pods en SCALED_DOWN retournent 0m 0Mi :

kubectl top pods
NAME CPU(cores) MEMORY(bytes)
nginx 0m 0Mi

C’est plus élégant.

Test des liveness probes

C’était LA limitation majeure de la v0.6.x : zeropod était incompatible avec les probes Kubernetes. Si vous mettiez une liveness probe httpGet sur votre container, la sonde déclenchait le timer de scale-down, et votre container ne passait jamais en SCALED_DOWN. Résultat : probes inutilisables, donc zeropod inutilisable en production.

Ce qui a changé

Deux correctifs ont été apportés entre la v0.6.x et la v0.12.0 :

L’activator (le composant eBPF qui écoute le trafic pendant le SCALED_DOWN) : il intercepte les probes et répond 200 directement, sans réveiller le container. Ça, c’est le comportement “après scale-down”.
Le socket tracker (le composant qui ignore les connexions pendant l’état RUNNING) : depuis la PR #72 (merged août 2025), zeropod est capable de détecter les connexions provenant du kubelet et de ne pas les compter comme du “vrai” trafic. Ça, c’est le comportement “avant scale-down”.

Test grandeur nature

J’ai déployé nginx avec une liveness probe agressive (periodSeconds: 5) et un scaledown-duration: 10s :

spec:
 runtimeClassName: zeropod
 containers:
 - image: nginx
 name: nginx
 livenessProbe:
 httpGet:
 path: /
 port: 80
 periodSeconds: 5

Sur k3s, ce test m’avait donné du fil à retordre : le socket tracker n’arrivait pas à filtrer les connexions des probes, qui resettaient le timer de scale-down en permanence. L’activator par contre (qui filtre les probes une fois le scale down passé) fonctionnait.

Sur kubeadm, le résultat est immédiat :

kubectl get pod -l app=nginx-probe -o json | jq -r '.items[0].metadata.labels["status.zeropod.ctrox.dev/nginx"]'
SCALED_DOWN

Le socket tracker filtre correctement les connexions du kubelet natif. La règle periodSeconds > scaledown-duration que j’avais dû utiliser sur k3s n’est plus nécessaire.

Un mot sur les évolutions entre v0.6.x et v0.12.0

Le tableau des améliorations entre les deux versions :

Point	v0.6.x	v0.12.0
`kubectl top pods` en scaled-down	❌ Erreur	✅ `0m 0Mi` (fix v0.9.0)
Checkpoint (nginx)	~400ms	~185ms (-54%)
Restauration (nginx)	~92ms	~99ms (stable)
CRIU	v3.x	v4.2
Gestion d’échec checkpoint	basique	métriques + events (v0.11.0)
Proxy timeouts configurables	❌	✅ (v0.11.0)
Migration inter-node	basique	améliorée + timeouts (v0.10.0)
Probes	❌ Incompatible	✅ Activator + socket tracker

Note technique intéressante sur les flags CRIU : zeropod a retiré l’option --tcp-established en septembre 2025. Auparavant, les connexions TCP actives étaient sauvegardées et restaurées avec le container. Désormais, zeropod utilise --tcp-skip-in-flight (quand runc >= 1.3 le supporte). Conséquence pratique : si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Il faudra les rétablir après restore.

Déploiement de WordPress (le cas d’usage réaliste :trollface:)

Bon, nginx c’est bien, mais c’est pas très représentatif. Déployons une vraie app avec du PHP, Apache et une base de données.

Reprenons le manifest WordPress de l’article original, sans zeropod sur MySQL :

apiVersion: apps/v1
kind: Deployment
metadata:
 name: wordpress
spec:
 replicas: 1
 selector:
 matchLabels:
 app: wordpress
 template:
 metadata:
 annotations:
 zeropod.ctrox.dev/scaledown-duration: 10s
 zeropod.ctrox.dev/container-names: wordpress
 zeropod.ctrox.dev/ports-map: wordpress=80
 labels:
 app: wordpress
 spec:
 runtimeClassName: zeropod
 initContainers:
 - name: wait-for-mysql
 image: mysql:8
 command:
 - sh
 - -c
 - |
 until mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "SELECT 1"; do
 echo "Waiting for MySQL..."
 sleep 3
 done
 mysql -h mysql -u root -p${MYSQL_ROOT_PASSWORD} -e "CREATE DATABASE IF NOT EXISTS wordpress;"
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 containers:
 - image: wordpress:latest
 name: wordpress
 ports:
 - containerPort: 80
 env:
 - name: WORDPRESS_DB_HOST
 value: mysql
 - name: WORDPRESS_DB_USER
 value: root
 - name: WORDPRESS_DB_PASSWORD
 value: verySecurePassword
 - name: WORDPRESS_DB_NAME
 value: wordpress

MySQL (sans zeropod) :

apiVersion: v1
kind: Service
metadata:
 name: mysql
spec:
 ports:
 - port: 3306
 selector:
 app: mysql
 clusterIP: None
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 serviceName: mysql
 replicas: 1
 selector:
 matchLabels:
 app: mysql
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - image: mysql:8
 name: mysql
 ports:
 - containerPort: 3306
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: verySecurePassword
 volumeMounts:
 - mountPath: /var/lib/mysql
 name: data
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi

Le checkpoint de WordPress (Apache + PHP) :

{"time":"2026-05-29T14:33:35.915988635Z","phase":"SCALED_DOWN","duration":"313.286787ms"}

Les checkpoints mettent autour de 300ms. La restauration est autour de 200 ms :

{"time":"2026-05-29T14:34:31.56806589Z","phase":"RUNNING","duration":"206.33005ms"}

La première requête curl confirme :

time curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.212s)

212ms, c’est environ 2 fois plus rapide que les 454ms de l’article original.

Et maintenant, le test qui tue : cascade WordPress + MySQL

Dans l’article original, j’avais tenté le test ultime : mettre les deux pods (WordPress ET MySQL) avec runtimeClassName: zeropod, puis envoyer une requête HTTP sur WordPress pendant que les deux sont checkpointés.

Le scénario est le suivant :

Au bout de quelques secondes, WordPress est SCALED_DOWN, MySQL est SCALED_DOWN aussi
Un client envoie une requête HTTP à WordPress
L’activator de WordPress intercepte la requête et restore le container WordPress
WordPress (Apache+PHP) démarre, exécute le code PHP qui nécessite une connexion MySQL
WordPress se connecte à MySQL sur le port 3306
L’activator de MySQL intercepte la connexion et restore MySQL
MySQL répond, WordPress génère la page, Apache renvoie la réponse HTTP

Du vrai scale to zero qui scale toute l’app, pas juste le front/back.

Note importante : je sais que vous ne voudrez probablement jamais scaler votre base de données à zéro en production, mais ce test montre que cette approche (eBPF + CRIU) fonctionne au-delà du simple scale-to-zero de serveurs web, ce que d’autres outils sur le marché font déjà très bien.

Sur k3s : pas de chance, sur kubeadm : victoire

Sur k3s, je n’ai pas encore réussi à faire fonctionner ce scénario : WordPress se restaurait mais ne répondait pas sur le port 80. J’ai passé pas mal de temps à essayer de comprendre, sans succès.

Même test, même version de zeropod, mais sur kubeadm :

curl http://<POD_IP>/ -s -o /dev/null -w "%{http_code} (%{time_total}s)"
HTTP 302 (0.224s)

224ms. Les deux pods sont passés de SCALED_DOWN à RUNNING, la page WordPress s’affiche. J’ai répété le test 5 fois de suite :

Cycle	Temps (curl)	HTTP
1	229ms	302
2	192ms	302
3	227ms	302
4	230ms	302
5	211ms	302

Les logs zeropod confirment le réveil des deux containers :

WordPress: SCALED_DOWN → RUNNING
MySQL: SCALED_DOWN → RUNNING

Ce qui a vraiment changé depuis v0.6.x

Les probes (enfin !)

C’était mon grief principal dans le premier article. Aujourd’hui, c’est résolu :

Avant : impossible de mettre des probes Kubernetes → zeropod inutilisable dans un usecase un minimum sérieux
Après : l’activator intercepte les probes en SCALED_DOWN (répond 200 sans restore), et le socket tracker filtre les connexions kubelet en RUNNING

La stabilité

Le comportement flaky (perte de pods sous charge simultanée) a disparu. Là où j’avais des échecs sous l’article original, les tests de charge séquentiels et simultanés passent tous.

Les performances

Le checkpoint a gagné ~50% en vitesse (185ms vs 400ms). La restauration aussi (200ms vs 454ms). Merci CRIU v4.2 et les optimisations de zeropod.

kubectl top pods

Ce petit détail faisait tache — kubectl top pods plantait sur les pods checkpointés. Corrigé en v0.9.0.

Mais quelques limitations résiduelles

Je serais malhonnête si je disais que tout est parfait. Voilà ce qui reste problématique :

depuis septembre 2025, zeropod n’utilise plus --tcp-established pour CRIU. Ça veut dire que si votre container a des connexions TCP sortantes au moment du checkpoint, elles seront perdues. Dans la pratique, pour un serveur web, ça veut dire qu’il faut reconnecter la base de données après restore. Avec zeropod, la connexion MySQL est refaite automatiquement (la requête PHP en cours échoue, la suivante réussit). C’est un détail qui peut avoir son importance selon les cas.
Je n’ai testé que WordPress (Apache + mod_php) et MySQL. Les applications avec des websockets, du streaming, ou des connexions longues pourraient se comporter différemment.
J’ai eu des difficultés à le faire correctement fonctionner sur k3s.
J’ai observé un glitch (segfault Apache) sur le premier restore d’un pod WordPress fraîchement créé. Ce n’est pas reproductible après un cycle checkpoint/restore normal, mais si vous redéployez souvent vos pods, vous pourriez le rencontrer.

Verdict

Un an après, zeropod me parait un peu plus tenir ses promesses :

Même si ce n’était pas rédhibitoire, le performances de checkpoint/restore se sont nettement améliorées (~50% plus rapide), ce qui est toujours bon à prendre
Le support des probes Kubernetes a été ajouté, le blocage principal selon moi est levé
La stabilité générale est meilleure
Le test cascade (WordPress + MySQL) fonctionne

Je reste toujours aussi hypé par l’idée qu’on puisse freezer un container et le restaurer 10 secondes plus tard comme si de rien n’était. La magie de CRIU et d’eBPF combinés commence à se matérialiser, après des années d’attente.

Est-ce que je mettrais ça en production ? Disons que c’est moins risqué qu’il y a un an. Pour rigoler sur mon cluster perso, pourquoi pas. Pour une base de données en prod avec des connexions longues, je pense que je passe toujours mon tour ;-).

Mais franchement, pour le coup, le projet a bien évolué et mérite qu’on s’y attarde.

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 2 - stockage)

Sun, 24 May 2026 18:00:00 +0200

Rappel de la partie 1

Dans la partie 1, on avait vu comment créer un cluster CKE, parcouru son anatomie (Exherbo Linux, Cilium, Materia etcd, konnectivity…), mesuré les temps de boot (~57s pour le control plane, excellent), testé les NodeGroups, et activé le CSI.

Dans cette deuxième partie, on va creuser ce qui touche au stockage et à des cas d’usages “un peu” avancés : cycle de vie des volumes, resize online, snapshots, et déploiement de vCluster avec données persistantes.

Activer le CSI et monter son premier volume

Comme on l’a vu en partie 1, le CSI n’est pas activé par défaut, mais un petit coup de CLI corrige ça rapidement :

clever k8s add-persistent-storage moncluster

Cette commande déploie le provisioner Ceph RBD et crée une StorageClass csi-rbd-sc qui devient la classe par défaut.

$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
csi-rbd-sc (default) rbd.csi.ceph.com Delete Immediate true

On notera au passage ALLOWVOLUMEEXPANSION: true : on y reviendra.

Créons un PVC tout bête :

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mon-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc.yaml
$ kubectl get pvc mon-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES
mon-pvc Bound pvc-2c2f058c-dc85-4006-865c-3437856462f5 1Gi RWO

Le binding prend environ 30 secondes (le temps que le provisioner crée l’image RBD dans le pool Ceph et l’attache). Rien de spécial, c’est du Kubernetes standard.

On monte le volume dans un pod, on écrit un fichier, on supprime le pod, on le recrée : les données sont toujours là. Jusque là, pas de surprise.

vCluster : un cas d’usage concret du stockage persistant

Maintenant qu’on a du stockage persistant, on peut faire des choses intéressantes. Généralement mon troll préféré, c’est de déployer Wordpress parce que évidemment Kubernetes c’est la meilleure plateforme pour déployer un Wordpress (/s).

Bon, cette fois ci j’ai décidé d’innover un peu et on va déployer vCluster (un cluster Kubernetes virtuel qui tourne dans votre cluster).

Note : à quoi ça sert, me direz vous ? Et bien, les usecases sont pas aussi clairs qu’on pourrait penser. vCluster vous donne un cluster Kubernetes complet, isolé, mais qui partage l’infrastructure du cluster hôte, y compris le CSI. En théorie ça permet de donner le cluster-admin à des gens sans donner les clés de l’infra complète à tout le monde. Je suis pas hyper convaincu par cette approche. Un usecase qui me parait moins dangereux, c’est pour des usages de type CI sans devoir monter un cluster complet, mais il y a des limitations aussi.

Installation :

vcluster create test-vcluster -n vcluster-test

Deux options pour s’y connecter :

Option 1 —> port-forward (le plus simple) :

$ vcluster connect test-vcluster -n vcluster-test -- kubectl get nodes
NAME STATUS ROLES AGE
control-plane-c367382a-22b1-4cef-b0cd-372bf83263c4-node Ready <none> 2m

vcluster connect monte un tunnel port-forward via l’API server (comme kubectl port-forward) et exécute la commande dans le contexte du vCluster. Ça marche sur CKE comme sur n’importe quel cluster Kubernetes.

Option 2 —> LoadBalancer (pour un accès durable sans tunnel) :

vcluster delete test-vcluster -n vcluster-test
vcluster create test-vcluster -n vcluster-test --expose --connect=false

Le flag --expose crée un Service LoadBalancer. On récupère l’IP et on génère un kubeconfig autonome :

$ LB_IP=$(kubectl get svc -n vcluster-test test-vcluster -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ vcluster connect test-vcluster -n vcluster-test \
 --server https://$LB_IP:443 \
 --insecure --print > /tmp/kube-vcluster.config

Le flag --insecure évite les soucis de certificat auto-signé, avec les risques de sécu que ça implique. A vos risques et périls… 💀

$ kubectl --kubeconfig /tmp/kube-vcluster.config get nodes
NAME STATUS ROLES AGE
test-vcluster Ready <none> 2m

Ce node test-vcluster contient tout notre cluster virtuel. Maintenant, la partie intéressante : créer un PVC dans le vCluster :

$ kubectl --kubeconfig /tmp/kube-vcluster.config apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc
EOF

C’est là où c’est sympa : le vCluster délègue la création du volume au cluster hôte, qui le provisionne via Ceph RBD. On a pas besoin de reconfigurer le CSI, les storage classes, les secrets, etc. C’est totalement transparent.

Petite vérification côté CKE :

$ kubectl get pvc -A | grep test-vcluster
vcluster-test pvc-<...> Bound 1Gi RWO csi-rbd-sc

Le PVC est bien créé dans le namespace du vCluster sur le cluster hôte.

Overhead mesuré :

Pod	CPU	RAM
`test-vcluster-0`	~80m	~342 Mi
coredns (vCluster)	~2m	~13 Mi

C’est tout à fait raisonnable. 342 MiB pour un control plane K8s complet, c’est dans les clous.

Conclusion vCluster : ça marche, y compris avec de la persistance. Si vous avez besoin d’isoler des environnements tout en gardant accès au CSI, vCluster sur CKE est une option fonctionnelle.

Note : il est aussi possible d’exposer le vCluster via un LoadBalancer (flag --expose) pour un accès direct sans tunnel. Pratique si le vCluster doit rester accessible après la fermeture de votre terminal.

Volume expansion : agrandir un volume à chaud

Vous avez une base de données qui grossit, vous avez provisionné 1Gi au départ et maintenant c’est juste. Avec allowVolumeExpansion: true sur la StorageClass, on peut agrandir le volume sans downtime.

kubectl patch pvc mon-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'

Côté Ceph, l’image RBD est redimensionnée immédiatement. Le PV passe à 2Gi :

$ kubectl get pv
NAME CAPACITY ACCESS MODES STATUS CLAIM
pvc-<...> 2Gi RWO Bound default/mon-pvc

Mais le PVC côté utilisateur reste à 1Gi et le filesystem XFS n’a pas encore été agrandi. Le kubelet finira par détecter le changement et déclencher le NodeExpandVolume tout seul (la synchronisation est périodique), mais on peut accélérer en supprimant et recréant le pod qui monte le volume :

$ kubectl delete pod mon-app --force --grace-period=0
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
 name: mon-app
spec:
 containers:
 - name: app
 image: alpine
 command: ["sleep", "3600"]
 volumeMounts:
 - mountPath: /data
 name: data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: mon-pvc
EOF

Dès que le volume est monté, le kubelet détecte qu’il a grandi et appelle le driver CSI pour un NodeExpandVolume. Le filesystem XFS est agrandi à chaud (xfs_growfs) et le PVC passe effectivement à 2Gi :

$ kubectl exec mon-app -- df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/rbd0 1.9G 47M 1.9G 1% /data

$ kubectl get pvc mon-pvc
NAME STATUS CAPACITY ACCESS MODES
mon-pvc Bound 2Gi RWO

VolumeSnapshots : le plus technique

Dernière fonctionnalité, et pas la plus simple : les snapshots de volumes.

Le driver Ceph RBD supporte les snapshots nativement. On le vérifie en regardant les logs du sidecar csi-snapshotter au moment de la création :

$ kubectl logs -n kube-system deployment/csi-rbdplugin-provisioner -c csi-snapshotter --tail=5
I0524 19:50:53.470970 snapshot_controller.go:339] createSnapshotWrapper: Creating snapshot for content snapcontent-<...> through the plugin ...

Pas d’erreur côté driver, la demande est acceptée et traitée.

Mais sur CKE, rien n’est pré-installé pour utiliser les snapshots. Il faut assembler les briques soi-même :

Étape 1 : installer les CRDs et le snapshot-controller

Les CRDs volumesnapshot* ne sont pas déployées sur CKE. Il faut les installer depuis le projet upstream external-snapshotter, ainsi que le snapshot-controller :

VERSION=v8.4.0
# CRDs
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
# Snapshot-controller (RBAC + deployment)
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Deux composants travaillent ensemble :

Le snapshot-controller (standalone) écoute les objets VolumeSnapshot et crée les VolumeSnapshotContent correspondants
Le csi-snapshotter (sidecar dans le provisioner) détecte les VolumeSnapshotContent et appelle le driver Ceph RBD pour créer/supprimer les snapshots

Les deux sont nécessaires.

Étape 2 : le piège des GroupSnapshot CRDs

Une fois les CRDs installées, vous créez votre VolumeSnapshotClass, votre VolumeSnapshot, et… rien ne se passe. Le VolumeSnapshotContent reste readyToUse: false indéfiniment.

Si vous regardez les logs du sidecar csi-snapshotter dans le provisioner, vous ne voyez aucune tentative de création de snapshot.

Pourquoi ? Parce que le sidecar est lancé avec un feature gate activé :

--feature-gates=CSIVolumeGroupSnapshot=true

Ce feature gate active le support des VolumeGroupSnapshot (la possibilité de snapshotter plusieurs volumes en une fois). Mais le sidecar attend les CRDs correspondantes pour initialiser son cache. Sans ces CRDs, le cache sync est bloqué, et le controller ne traite aucun VolumeSnapshot, pas même les snapshots unitaires (normaux, pas “group” quoi).

La solution : installer les CRDs groupsnapshot* :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshots.yaml

Puis redémarrer le provisioner pour que le sidecar recharge sa config. Attention : le provisioner a une anti-affinity qui empêche deux pods de cohabiter sur le même node. Sur un cluster ALL_IN_ONE (1 node), ça bloque le rollout. Il faut supprimer directement l’ancien pod :

kubectl delete pod -n kube-system -l app=csi-rbdplugin-provisioner --force

Ce problème est spécifique aux clusters ALL_IN_ONE. Sur DEDICATED_COMPUTE ou DISTRIBUTED (multi-nodes), l’anti-affinity ne sera probablement pas bloquante.

Étape 3 : le secret Ceph dans le VolumeSnapshotClass

Une fois le sidecar relancé, les logs montrent… une erreur :

rpc error: code = Internal desc = provided secret is empty

Le driver Ceph RBD a besoin des credentials Ceph pour créer un snapshot, exactement comme pour créer un volume. Vous les trouverez dans le secret csi-rbd-secret du namespace kube-system. La StorageClass les référence déjà pour le provisionning :

parameters:
 csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
 csi.storage.k8s.io/provisioner-secret-namespace: kube-system

Mais ces paramètres ne sont pas reportés automatiquement dans le VolumeSnapshotClass. Il faut les ajouter manuellement :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
 name: csi-rbd-snapclass
driver: rbd.csi.ceph.com
deletionPolicy: Delete
parameters:
 clusterID: <votre-cluster-id>
 csi.storage.k8s.io/snapshotter-secret-name: csi-rbd-secret
 csi.storage.k8s.io/snapshotter-secret-namespace: kube-system

Le clusterID est celui de la StorageClass (visible dans kubectl get sc csi-rbd-sc -o yaml).

Étape 4 : le snapshot fonctionne

$ kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: mon-snapshot
spec:
 volumeSnapshotClassName: csi-rbd-snapclass
 source:
 persistentVolumeClaimName: mon-pvc
EOF

$ kubectl get volumesnapshot mon-snapshot
NAME READYTOUSE SOURCEPVC RESTORESIZE AGE
mon-snapshot true mon-pvc 1Gi 6s

READYTOUSE: true immédiatement. Le snapshot Ceph RBD est créé en quelques secondes.

Étape 5 : restaurer un volume depuis un snapshot

Pour être VRAIMENT sûr que ça fonctionne, on peut faire un test (et oui, ça fonctionne)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-restored
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 dataSource:
 name: mon-snapshot
 kind: VolumeSnapshot
 apiGroup: snapshot.storage.k8s.io
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc-restored.yaml
$ kubectl get pvc pvc-restored
NAME STATUS VOLUME CAPACITY
pvc-restored Bound pvc-... 1Gi

Bilan global

Deuxième partie, deuxième bilan. Qu’est-ce qu’on retient ?

Les points forts :

CSI Ceph RBD : là encore, un bon choix. Ceph, ça fonctionne bien dans Kubernetes. Provisionning, persistence, resize online — tout fonctionne et ce n’est pas une surprise.
vCluster + CSI : pour faire plaisir à Akanoa, j’ai fait du kubeception (Kubernetes in Kubernetes) et ça m’a permis de tester une feature de vCluster que j’avais jamais essayée => la délégation transparente du CSI vers le CSI de l’hôte

Les points d’attention :

Les snapshots ne sont pas “out of the box” : CRDs manquantes, feature gate inattendu, secret à recopier. Je ferai un petit email aux copain⋅es parce que ça me parait dommage de pas l’ajouter

Encore merci à l’équipe Clever Cloud pour m’avoir donné accès en avant-première et pour avoir pris le temps d’échanger sur mes retours. Je ne sais pas s’il y aura un 3ème article ou non. Wait and see ;-P

Refonte de l'UI de GroROTI

Fri, 22 May 2026 12:00:00 +0200

Si vous lisez régulièrement ce blog et mes aventures sur les réseaux sociaux, vous savez que j’aime énormément l’infrastructure, un peu le code backend (surtout en Golang), mais que dès qu’il s’agit de concevoir une interface graphique moderne et agréable, il n’y a plus personne.

C’est un fait établi, je n’ai aucune compétence en développement front. Dommage pour les offres FullSteak (jeu de mot pourri, mais plutôt approprié ici).

C’est exactement ce qui pénalisait GroROTI, un petit outil web open source en Go que j’avais développé en 2024 (en partie sur mon temps libre, en partie lorsque j’étais chez mon ancien employeur, ce qui explique pourquoi le dépôt soit hébergé sur leur GitHub).

Pour rappel, l’application permet d’évaluer rapidement et anonymement la qualité des réunions ou des ateliers via le format ROTI (Return On Time Invested).

Le problème, c’est que l’outil était fonctionnel, mais franchement moche. Un petit look Web 1.0, voire soviétique, qui était franchement assumé dans un premier temps, mais dont on se lasse assez vite.

Qu’à cela ne tienne. Fort de mes expériences plutôt concluantes avec la refonte de ma page Conférence (cf “Refonte de la page Conférences : data-driven avec Hugo”) et la v3 de mon projet pour cataloguer toutes les manières de déployer Kubernetes (cf “101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s’améliore”), j’ai fait chauffer un LLM perso pour lui demander de m’aider à rendre ça un peu plus agréable à l’oeil.

Le résultat va bien au-delà de mes compétences (“la barre est au sol” comme on dit). Si on compare les captures d’écran avant (à gauche) et après (à droite), le changement est flagrant :

Une page d’accueil transformée : Fini l’alignement de texte un peu triste. On passe sur une interface épurée, une colorimétrie violette moderne (petit clin d’oeil), un bloc de création “New ROTI” bien délimité et une barre latérale pour afficher les derniers examens créés.

Des résultats clairs : La page de restitution des votes affiche désormais la moyenne globale en grand, ainsi que le nombre de participants et les valeurs minimales et maximales sous forme de “cartes”. Le QR code de partage est lui aussi bien mieux intégré visuellement.

Un système de notation plus intuitif : Le vieux curseur glissant a été remplacé par un système de notation à 5 étoiles (avec support des demi notes) bien plus classique et parlant pour les utilisateurs. Le tout reste accompagné d’une zone de texte (redesignée) pour les retours optionnels, quand ils sont activés.

Juste un lifting

Sous le capot, l’application reste la même, je n’ai pas touché au code backend (*), juste la partie templates HTML (gotpl) et CSS.

(*) c’est pas 100% vrai, j’ai fait quelques modifs en 2025, notamment pour ajouter du tracing otel, support de la CR ServiceMonitor, amélioration du build multi arch et quelques bugfixes… dont je ne vous avais pas parlé.

Au final, ce petit truc en plus fait la diff entre un tool interne que je n’avais pas trop envie de mettre en avant, et un outil qui me parait utilisable en dehors de mon contexte pro :

https://github.com/deezer/GroROTI

nodes/proxy GET : la permission Kubernetes de trop

Tue, 19 May 2026 12:00:00 +0200

TL;DR

Ca date un peu mais j’avais quand même envie de faire un petit REX sur ce sujet.

En janvier un chercheur en cybersécurité a remonté une faille de Kubernetes qui a pas mal fait le buzz. Ca faisait un moment qu’on avait plus eu de faille sur Kube qui fasse autant parler, de mémoire de Denis (oui je parle de moi à la 3ème personne).

En vrai, c’est assez chaud : la permission RBAC nodes/proxy GET permet à n’importe quel ServiceAccount d’exécuter du code dans n’importe quel Pod du cluster, sans laisser la moindre trace dans les logs d’audit. C’est facheux, surtout quand vous avez des ServiceAccount qui se nomment rook-ceph-system et qui cumulent également un accès en lecture à tous les Secrets du cluster.

Cet article détaille le problème, la façon dont on peut vérifier si on est vulnérable, les correctifs à appliquer, et les mesures de prévention qui peuvent être mises en place si vous ne pouvez pas fix.

Le problème : WebSocket + Kubelet = exec sans audit

La vulnérabilité a été documentée par Graham Helton dans cet article. Le principe est le suivant.

L’API Kubernetes expose une sous-ressource nodes/proxy qui proxifie les requêtes HTTP vers le Kubelet de chaque node. Le Kubelet lui-même expose une API sur le port 10250, notamment l’endpoint /exec qui permet d’exécuter des commandes dans un container.

Le problème vient de la façon dont le Kubelet gère les autorisations pour les connexions WebSocket :

kubectl exec utilise une connexion WebSocket, dont le handshake est un GET HTTP
Le Kubelet mappe ce GET initial vers le verbe RBAC get
Il vérifie nodes/proxy GET, puis autorise l’opération
Aucune vérification secondaire n’est faite pour le verbe CREATE normalement requis pour /exec

Résultat : n’importe quel ServiceAccount avec nodes/proxy GET peut exécuter des commandes dans n’importe quel Pod du cluster, y compris les Pods système (etcd, kube-apiserver, etc.).

# Exploitation via websocat
websocat --insecure \
 --header "Authorization: Bearer $TOKEN" \
 --protocol "v4.channel.k8s.io" \
 "wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&command=id"

Et c’est pas fini. Les commandes exécutées via cette méthode ne génèrent aucun log d’audit Kubernetes (enfin bon, peut être que vous les collectez pas 🙈). L’accès passe directement par le Kubelet, qui ne remonte pas d’événements à l’API server.

Le statut officiel de Kubernetes sur ce sujet : Won’t Fix. C’est un “comportement intentionnel” (notez les guillemets), corrigé par une feature gate (KEP-2862, voir plus bas).

Ca pique.

L’audit : des ServiceAccounts vulnérables sur nos clusters

En janvier 2026, suite à la publication de l’article de Graham Helton, beaucoup de gens ont du auditer en urgence leurs clusters. On peut soit auditer soit même l’ensemble de ses Roles / ClusterRoles, soit utiliser un script de détection fourni par le chercheur.

Pour l’exemple, voici trois composants relativement courants et qui peuvent être de bons candidats pour une belle élévation de privilèges :

Composant	ClusterRole	ServiceAccounts
OpenTelemetry Collector	`otel-otelcol-k8sobjects`	`opentelemetry-collector-daemonset-collector`, `opentelemetry-collector-deployment-collector`
OpenTelemetry Operator	`otel-operator-resources` / `opentelemetry-operator-manager`	`opentelemetry-operator`
Rook-Ceph	`rook-ceph-global`, `rook-ceph-mgr-cluster`	`rook-ceph-system`, `rook-ceph-mgr`

Note : il y en a beaucoup plus, Graham Helton a ajouté une section “Appendix: Affected Helm Charts” en fin d’article, qui référence AU MOINS 69 helm charts concernées selon lui.

Le cas critique : rook-ceph-system

Dans la chart officielle, le ServiceAccount rook-ceph-system cumulait deux permissions particulièrement dangereuses :

nodes/proxy GET - la RCE
secrets GET/LIST/WATCH sur tout le cluster

Les secrets accessibles peuvent notamment inclure des clés LUKS de chiffrement des volumes, les keyrings Ceph admin, et les mots de passe du dashboard… ce genre de permissions en fait une cible de choix pour un attaquant.

Le scénario d’attaque : une compromission du Pod rook-ceph-operator (via CVE, supply chain, ou image malveillante) permettrait de lire tous les secrets Ceph, puis d’exécuter du code dans n’importe quel Pod (y compris etcd) aboutissant à une compromission complète du cluster et des données chiffrées.

Pour vérifier manuellement si un ServiceAccount est vulnérable :

kubectl auth can-i get nodes --subresource=proxy \
 --as=system:serviceaccount:<namespace>:<serviceaccount>

Exemples de correctifs à appliquer

Rook-Ceph : fix upstream

Pour Rook-Ceph, le fix est venu de l’upstream : la PR rook/rook#16979 a supprimé nodes/proxy des ClusterRoles. Ce fix est inclus dans Rook v1.19.1, il suffisait donc de mettre à jour les clusters concernés.

Après mise à jour, vérification sur tous les clusters :

kubectl get clusterroles rook-ceph-global -o yaml | grep -A3 nodes/proxy
# -> rien

OTel / Otel operator

Pour OpenTelemetry, la situation est potentiellement plus complexe. Si vous utilisez otel-operator et les Custom Resource OtelCollector, il est probable que vous deviez gérer vous même vos propres manifests RBAC.

Pour avoir eu à le faire, c’est assez pénible, en fonction de votre type de collecteur et des receivers que vous avez activés, il est nécessaire de croiser plusieurs documents sur les sites officiels d’otel et otel-operator.

L’upstream avait mergé une approche conditionnelle dans open-telemetry/opentelemetry-helm-charts#2083 basée sur la version Kubernetes :

# Approach upstream (opentelemetry-helm-charts#2083)
{{- if semverCompare ">=1.33-0" .Capabilities.KubeVersion.Version }}
 - nodes/pods
{{- else }}
 - nodes/proxy
{{- end }}

Là encore, si tous vos clusters sont à jours, vous avez simplement à remplacer nodes/proxy par nodes/pods directement (sans conditionnel).

otel-collector-crb.yaml :

# Avant
rules:
 - apiGroups: [""]
 resources:
 - nodes
 - nodes/proxy  # ← RCE risk
 - nodes/spec
 - nodes/stats
 verbs:
 - get

# Après
rules:
 - apiGroups: [""]
 resources:
 - nodes
 # nodes/pods replaces nodes/proxy (RCE risk, see https://grahamhelton.com/blog/nodes-proxy-rce)
 # Requires K8s >= 1.33 (KEP-2862 fine-grained kubelet authz)
 - nodes/pods
 - nodes/spec
 - nodes/stats
 verbs:
 - get

otel-operator-rbac.yaml :

# Avant
 - apiGroups: [""]
 resources:
 - nodes/proxy  # ← RCE risk
 verbs:
 - get

# Après
 # nodes/pods replaces nodes/proxy (RCE risk, see https://grahamhelton.com/blog/nodes-proxy-rce)
 # Requires K8s >= 1.33 (KEP-2862 fine-grained kubelet authz)
 - apiGroups: [""]
 resources:
 - nodes/pods
 verbs:
 - get

Les mesures préventives

KEP-2862 : Fine-Grained Kubelet API Authorization

On l’a déjà un peu teasé, la vraie solution long terme est la KEP-2862 (Fine-Grained Kubelet API Authorization). Elle introduit des sous-ressources granulaires (nodes/pods, nodes/metrics, nodes/stats, nodes/log, etc.) qui permettent de donner des accès précis sans passer par nodes/proxy.

Version K8s	Statut KEP-2862
1.32	Alpha
1.33	Beta, activé par défaut — `nodes/proxy GET` ne donne plus accès à `/exec`
1.36	GA (locked to enabled)

Mais ça nécessite de passer sur TOUTES les charts utilisées et vérifier tous les manifests déployés maintenant et dans le futur.

CiliumNetworkPolicy : bloquer le port Kubelet

En attendant la mise à jour K8s, ou (et ?) comme défense en profondeur, on peut aussi bloquer l’accès au port 10250 depuis les pods concernés via NetworkPolicies (ou CiliumNetworkPolicy si vous avez Cilium comme CNI plugin).

Attention : cela ne s’applique qu’aux composants qui n’ont pas besoin d’accéder au Kubelet. OTel collector en a potentiellement besoin pour collecter les métriques du kubelet. Dans ce cas, pas le choix, on ne peux que corriger le RBAC.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: deny-kubelet-api-access
 namespace: <namespace>
spec:
 endpointSelector:
 matchLabels:
 <app-label>: <value>
 egressDeny:
 - toEntities:
 - host
 - remote-node
 toPorts:
 - ports:
 - port: "10250"
 protocol: TCP

Kyverno : bloquer la création de nouveaux Roles avec nodes/proxy

Note : a priori j’ai découvert un trou dans la policy officielle de Kyverno, j’ai ouvert une issue

Pour éviter toute régression (j’ai dit qu’il fallait se protéger dans le futur), on peut aussi ajouter une ClusterPolicy Kyverno qui refuse la création ou modification de ClusterRole/Role contenant nodes/proxy.

On a de la chance, il existe déjà des exemples prêt à l’emploi sur le site officiel de Kyverno :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: restrict-nodes-proxy
spec:
 validationFailureAction: Audit  # passer en Enforce après validation
 background: true
 rules:
 - name: deny-nodes-proxy-in-clusterroles
 match:
 any:
 - resources:
 kinds:
 - ClusterRole
 - Role
 exclude:
 any:
 - resources:
 names:
 - "system:kubelet-api-admin" # built-in K8s, non modifiable
 validate:
 message: >
 nodes/proxy grants RCE capability via Kubelet WebSocket exec.
 Use nodes/pods (requires K8s >= 1.33, KEP-2862) instead.
 deny:
 conditions:
 any:
 - key: "nodes/proxy"
 operator: AnyIn
 value: "{{ request.object.rules[].resources[] }}"

Le déploiement se fait en deux temps : d’abord en mode Audit pour vérifier qu’il n’y a plus de manifests vulnérables (qu’on préférera fix avant de bloquer), puis en Enforce pour bloquer effectivement.

Surveillance de l’audit log

Même si les commandes exécutées via le Kubelet ne laissent pas de trace, on peut surveiller les SubjectAccessReviews pour détecter les tentatives d’énumération de permissions nodes/proxy.

La configuration dans la policy d’audit Kubernetes :

# audit-policy.yaml
- level: Request
 verbs: ["create"]
 resources:
 - group: "authorization.k8s.io"
 resources: ["subjectaccessreviews"]

Puis une alerte Prometheus/Alertmanager sur les SAR qui concernent nodes/proxy :

# Détecter les SAR portant sur nodes/proxy
increase(
 apiserver_audit_event_total{
 verb="create",
 resource="subjectaccessreviews"
 }[5m]
) > 0

Références

Kubernetes RCE via nodes/proxy GET — Graham Helton
Script de détection
KEP-2862 Fine-Grained Kubelet API Authorization
Kubernetes RBAC Good Practices - nodes/proxy
rook/rook#16979 - Fix upstream Rook-Ceph
open-telemetry/opentelemetry-helm-charts#2083 - Fix upstream OTel

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 1)

Tue, 12 May 2026 12:00:00 +0200

La suite de ma saga avec Clever Cloud

Ça fait maintenant quelques années que je teste les produits de Clever Cloud sur ce blog. En 2022, j’avais testé le Clever Kubernetes Operator, qui permet de provisionner des services managés (MySQL, Redis, Pulsar…) directement depuis un cluster Kubernetes via des CRDs. En 2025, j’ai réessayé leur offre d’hébergement de sites statiques, et j’ai même poussé le délire jusqu’à déployer un control plane Kubernetes sur leurs apps Linux, pour rigoler en attendant leur offre managée.

Bref, à la fin de cet article, je concluais avec un trollface et un “j’attends mon accès au k8s managé de Clever Cloud”. Et bien… c’est maintenant !

Clever Cloud a lancé CKE (Clever Kubernetes Engine) en bêta publique. J’ai eu accès en avant-première pour tester et je leur ai fait quelques retours. Maintenant que le produit est public, j’ai enfin le droit de vous partager mes impressions.

CKE c’est quoi exactement ?

CKE est l’offre Kubernetes managée de Clever Cloud. Le positionnement est clair : Vanilla Kubernetes, pas de lock-in, le plus standard possible dans l’usage du cluster.

Ce qui distingue CKE des offres plus conventionnelles, c’est ça :

Materia etcd : leur implémentation maison de l’API etcd, construite sur FoundationDB (pas d’etcd VM à provisionner ou dimensionner, c’est serverless). C’était pas gagné, cf cet article de Pierre Zemb “Diving into Kubernetes’ Watch Cache”
Infrastructure souveraine et isolée des autres clients : tout tourne sur des VMs dédiées, en France. Rien de mutualisé entre tenants.
Cilium + eBPF natif, avec WireGuard pour le chiffrement inter-nodes.

Activation : c’est un peu caché

CKE est en bêta publique, mais l’accès n’est pas actif par défaut. Il faut l’activer, soit via la CLI :

clever features enable k8s

Note : les commandes clever k8s sont disponibles dans la CLI à partir d’une version récente de leur CLI, idéalement version 4.9+.

Soit depuis l’interface web, dans l’onglet Labs de votre compte : https://console.clever-cloud.com/users/me/feature-list

L’onglet Labs n’est pas particulièrement mis en avant dans la console (il faut savoir où chercher). Une fois le feature flag activé, un nouveau menu apparaît dans la console.

Création d’un cluster

Depuis la CLI, voici la commande minimale pour créer un cluster :

clever k8s create moncluster --watch

--watch suit le déploiement jusqu’à ce que le cluster soit ACTIVE. En pratique, ça ressemble à ça :

⏳ Cluster status: DEPLOYING. Waiting for 10s before checking again...
✓ Cluster moncluster (kubernetes_01KRDDW6YNMDE7ZT0RYD3MY0GE) deployed successfully

On peut passer tout un tas d’options : version K8s (--cluster-version 1.36), topology, flavor du control plane, replication factor, autoscaling, CSI… On y reviendra.

Mais il est aussi possible, depuis peu, de créer un cluster via formulaire de création, avec un récapitulatif en temps réel.

On y retrouve tous les paramètres : version K8s, topology, flavor, replication factor, autoscaling, persistent storage. C’est bien fait, les topologies sont expliquées inline. Le nom de cluster est généré aléatoirement (style cunning-arcane-runic-corsair, modifiable bien sûr).

Les 3 topologies : Essential, Business, Enterprise

C’est l’un des aspects les plus inhabituel de CKE. Trois topologies sont disponibles à la création (et immutables après, ce qui oblige à bien choisir dès le départ).

Topology	Offre	Ce que vous payez	Usage typique
`ALL_IN_ONE`	Essential	rf (replication factor) × VM bundle (CP + worker intégré)	Dev, test, petits clusters
`DEDICATED_COMPUTE`	Business	rf × VM CP + chaque worker VM	Prod avec isolation CP/workers
`DISTRIBUTED`	Enterprise	5 composants × rf × VM + workers	Prod HA fine par composant

ALL_IN_ONE est la topologie par défaut. Le control plane et un worker node partagent la même VM (c’est le mode k3s-style, pour reprendre la description de la console). Ça a une conséquence concrète : kubectl get nodes liste le node du control plane comme worker disponible pour les pods.

DEDICATED_COMPUTE isole le CP sur ses propres VMs, les workers sont dans des node groups séparés. Avec un replication factor de 3, les VMs sont réparties sur les 3 datacenters parisiens de Clever Cloud (un datacenter peut tomber sans impacter le control plane).

DISTRIBUTED pousse l’isolation plus loin : chaque composant du CP (apiserver, controller-manager, scheduler, cloud-controller-manager, node-group-operator) tourne sur sa propre VM, avec sa propre flavor et son propre replication factor. J’ai du mal à voir dans quel cas c’est utile, mais pourquoi pas.

Un mot sur la tarification

Contrairement à certains cloud providers (de moins en moins cela dit…) qui offrent parfois le control plane quand il est mutualisé et ne facturent que les workers, Clever Cloud facture une vraie VM dédiée par cluster (rien de mutualisé entre tenants).

En ALL_IN_ONE, cette VM fait aussi office de worker, ce qui en fait paradoxalement l’option la moins chère. La flavor S (8 vCPU / 12 GB RAM) revient à 64 €/mois, CP et workers inclus sur la même machine. L’isolation se paye davantage : DEDICATED_COMPUTE commence à 96 €/mois pour le CP seul (+ workers séparés), DISTRIBUTED à 180 €/mois minimum pour 5 composants CP en 2XS.

Ce n’est pas donné pour du dev, mais le prix s’explique par le choix architectural : vous avez vraiment 8 vCPU / 12 GB de RAM rien que pour vous, pas un dixième de VM partagée entre dix clients.

Note : pendant la bêta publique, le CSI (Ceph) et les LoadBalancers ne sont pas encore facturés. Seuls le CP et les workers le sont.

Récupérer le kubeconfig

clever k8s get-kubeconfig moncluster > ~/.kube/clever.yaml
kubectl --kubeconfig ~/.kube/clever.yaml get nodes

Un détail à noter : l’API server écoute sur un port non standard (1032 ou 1022 selon les clusters). Ce n’est pas bloquant dans la plupart des environnements, mais j’ai eu la surprise de me retrouver bloqué depuis un réseau qui filtre les ports non-standards. À garder en tête si vous devez accéder au cluster depuis un réseau d’entreprise restrictif.

Anatomie du cluster

Une fois connecté, quelques observations :

$ kubectl get nodes -o wide
NAME STATUS VERSION OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
control-plane-be4e3383-...-node Ready v1.36.0 Exherbo Linux 6.19.14-clevercloud-vm-dirty (amd64) containerd://2.3.0

Exherbo Linux : on retrouve bien la marque de fabrique de Clever Cloud. Pour celleux qui ne connaissent pas, Exherbo est une distro minimaliste et source-based, peu connue en dehors de cercles très spécialisés. Le kernel est un build custom Clever Cloud (clevercloud-vm-dirty), et le container runtime est containerd 2.3.0.

Les composants pré-installés dans kube-system :

$ kubectl get pods -A
NAMESPACE NAME READY
kube-system cilium-tv9m7 1/1 # CNI
kube-system cilium-operator-7db7f998d7-z5zq8 1/1
kube-system coredns-5986bf5c44-wkzb9 1/1
kube-system konnectivity-agent-l26kl 2/2 # proxy CP->workers
kube-system kube-state-metrics-75b86d74f6-6slx8 2/2
kube-system kubelet-csr-approver-68d5bfcb6b-kgz5c 1/1
kube-system metrics-server-559c9b85f9-wflvk 1/1
kube-system cc-collector-wwpld 1/1 # collecteur OTel Clever Cloud

Quelques absences notables par rapport à une install classique : pas de kube-proxy (remplacé par Cilium en mode eBPF kube-proxy replacement).

Pour la petite histoire, les premiers teasers de CKE avaient montré l’usage de flannel. Heureusement que les équipes de clever ont écouté la communauté et migré vers cilium.

Konnectivity : l’isolation réseau du control plane

Le pod konnectivity-agent mérite une mention. C’est un composant qu’on retrouve assez souvent sur les Kubernetes managés et certaines distribution de Kubernetes. Il tourne sur chaque node (2 containers : proxy-agent + haproxy) et sert de proxy entre le control plane et les workers. Le CP ne parle pas directement aux pods : tout le trafic CP->workers (logs, exec, port-forward, métriques) passe par ce tunnel.

Pour un service managé, c’est la bonne pratique : le control plane n’a pas besoin d’accès réseau direct aux pods, et les workers n’ont pas besoin d’exposer kubelet directement au CP.

Materia etcd

Pas de pod etcd dans le cluster : c’est normal. Clever Cloud utilise Materia etcd, leur implémentation serverless de l’API etcd construite sur FoundationDB. C’est transparent pour vous.

Cilium

Le CNI est Cilium v1.19.1. Pour aller plus loin sur l’intégration Cilium/CKE, je vous recommande l’article de Joseph qui est le premier à en avoir parlé publiquement et qui s’y connaît bien mieux que moi sur le sujet.

Les NodeGroups

Les workers sont gérés via une CRD custom NodeGroup (groupe api.clever-cloud.com/v1).

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
 name: mes-workers
spec:
 flavor: S
 nodeCount: 3

kubectl apply -f nodegroup.yaml

Les nodes apparaissent dans kubectl get nodes environ 35-40 secondes après la création du NodeGroup. La CRD supporte le subresource scale, ce qui permet de faire :

kubectl scale nodegroup mes-workers --replicas=5

Les flavors disponibles en ALL_IN_ONE : S (8 vCPU / 12 GB), M (10 vCPU / 16 GB), L (12 vCPU / 24 GB), XL (16 vCPU / 32 GB). Un quota global s’applique au niveau de l’organisation (40 vCPU / 40 GB RAM par défaut, tous clusters confondus). Ca peut probablement être augmenté en faisant une demande au support, mais j’ai pas assez d’argent à crâmer pour justifier une telle demande 😅.

En cas de dépassement de quota, le NodeGroup passe en phase QuotaExceeded avec un message d’erreur très lisible :

'Quota exceeded: RAM max: limit = 40.0 GB | actual = 48.0 GB | excess = 8.0 GB'

C’est appréciable : on sait exactement ce qui bloque et de combien.

La CLI propose aussi une gestion des node groups :

clever k8s nodegroups create moncluster workers M:3
clever k8s nodegroups update moncluster workers --count 5
clever k8s nodegroups update moncluster workers --autoscaling --min 2 --max 10

Combien de temps pour booter ?

Un des points forts mis en avant par Clever Cloud. J’ai mesuré avec un script de benchmark (3 runs) et via la commande clever k8s activity qui expose les timestamps précis de chaque étape :

clever k8s activity moncluster --format json

[
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "STARTED", "createdAt": "2026-05-12T06:27:11Z" },
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "COMPLETED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "STARTED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "COMPLETED", "createdAt": "2026-05-12T06:28:01Z" }
]

activity détaille chaque étape du bootstrap : création du réseau, déploiement de Materia LogicalDB, déploiement du control plane, configuration du load balancer, installation des plugins. Elle couvre aussi les opérations sur les NodeGroups.

Résultats mesurés (K8s 1.35, 3 runs, 5 nodes S) :

Étape	Moyenne
Cluster DEPLOYING -> ACTIVE	~57s
NodeGroup -> 1er node Ready	~38s
NodeGroup -> tous les nodes Ready	~46s (donc 8s après le premier node)
Suppression du cluster (API)	~244ms

Pour comparaison, SKS d’Exoscale bootstrappe le control plane en ~2 minutes (on me souffle dans l’oreille que ça a peut être baissé depuis). Et à la bonne époque où je faisais du AKS, c’était carrément 20+ minutes (j’espère qu’ils se sont améliorés depuis). Clever Cloud se place très haut sur ce critère.

Réseau, services, sécurité

LoadBalancer: chaque service de type LoadBalancer provisionne un L4 LB avec deux IPs publiques dédiées.

Ingress : pas d’ingress controller préinstallé. Traefik s’installe sans problème via Helm.

NetworkPolicies : Cilium étant le CNI natif, les NetworkPolicies sont enforced nativement. Pas besoin d’installer quoi que ce soit en plus.

Note pour ceux qui auraient lu mon article de mars sur le CNI chaining Flannel/Cilium : cet article était né des tests sur la bêta privée de CKE, qui utilisait Flannel à l’époque. Depuis le passage en bêta publique, CKE livre Cilium nativement (les NetworkPolicies fonctionnent out of the box).

Pod Security Admission : aucun namespace n’a de labels PSA par défaut (ni kube-system, ni default). Ça signifie que les pods sont en mode privileged implicite, sans restriction. On peut bien sûr configurer ça soi-même, mais sur un cluster managé on s’attendrait à avoir au minimum des profils baseline ou restricted préconfigurés sur les namespaces utilisateur.

RBAC : pas de surprise, le kubeconfig fourni donne un accès cluster-admin. A ne pas utiliser au delà de l’administration initiale ;-).

Stockage (CSI)

Le CSI n’est pas activé par défaut. Pour l’activer :

clever k8s add-persistent-storage moncluster

Activation en ~1 minute. Une StorageClass csi-rbd-sc (défaut) est créée, provisionnée par rbd.csi.ceph.com (Ceph RBD), filesystem XFS, volume expansion activée.

Les tests complets du cycle de vie (PVC, resize, snapshots) feront l’objet de la partie 2.

Un vrai déploiement : GroROTI

Histoire de valider que tout fonctionne de bout en bout, j’ai déployé GroROTI (ma propre application web en golang de ROTI) via Helm, avec Traefik en ingress controller et un certificat TLS.

helm install traefik traefik/traefik -n traefik --create-namespace
helm install groroti oci://ghcr.io/zwindler/groroti-chart \
 -f values-clever.yaml \
 --namespace groroti --create-namespace

Au bout de quelques minutes, l’application tourne sur groroti.zwindler.fr, accessible publiquement, TLS inclus. Ça fonctionne.

Bugs rencontrés (alpha / bêta oblige)

LoadBalancer : lors de mes premiers tests (alpha / bêta privée), j’avais eu un cas où l’EXTERNAL-IP restait en <pending> pendant… 32 heures. Ce problème semble avoir disparu en bêta publique.

Cluster FAILED sans diagnostic : lors de mes tests, j’ai eu plusieurs clusters qui passaient en FAILED ~25 secondes après la création, sans aucun message d’erreur exploitable. clever k8s get <ID> retourne juste Status: FAILED, même avec --verbose. Aucune commande logs ou events pour un cluster n’existe dans la CLI.

C’est d’autant plus frustrant que le status QuotaExceeded des NodeGroups est, lui, extrêmement bien documenté dans le message d’erreur. Il y a une belle asymétrie là.

Le bug a été résolu côté Clever Cloud dans la nuit. Mais le manque de diagnostic reste un point à améliorer. L’UI est aussi encore clairement en bêta, avec un petit bug graphique que j’ai pu remonter.

Conclusion (partie 1)

Première impression globalement positive. CKE est impressionnant pour une bêta :

Boot time excellent : ~57s pour le cluster (CP à part ou All in one), ~38s pour le premier node quand on ajoute des NodeGroups (dans le haut du panier des Kubernetes managés que j’ai testé au fil des années)
Cilium natif avec WireGuard inter-nodes, NetworkPolicies out of the box
Materia etcd sur FoundationDB : une approche originale pour gérer les problématiques etcd (scalabilité, multi tenancy) d’un cloud provider
Design CRD propre pour les NodeGroups, compatible kubectl scale
Konnectivity : isolation réseau du CP comme chez les grands cloud providers

Les points à améliorer : diagnostic du status FAILED, PSA non configurée par défaut, pas d’ingress controller inclus.

J’ai aussi une petite feature que j’ai demandé à Antoine chez Clever, l’audit logging, c’est en cours. Wait and see ;-).

La tarification du control plane me parait un poil élevée, typiquement face à des concurrents européens comme SKS ou Kapsule (mode mutualisé), mais elle s’explique par le choix architectural (VMs dédiées, rien de mutualisé). Pour une équipe déjà sur Clever Cloud, l’intégration avec le Clever Kubernetes Operator et les add-ons managés est un vrai argument.

Dans la partie 2, on creusera sûrement plus de fonctionnalités, comme le CSI (lifecycle PVC, resize, snapshots), les upgrades de cluster, l’intégration avec Clever Cloud operator (justement). Peut être aussi qu’on testera vCluster ou k3k ?

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

DevoxxFR 2026 - Récap du vendredi (jour 3)

Fri, 24 Apr 2026 16:00:00 +0200

Les résumés des 3 jours de DevoxxFR 2026

Troisième jour de DevoxxFR 2026

Dernier jour, et surtout pour moi : c’était le créneau de notre talk.

Entre le “petit” stress avant de monter sur scène, la tension des démos live, puis le relâchement après coup, cette journée a eu une saveur différente. Moins de talks que les deux jours précédents dans mon programme, et je suis un peu rincé dans mon train retour.

Limits, Requests, QoS, PriorityClasses, démystifions le scheduling dans Kubernetes

C’était notre session, avec un objectif simple : rendre concret un ensemble de concepts que tout le monde voit passer (requests, limits, classes de QoS, PriorityClass, ordonnancement), mais qui restent souvent flous tant qu’on ne les voit pas en situation réelle.

Le format est maintenant bien rodé (on l’avait déjà donné notamment au DevFest Nantes et à Touraine Tech 2026), mais cette édition était clairement notre meilleure exécution jusqu’ici :

transitions très fluides ;
démos live qui ont toutes fonctionné ;
bon rythme entre explication pédagogique et incidents provoqués ;
super interactions avec la salle et beaucoup de questions à la sortie.

On a eu plusieurs personnes qui sont venues nous voir spontanément après la session pour échanger sur leurs cas de prod. C’est exactement ce qu’on espérait : démystifier, puis rendre actionnable.

Plusieurs personnes sont aussi venues simplement nous féliciter à la sortie, et ça m’a vraiment touché.

Côté feedback, les retours ont été excellents, avec une note moyenne de 4.91/5 (45 évaluations) et des commentaires très positifs sur la clarté, l’humour et les démos.

Deux retours (parmi 17 !!!) qui résument bien l’esprit de la session :

“Très dynamique, un magnifique récap et des démos vraiment bien construites et claires. Merci pour ce moment de partage.”

“Des concepts un peu obscurs pour les développeurs, enfin démystifiés, avec de l’humour et des démos qui marchent (toutes !), et des conseils simples et actionnables.”

Franchement, gros moment de satisfaction.

Interview au Studio Devoxx

J’avais aussi un enregistrement prévu au Studio Devoxx, le nouveau format vidéo/podcast de la conférence.

J’étais un peu stressé au départ, mais Emmanuel Bernard m’a rapidement mis à l’aise. Très vite, la discussion est devenue naturelle et très agréable.

On a parlé de Kubernetes (avec quelques anecdotes de production), de notre talk du jour, et aussi de l’écriture technique autour de mon livre Kubernetes : 50 solutions pour les postes de développement et les clusters de production.

Curieux de voir le rendu final quand l’épisode sortira.

Kubernetes et la JVM

Je voulais absolument assister à cette session de Jean-Michel Doudoux et Alain Regnier (SCIAM), par curiosité sur l’angle JVM en environnement Kubernetes.

Talk avec de nombreux rappels des fondamentaux, aussi bien sur Kubernetes que sur Java :

warmup JVM, tiered compilation, impacts du JIT (C1/C2) sur les phases de démarrage ;
importance des ressources CPU allouées (démo assez parlante : 37s de démarrage avec 200m CPU contre 2s avec 1000m) ;
choix du garbage collector influencé par les ressources disponibles ;
détection des limites container et évolutions côté Java (container awareness, MaxRAMPercentage, support cgroups v2) ;
sujets de startup time (Class Data Sharing, AOT) et compromis de GraalVM natif.

Un autre sujet intéressant évoqué : CRaC (Coordinated Restore at Checkpoint), encore très expérimental, qui vise à réduire drastiquement le warmup en s’appuyant sur un mécanisme de checkpoint/restore CRIU, que je suis avec une grande attention (j’en ai déjà parlé plusieurs fois sur le blog, notamment quand je vais au FOSDEM).

Petite réserve : une reco sur Kaniko apparaissait encore dans les slides, alors que le projet est archivé depuis fin 2025.

Globalement, le talk balayait beaucoup de concepts sans forcément rentrer en profondeur sur chacun, je regrette un peu de ne pas plutôt être allé à “Fini les nuits difficiles: Comment l’IA a transformé nos astreintes” de Jean-Philippe Fourès.

Hallway track (encore et toujours)

Comme souvent à Devoxx, une grosse partie de la valeur se joue aussi entre les salles : discussions improvisées, débriefs à chaud, retrouvailles et nouvelles rencontres.

Un peu rincé par cette matinée riche en émotions, j’ai aussi fini de collecter les awards qui me manquaient sur l’app mobile compagnon : j’ai été le 9e à atteindre les 6400 points. Gamification, quand tu nous tiens.

Le format “dernier jour” donne un petit côté bilan collectif, et c’était très sympa de croiser encore plein de monde (Florian, Olivier, Jean-Philippe, Jérôme, Carine, Alexandre, Emmanuel).

Merci particulier à Brian et Quentin, mes collègues Luccasiens, qui ont donné à ce DevoxxFR une saveur spéciale. C’est beaucoup plus chouette de faire une conférence entre collègues que seul (ce que j’ai souvent fait).

Fin de DevoxxFR 2026

Ce DevoxxFR 2026 était encore une très belle édition.

Côté perso, je repars surtout avec :

la satisfaction d’avoir donné notre meilleure version du talk ;
des discussions de fond sur Kubernetes et l’évolution de nos pratiques ;
quelques idées à creuser, au fil des discussions et des meilleures sessions ;
et toujours autant d’énergie prise dans les rencontres.

Merci aux organisateurs, aux speakers, aux bénévoles, aux sponsors, et à toutes les personnes avec qui j’ai pu échanger pendant ces trois jours.

Petit clin d’oeil aux orgas :

la prod est down

le dog est down

mais je m’en fous parce que je devoxx!

Vivement la prochaine édition.

DevoxxFR 2026 - Récap du jeudi (jour 2)

Thu, 23 Apr 2026 18:00:00 +0200

Les résumés des 3 jours de DevoxxFR 2026

Deuxième jour de DevoxxFR 2026

Pour ce jeudi, j’ai raté les keynotes du matin (arrivé un peu tard), j’ai donc commencé par un tour des stands avant d’enchaîner avec les talks de la matinée. J’en ai profité pour récupérer des goodies pour les enfants au passage (:P).

Gérer vos tickets support avec de l’IA mais sans cramer la planète

Matthieu Vincent (Sopra Steria) et Philippe Charrière (Docker) ont présenté un talk sur un cas d’usage IA utile (gestion d’un service “support”), sans exploser les coûts infra.

Le message central : pas besoin d’un gros modèle partout. Selon le besoin, SLM/TLM (S ou T pour small ou tiny) peuvent suffire, à condition de bien cadrer mémoire, contexte et architecture.

Les points principaux :

Dimensionner le modèle sérieusement (poids, KV cache, activations), pas juste prendre “le plus gros”. Ca ne rentrera pas “sur le mac”.
Construire un RAG propre sur l’historique des tickets, avec embeddings et chunking seulement si nécessaire.
Ajouter une couche agentique légère pour orchestrer les actions/outils externes.

J’ai bien aimé que la démo utilise un JSON comme base vectorielle, ça rend très lisible et compréhensible le concept de vecteur et de calcul de distance. J’ai aussi bien aimé la très brève démo de “Docker Agents”, ce qui m’a décidé à enchaîner sur un talk à ce sujet l’après-midi.

Talk efficace, orienté pratique, avec une idée simple mais importante : pour ce type de besoin, “petit modèle bien outillé” bat souvent “gros modèle par défaut”.

L’Agentic Coding, nouveau territoire du Platform Engineering

Yankı Sesyılmaz et Julien Tanay (Doctolib) ont présenté un REX très concret sur l’adoption de l’agentic coding à l’échelle.

Le chiffre marquant : une vraie “task force” de 2 personnes dédiée à l’accompagnement de 600 profils tech, avec un passage assumé en mode agentic-first.

Ce que j’ai retenu :

Le sujet n’est pas juste “quel outil choisir”, c’est un vrai sujet de platform engineering.
Passer en agentic-first impose de revoir les workflows, de soigner le context engineering, de mettre en place une marketplace pour standardiser sans enfermer.
Leur approche tourne autour du Spec-driven Development (specs Markdown versionnées, lisibles humains + machines). Ils ont choisi OpenSpec pour garder un framework léger et adaptable.
Les plus gros utilisateurs de l’agentic sont les profils déjà habitués au context switching (et notamment les DevOps/SRE qui sont très transverses). On réduit la friction avec worktrees, dashboards d’agents et réduction des blocages humains.

Ils ont aussi partagé leur pipeline d’industrialisation outillage : veille, filtre valeur, revue sécurité, test avec AI champions, puis standardisation.

Enfin, les use cases “remote agents” étaient plutôt concrets : backlog de tickets, incidents de prod, migrations techniques, revue de code, avec orchestrateur, observabilité et guardrails pour cadrer le tout.

Talk intéressant, qui pointe les questions à se poser plus qu’il ne répond à comment les résoudre (:p).

Email at scale : comment on a survécu à 800M mails/an (et au DNS)

Julien Goullon et Julien Eyraud (Mirakl)

REX très solide sur un sujet qu’on sous-estime souvent : à ce volume, l’email devient un sujet de plateforme, pas un simple “service annexe”.

Ce que j’ai retenu :

Le contexte est massif : 300+ marketplaces, 170k vendeurs, 500 domaines d’envoi à migrer.
Leur nouvelle archi (Kafka + outbox + traitements asynchrones) a apporté du scale, mais a aussi exposé des effets de bord violents en incident (rebalancing, doublons, consumers bloqués).
Ils ont dû ajouter des garde-fous très concrets : circuit breaker, topics rapides/lents, déduplication Redis, observabilité/reporting.
La migration DNS/fournisseur est un chantier à part entière (SPF, DKIM, propagation, warm-up IP, suppression lists), avec beaucoup d’erreurs côté clients.

Le point le plus intéressant : ils ont investi dans l’outillage et l’autonomie client pour devenir proactifs, au lieu de rester en réaction permanente aux incidents.

Docker Agent - comment simplifier encore plus la création d’agents IA ?

Djordje Lukic et David Gageot (Docker)

Pas pu rentrer, même avec un peu plus de 10 minutes d’avance (maintenant un classique pour la salle Maillot). On m’en a dit du bien, je le mettrai dans la liste des replays.

Le mythe de la neutralité : quand la tech devient politique

Hugo Lassiège (eventuallycoding)

Talk dense et assez courageux sur un sujet qu’on évite encore dans les conférences tech, par peur de se faire étiqueter souverainiste peut être ? (alors que pas du tout).

Ce que j’ai retenu :

Le discours “la technologie est un outil neutre, tout dépend de l’usage” est commode, surtout pour les big techs. Mais un système peut définir ou suggérer son propre usage — une arme reste une arme.
Le numérique n’est pas “virtuel” : il structure concrètement l’accès au monde (transports, paiements, information), et ses biais ont des effets réels (ex. reconnaissance faciale moins performante sur les personnes non blanches au Royaume-Uni).
Les GAFAM sont en avance, mais aussi massivement subventionnés par des fonds publics — ce n’est pas uniquement le fruit du marché libre.
La souveraineté ne signifie pas l’autarcie. Être maître de ses choix sans subir de pressions extérieures, c’est possible dans un cadre d’interdépendance.

La citation qui m’a le plus parlé :

J’espère qu’on est en train de vivre notre effet Sputnik, qu’on appellera peut-être l’effet Trump.

Les exemples concrets sur ce qui se passe quand on se fâche avec les États-Unis (la CPI coupée de ses outils bureautiques, le juge coupé de toute interaction avec le monde) ou sur des déclarations comme “la technologie permettra d’éliminer le vote” (Peter Thiel) remettent bien les enjeux en perspective.

Talk que j’ai bien aimé.

Mise : un multi-outil pour votre poste de Dev & Ops

Rémi Verchère (Gravitek) parle d’un sujet que j’ai découvert avec la sortie des nodes de type Linux chez Clever Cloud il y a quelques mois (cf mon article sur le sujet). Le talk adresse un problème très concret : quand on jongle entre plusieurs projets, versions d’outils, variables d’environnement et scripts maison, ça devient vite le bazar.

Ce que j’ai retenu :

mise.toml permet de figer les versions d’outils par projet et de les installer simplement.
Le système de tasks (avec dépendances) permet de structurer les workflows build -> test -> deploy.
Bon support de l’environnement de dev (variables, venv Python, etc.).
Côté sécurité, il y a des briques utiles (checksum, cosign, lockfiles).

Un outil que je vais clairement creuser, surtout pour réduire la friction sur les context switches Dev/Ops.

Soirée meet-and-greet (version courte)

J’ai brièvement croisé quelques personnes pendant le meet-and-greet, mais j’ai rapidement dû filer au meetup Staff 42 qui commençait juste après. Pas eu le temps de passer à The Voxx, mais ça avait l’air bien, comme d’habitude.

Meetup Staff 42

Quelques sujets abordés pendant la soirée :

Comment naviguer dans l’ambiguïté — et trouver les bons problèmes à résoudre.
Le rôle Staff n’est pas fixe : on navigue entre différents archétypes (dans la définition qu’en donne le livre sur le staff engineering) selon les semaines et les contextes.
Super pouvoir identifié : savoir communiquer / avoir la liberté d’amener de l’innovation.
Il est difficile de devenir Staff sans avoir fait plusieurs entreprises et découvert plusieurs cultures.

Bonne soirée, discussions enrichissantes. On a fini par un dîner ensemble.