Cilium on Zwindler's Reflection

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

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 ?

Flannel et NetworkPolicies : comment ajouter le support avec Cilium en CNI chaining

Sun, 15 Mar 2026 18:00:00 +0200

Flannel, flannel, flannel…

Flannel est un CNI simple et populaire 😢.

C’est le CNI par défaut de k3s, celui que la moitié des tutos kubeadm utilisent, et on le retrouve aussi dans pas mal d’offres managées.

OK, il est simple, il route les paquets entre les pods, il supporte VXLAN et WireGuard, il se configure en 2 minutes. Que demander de plus ?

Ben justement. Il y a un truc que flannel ne fait pas : les NetworkPolicies. (Et c’est très grave).

Flannel is focused on networking. For network policy, other projects such as Calico can be used.

[Edit] Contrairement à ce que j’écris ici, flannel supporte en fait les NetworkPolicies depuis au moins 2 ans, via l’implémentation de référence kube-network-policies du projet Kubernetes. L’option n’est pas mise en avant dans le README et ce n’est probablement pas plus recommandé en production, mais elle existe. Voir la documentation officielle.

Et le piège, c’est que si vous n’avez pas lu cette petite ligne dans le README.md, rien ne vous le dit explicitement.

Vous pouvez parfaitement créer des objets NetworkPolicy dans votre cluster, kubectl apply ne bronchera pas, kubectl get netpol vous les listera gentiment. Sauf que… elles ne sont pas enforced. Le trafic passe quand même. Votre deny-all ne deny rien du tout.

On vérifie pour être bien sûr

Avant de résoudre quoi que ce soit, vérifions que le problème existe. En partant du prérequis qu’on a un cluster Kubernetes qui a flannel comme CNI et que tout est fonctionnel, on va déployer deux pods dans deux namespaces différents : un client (curl) et un serveur (nginx).

On vérifie que le client peut joindre le serveur :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

On obtient la page d’accueil nginx. Jusque-là, tout est normal. Maintenant, on applique une NetworkPolicy deny-all sur le namespace du serveur :

# 01-deny-all-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: deny-all-ingress
 namespace: netpol-test-b
spec:
 podSelector: {}
 policyTypes:
 - Ingress

kubectl apply -f 01-deny-all-ingress.yaml

Et on re-teste :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : la page nginx s’affiche toujours. La NetworkPolicy est bien créée (kubectl get netpol -n netpol-test-b la montre), mais elle n’est pas enforced. Le trafic passe comme si de rien n’était.

C’est le comportement attendu avec flannel (par défaut). Flannel ne fait que du routage L3 (overlay VXLAN ou WireGuard). Il n’implémente pas de contrôleur NetworkPolicy. Les objets existent dans etcd, mais personne ne les traduit en règles de filtrage.

On nettoie la policy avant de passer à la suite :

kubectl delete -f 01-deny-all-ingress.yaml

Les alternatives pour ajouter le support

Pendant longtemps j’ai pensé que c’était une fatalité. Je pense toujours que n’est pas un bon choix pour n’importe quelle production.

MAIS récemment, j’ai découvert qu’il était possible de chaîner les CNI au sein d’un même cluster, et ainsi d’avoir un CNI qui gère la majorité des tâches (ici Flannel) et un autre qui se charge d’autres tâches, comme par exemple enforcer des Netpols.

C’est d’ailleurs le principe de Canal, que je connaissais de nom mais que je n’avais jamais exploré. En fait, c’est ni plus ni moins qu’un manifeste qui déploie Flannel comme CNI principal avec Calico pour l’enforcing des NetOK fine, it’s truepols !

Canal was the name of Tigera and CoreOS’s project to integrate Calico and flannel.

Note : le projet GitHub a été archivé en octobre 2025 mais en théorie ça devrait encore fonctionner, si on trouve la doc correcte (pas trouvé, les liens sont KO, mais j’ai pas vraiment cherché non plus).

Vous avez donc compris le principe, on va ajouter un composant qui va watch les objets NetworkPolicy et les traduire en règles de filtrage effectives (iptables, eBPF, nftables…), sans toucher au flannel existant. C’est ce qu’on appelle le “CNI chaining” ou le mode “policy-only”.

Il existe plusieurs solutions :

Calico (Canal), Historiquement, la combinaison flannel + Calico s’appelle “Canal”, dont je viens de parler. Mais le manifeste Canal officiel embarque son propre flannel dans le même DaemonSet que calico-node. Si votre flannel est déjà installé et géré (par vous, par un opérateur, par un provider…), vous ne voulez probablement pas le remplacer. Et l’opérateur Tigera (la méthode Helm “officielle”) ne supporte pas non plus le déploiement en mode policy-only sur un flannel existant. Bref, c’est faisable mais ça nécessite un peu d’effort. Flemme.

kube-router, kube-router peut fonctionner en mode firewall-only (--run-firewall=true) et n’a besoin que d’iptables/ipset. C’est d’ailleurs ce que k3s utilise par défaut pour les NetworkPolicies. C’est la solution la plus légère (a priori ~50 Mo de RAM par node). Vérifiez que votre kernel dispose du module ip_set, sinon ça ne fonctionnera pas.

Cilium en mode CNI chaining, C’est la solution que j’ai retenue et qu’on va détailler. Cilium s’attache aux interfaces veth créées par flannel et ajoute ses programmes eBPF pour le policy enforcement. Pas de dépendance à iptables ou ipset, et en bonus on récupère Hubble pour l’observabilité réseau.

Installer Cilium en mode CNI chaining

Prérequis

Un cluster Kubernetes fonctionnel avec flannel
helm v3+
Un kernel >= 4.19 (idéalement >= 5.10 pour toutes les features eBPF)

Récupérer la configuration CNI de flannel

Cilium en mode chaining doit connaître la configuration CNI existante. On va la récupérer depuis un node :

kubectl debug node/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') \
 -it --image=busybox -- cat /host/etc/cni/net.d/10-flannel.conflist

Sur mon cluster, ça donne :

{
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 }
 ]
}

Notez le champ name (ici cbr0). On en aura besoin.

Créer le ConfigMap de chaining

On va créer un ConfigMap qui reprend la config flannel et y ajoute le plugin cilium-cni en chaining :

apiVersion: v1
kind: ConfigMap
metadata:
 name: cni-configuration
 namespace: kube-system
data:
 cni-config: |-
 {
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 },
 {
 "type": "cilium-cni",
 "chaining-mode": "generic-veth"
 }
 ]
 }

Attention : le champ name doit correspondre à celui de votre conflist flannel. Si le vôtre s’appelle cni0 ou autre chose, adaptez.

Avant d’appliquer, vérifiez aussi que votre CNI utilise bien des interfaces veth (c’est le cas par défaut avec flannel, mais mieux vaut s’en assurer). Depuis un node :

ip -d link | grep veth

Vous devriez voir des interfaces de type veth correspondant à vos pods, par exemple :

103: lxcb3901b7f9c02@if102: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
veth addrgenmode eui64 numtxqueues 1 numrxqueues 1

Si c’est bien le cas, le mode generic-veth de Cilium fonctionnera. On applique :

kubectl apply -f cilium-cni-configmap.yaml

Installer Cilium via Helm

helm repo add cilium https://helm.cilium.io/
helm repo update

Voici les values pour le mode chaining :

# cilium-values.yaml
cni:
 chainingMode: generic-veth
 customConf: true
 configMap: cni-configuration
 install: true

routingMode: native
enableIPv4Masquerade: false
enableIPv6Masquerade: false

hubble:
 enabled: true
 relay:
 enabled: true
 ui:
 enabled: true

Les points importants :

cni.chainingMode: generic-veth, c’est le mode chaining, Cilium s’attache aux interfaces veth existantes
cni.customConf: true + cni.configMap, on fournit notre propre config CNI
routingMode: native, flannel gère le routage, pas Cilium
enableIPv4Masquerade: false, flannel gère le masquerading
hubble.enabled: true, l’observabilité réseau, c’est le gros bonus de Cilium

helm install cilium cilium/cilium --version 1.19.1 \
 --namespace kube-system \
 -f cilium-values.yaml

On attend que tout soit prêt :

kubectl rollout status daemonset/cilium -n kube-system --timeout=120s

Vérification

kubectl exec -n kube-system ds/cilium -- cilium status

Ce qui nous intéresse :

Kubernetes: Ok 1.35 (v1.35.0) [linux/amd64]
CNI Chaining: generic-veth
Cilium: Ok 1.19.1
Hubble: Ok

La ligne CNI Chaining: generic-veth confirme que Cilium fonctionne en mode chaining et ne remplace pas flannel.

Important : les pods qui existaient avant l’installation de Cilium ne sont pas automatiquement gérés par Cilium. Il faut les redémarrer pour que Cilium attache ses programmes eBPF. Pensez à faire un kubectl rollout restart de vos workloads de test (ou à les recréer).

Tester les NetworkPolicies

C’est le moment de vérité. On re-applique notre deny-all :

kubectl apply -f 01-deny-all-ingress.yaml

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : timeout ! Cette fois, la NetworkPolicy est bien enforced. Le trafic est bloqué.

J’ai enchaîné avec les autres scénarios classiques de NetworkPolicy, et tout fonctionne :

Allow ingress sélectif par namespace, en ajoutant une policy qui autorise le trafic depuis netpol-test-a uniquement, le curl passe depuis ce namespace mais reste bloqué depuis default. L’isolation par namespace fonctionne.
Deny-all egress, en bloquant tout le trafic sortant du client, même la résolution DNS est bloquée (timeout immédiat).
Allow egress sélectif, en autorisant uniquement le DNS (port 53) et le serveur (port 80 dans le namespace netpol-test-b), le curl vers le serveur passe mais curl http://example.com reste bloqué.

Bref, ingress, egress, sélectif par namespace, tout marche comme attendu.

Bonus : Hubble, l’observabilité réseau

C’est pour moi le vrai atout de Cilium par rapport aux alternatives. Hubble permet de voir en temps réel les flux réseau et les verdicts de policy :

kubectl exec -n kube-system ds/cilium -- \
 hubble observe --namespace netpol-test-b --last 5

Mar 15 13:20:42.287: netpol-test-a/client:40066 (ID:9745) ->
netpol-test-b/server:80 (ID:22271)
policy-verdict:none ALLOWED (TCP Flags: SYN)

On voit le pod source, le pod destination, le port, l’identité Cilium, et le verdict de policy. Quand vous debuggez une NetworkPolicy qui ne se comporte pas comme prévu, c’est vraiment pratique.

Combien ça coûte en ressources ?

Sur mon cluster (3 nodes), voici ce que Cilium consomme juste après installation :

Composant	Par node	RAM
cilium agent	oui (DaemonSet)	~160 Mo
cilium-envoy	oui (DaemonSet)	~22 Mo
cilium-operator	non (2 replicas)	~42 Mo
hubble-relay	non (1 replica)	~16 Mo
hubble-ui	non (1 replica)	~21 Mo

Soit environ 180 Mo par node pour l’agent + envoy. J’ai pas de point de comparaison par rapport à Calico ou kube-router, mais ça me semble acceptable, et le fait de pouvoir avoir une vision complète sur la totalité des flux avec Hubble justifie largement le surcoût (à mon avis).

Conclusion

Si jamais vous n’avez pas le choix et que vous devez composer avec flannel, et que vous voulez boucher le trou béant de sécurité que représente l’absence d’enforcement des Netpols, sachez donc qu’il est maintenant possible :

d’activer l’ajout de l’implémentation officielle (même si je ne l’ai pas testée, ça doit marcher)
de chaîner un autre CNI pour le faire

À défaut de l’avoir en CNI pour tout (tout bon cluster Kubernetes a Cilium comme CNI), Cilium en mode CNI chaining (generic-veth) est une solution plutôt sympa pour combler ce manque. Il ne touche pas au flannel existant, il s’y greffe. Et en bonus, vous récupérez Hubble pour l’observabilité réseau, ce qui est franchement appréciable.

Have fun :)

Un nouveau champ `log` pour les network policies Cilium : une idée de use case

Mon, 03 Nov 2025 12:00:00 +0200

TL;DR

Cilium 1.18 a ajouté un champ log aux CiliumNetworkPolicies pour taguer les verdicts de flux (FORWARDED, DROPPED, AUDIT, …) avec des labels personnalisés. Dans l’idée, c’est la fonctionnalité parfaite pour éviter de logger le trafic bloqué que l’on connait dans nos dashboards de monitoring !

Mais il y a un hic, sans rapport avec cette fonctionnalité, qui rend cette idée inutilisable : on ne peut pas l’utiliser avec egressDeny + toFQDNs.

ET, il y a un bug, qui fait que le “log” n’est visible que sur le trafic “autorisé”.

Je vous raconte…

Le problème : monitor all the things (mais pas trop)

Comme toute bonne équipe “ops” qui se respecte, nous monitorons/loggons les flux réseau de notre cluster Kubernetes avec Hubble pour une analyse ultérieure et de l’alerting. Nous (en particulier mon collègue Nicolas Nativel) poussons tous les flux AUDIT et DROPPED vers un dashboard Grafana pour pouvoir rapidement repérer quand quelque chose est bloqué et décider :

C’est légitime ? → On ouvre le flux
C’est suspect ? → On déclenche l’alarme 🚨

Ça fonctionne plutôt bien… jusqu’à ce qu’on commence à bloquer explicitement des choses qu’on sait devoir être bloquées.

Dans notre cas, nous voulions empêcher une application tierce d’envoyer les données de “télémétrie” (ouais, appelons ça comme ça 😏). On parle d’appels HTTPS vers des domaines de tracking externes.

Le problème ? Si on bloque simplement ces flux, ils apparaîtront comme DROPPED dans Hubble, déclencheront notre monitoring, et on se retrouvera avec des alertes pour quelque chose qu’on a intentionnellement bloqué.

C’est du bruit dont on ne veut pas.

Et donc, ce champ log des network policies de Cilium 1.18 ?

Bonne nouvelle ! Cilium 1.18 a introduit exactement ce dont nous avions besoin : la possibilité d’ajouter des champs de log personnalisés aux verdicts sur les network policies.

Cf. l’annonce dans le blogpost officiel.

L’idée est simple : vous ajoutez un champ log.value à votre CiliumNetworkPolicy :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: my-policy
spec:
 endpointSelector:
 matchLabels:
 app: my-app
 egress:
 - toFQDNs:
 - matchName: "example.com"
 log:
 value: "my-custom-log-tag"

Ensuite, quand vous observez les flux dans Hubble, vous pouvez les filtrer en utilisant CEL (Common Expression Language) :

hubble observe \
 --verdict AUDIT \
 --not \
 --cel-expression "(_flow.policy_log.endsWith('my-custom-log-tag'))" \
 --print-raw-filters

Output :

allowlist:
- '{"verdict":["AUDIT"]}'
denylist:
- '{"experimental":{"cel_expression":["(_flow.policy_log.endsWith(''my-custom-log-tag''))"]}}'

Parfait ! Vous savez maintenant taguer les calls que vous avez explicitement bloqués et les exclure de votre monitoring. 🎉

Le plan : bloquer la télémétrie élégamment

À l’aide de cette nouvelle fonctionnalité, nous avons élaboré notre stratégie :

Utiliser egressDeny pour bloquer explicitement les domaines de télémétrie
Ajouter un champ de log personnalisé : app-explicit-traffic-blocked
Configurer Hubble pour filtrer les verdicts de flux avec ce tag
Profit ! 🎉

Voici ce que nous avons essayé :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: app-external-block-policy
 namespace: my-namespace
spec:
 endpointSelector:
 matchLabels:
 app.kubernetes.io/name: my-app
 # note: egressDeny prend la précédence sur les règles egress
 # https://docs.cilium.io/en/stable/security/policy/language/#deny-policies
 egressDeny:
 # Bloquer tout le trafic externe et le logger avec un champ de log arbitraire
 # Ceci est utilisé pour empêcher l'app d'envoyer des données de télémétrie à l'extérieur
 # sans déclencher d'alerte AUDIT/DROPPED
 # fonctionnalité ajoutée dans cilium 1.18.0 https://github.com/cilium/cilium/pull/39902
 - toFQDNs:
 - matchPattern: "*.telemetry.example.com"
 toPorts:
 - ports:
 - port: "443"
 protocol: TCP
 - port: "80"
 protocol: TCP
 log:
 value: "app-explicit-traffic-blocked"

Ça devrait fonctionner, non ? On utilise egressDeny (qui prend la précédence sur les autres règles, ce qui est une bonne chose !), et on le tague avec notre log personnalisé.

Retour à la réalité

Et puis… patatra.

En lisant la documentation Cilium sur les deny policies, nous sommes tombés sur cette petite note de rien du tout :

Deny policies do not support:

policy enforcement at L7, i.e., specifically denying an URL

toFQDNs, i.e., specifically denying traffic to a specific domain name.

Attendez, quoi ?

On ne peut pas utiliser toFQDNs avec egressDeny. Tout notre plan vient de s’effondrer 😱.

Pourquoi c’est un problème, déjà ?

Le problème, c’est le modèle de précédence dans Cilium :

Les règles egressDeny prennent la précédence sur les règles egress (by design, et c’est bien !)
Mais si on utilise egressDeny, on ne peut pas utiliser toFQDNs pour cibler intelligemment le domaine incriminé, on doit bloquer par IP ou CIDR
Ces services de télémétrie utilisent probablement des IPs dynamiques pour leurs endpoints (bonne chance pour maintenir une liste…)
Et si on bloque tout le trafic 80/443 dans egressDeny, on ne peut pas faire d’exceptions pour le trafic légitime dans les règles egress car… deny prend la précédence sur allow !

On est coincé entre le marteau et l’enclume :

Utiliser egress avec toFQDNs → ça marche, mais on ne peut pas bloquer, seulement autoriser
Utiliser egressDeny avec des IPs → on va jouer au chat et à la souris avec des plages IP qui changent
Utiliser egressDeny pour bloquer tout le 80/443 → on bloque tout, y compris le trafic légitime

Solutions de contournement potentielles

En attendant que Cilium supporte toFQDNs dans les policies egressDeny, voici quelques approches alternatives que vous pourriez envisager :

Trouver un moyen de désactiver la télémétrie directement dans l’app

C’est la meilleure option, mais malheureusement pas toujours sur la table.

Blocage basé sur le DNS

Configurer le serveur DNS pour retourner NXDOMAIN pour les domaines de télémétrie, comme un serveur pi-hole personnel le ferait avec les pubs. L’application échouera à résoudre le domaine et n’enverra pas de données.

Utiliser egressDeny basé sur les IPs (avec un overhead de maintenance)

Résoudre les FQDNs de télémétrie vers leurs plages IP actuelles et les bloquer avec egressDeny :

egressDeny:
 - toCIDRSet:
 - cidr: 203.0.113.0/24  # Exemple de plage IP de télémétrie
 toPorts:
 - ports:
 - port: "443"

Si la liste n’évolue pas trop souvent, c’est une bonne option.

OK, mais imaginons qu’il n’y ait pas de trafic légitime. Peut-on utiliser la fonctionnalité pour ajouter un log sur le trafic droppé ?

Malheureusement non, pas pour le moment.

Il y a un bug dans cette nouvelle fonctionnalité de Cilium qui ne log le champ policy_log que sur les flux “autorisés”, pas sur les flux audit/dropped.

Policy log does not work for DROPPED/AUDIT flow ouverte par mon collègue Nicolas :

When defining a CiliumNetworkPolicy with the spec.log field configured, I expect the relevant hubble flows to have the policy_log field. It works for allowed flow.

But for denied/audited flow resulting from the rule (implicit or explicit), policy_log is never available.

Note: I observe the same issue with --print-policy-names option of hubble, the k8s:io.cilium.k8s.policy.derived-from label is not set for denied flows (but correctly set for allowed flows).

et une autre issue [Hubble CLI] –print-policy-names flag does not do anything ouverte par quelqu’un d’autre.

Puisque 2 tickets sont ouverts et que les mainteneurs ont commencé à répondre dessus, on peut espérer que ce soit corrigé un jour.

Conclusion

Dans notre cas d’usage, nous n’avons finalement pas utilisé cette nouvelle fonctionnalité de Cilium. Mais donner la possibilité d’ajouter des détails (et permettre de filtrer dessus également) est toujours une feature sympa.

Un grand merci à mon collègue Nicolas Nativel, qui a fait la majorité du travail autour des CiliumNetworkPolicies, incluant les dashboards, le travail exploratoire sur cette fonctionnalité, et a pris le temps de créer l’issue sur le repo Cilium.

Références

J'ai testé pour vous : k8e (Kubernetes Easy Engine)

Fri, 19 Sep 2025 16:00:00 +0000

Tu ne faisais pas un livre sur Kubernetes, toi ?

Oui ! Et j’ai une bonne nouvelle : mon livre “Kubernetes : 50 solutions pour les postes de développement et les clusters de production”, édité par Eyrolles, sortira le 16 octobre 2025 ! Vous pouvez suivre l’état d’avancement du projet sur 50ndk.zwindler.fr. Je ferai une annonce propre quand j’aurai la couverture définitive à vous montrer :3.

En attendant la sortie, je “libère” un autre chapitre qui avait été abandonné lors de la sélection finale du livre : celui sur k8e (Kubernetes Easy Engine). Si vous suivez le blog attentivement, vous vous souviendrez peut-être que j’avais fait pareil pour k8s-tew (K8S : the easier way), qui n’avait aussi pas eu la chance de figurer dans la liste des 50 méthodes qui ont leur place dans mon livre :-P.

Mais revenons à k8e !

k8e est un wrapper pour k3s qui permet d’installer facilement un cluster multi-nodes avec Cilium configuré comme CNI et en mode kube-proxy replacement. Dans la philosophie, c’est vraiment pas beaucoup plus que k3s avec un gros preflight check. On est même pas sur le niveau fonctionnel d’un k3sup ou d’un k0ctl…

Les développeurs mettent en avant plusieurs fonctionnalités clés :

✅ Key Features

Supports airgap images package for k8s components

10-year valid certificate, supports cluster backup and upgrade

No dependency on Ansible, HAProxy, or Keepalived; a binary tool with zero dependencies

Natively supports Cilium network

No kube-proxy component

Le projet se présente donc comme une alternative simplifiée pour déployer k3s avec Cilium directement intégré, ce qui évite les étapes manuelles de configuration post-installation. J’ai d’ailleurs écrit un article fin 2023 sur ces fameuses opérations manuelles, toujours disponible ici : k3s et cilium rapide et facile

Prérequis

Comme k8e s’appuie sur k3s, les prérequis sont globalement les mêmes que pour k3s. Cependant, il y a une exigence supplémentaire importante : Cilium utilisant eBPF pour ses fonctionnalités de bas niveau, il faut un noyau Linux relativement récent

Bon, ça c’était ce qu’on disait pour les premières versions de cilium. Maintenant Linux kernel >= 4.19.57 c’est un vieux vieux kernel !

Pour mes tests, j’ai utilisé 4 machines virtuelles dans le même LAN :

k8e1 (control plane, 192.168.1.11)
k8e2 (control plane, 192.168.1.12)
k8e3 (control plane, 192.168.1.13)
k8e4 (worker, 192.168.1.14)

L’installation nécessite un accès SSH avec des privilèges sudo/root sur tous les nœuds.

Installation du premier nœud

Le Getting started est un peu rude car on tombe sur une page en chinois simplifié par défaut…

L’installation de k8e se fait via un script bash, comme beaucoup d’outils de la CNCF (RIP la sécurité). Pour le premier nœud (qui sera notre premier node control plane), on utilise la commande suivante :

denis@k8e1:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | API_SERVER_IP=192.168.1.11 K8E_TOKEN=superSecureToken INSTALL_K8E_EXEC="server --cluster-init" sh -

Le script réalise plusieurs vérifications préalables (“preflight checks”) pour s’assurer que l’environnement est compatible. C’est notamment là qu’il vérifie la version du noyau Linux pour la compatibilité eBPF.

[2025-09-19 12:28:45] [WARN] System memory is less than 4GB. This may affect performance.
Finding latest version from GitHub
v1.31.2+k8e1
Downloading package https://github.com/xiaods/k8e/releases/download/v1.31.2+k8e1/k8e as /home/denis/k8e
...

À la fin du processus, on obtient un message de confirmation :

[...]
[2025-09-19 12:35:33] [INFO] systemd: Starting k8e
[2025-09-19 12:35:41] [INFO] Installing cilium network cni/operator
ℹ️ Using Cilium version 1.15.6
🔮 Auto-detected cluster name: default
🔮 Auto-detected kube-proxy has not been installed
ℹ️ Cilium will fully replace all functionalities of kube-proxy
[2025-09-19 12:35:42] [INFO] Installation completed successfully
[2025-09-19 12:35:42] [INFO] Performing cleanup...

Point qui a été amélioré depuis la dernière fois que j’avais testé, k8e copie lui-même le kubeconfig, il n’y a plus besoin d’aller le récupérer dans /etc/k8e/k8e.yaml (idem k3s, il est traditionnellement dans /etc/rancher/k3s/k3s.yaml)

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 62m v1.31.2+k8e1

Cependant, un rapide coup d’œil permet de voir “comment” k8e le fait :

denis@k8e1:~$ env
...
KUBECONFIG=/etc/k8e/k8e.yaml

denis@k8e1:~$ ls -l /etc/k8e/k8e.yaml
-rw-r--r-- 1 root root 2961 Sep 19 12:35 /etc/k8e/k8e.yaml

Et là, je suis désolé, mais c’est :

Le kubeconfig cluster-admin à poil en 644, c’est NON. La doc de k8e est même encore pire, elle conseille du 666 (toujours plus).

Ajout des nœuds supplémentaires

Une fois le premier nœud installé, on peut ajouter les autres membres du control plane. Pour les nœuds supplémentaires du control plane :

denis@k8e2:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

denis@k8e3:~$ curl -sfL https://getk8e.com/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

Et pour le worker node :

denis@k8e4:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 sh -

On peut ensuite vérifier que tous les nœuds sont bien présents :

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 72m v1.31.2+k8e1
k8e2 Ready control-plane,etcd,master 2m30s v1.31.2+k8e1
k8e3 Ready control-plane,etcd,master 2m18s v1.31.2+k8e1
k8e4 Ready <none> 75s v1.31.2+k8e1

Vérification de Cilium

Une des particularités de k8e est donc l’intégration native de Cilium. On peut vérifier que Cilium fonctionne correctement en utilisant sa CLI directement sur un des nœuds du control plane (installée par défaut) :

denis@k8e1:~$ cilium status
 /¯¯\
 /¯¯\__/¯¯\  Cilium: OK
 \__/¯¯\__/ Operator: OK
 /¯¯\__/¯¯\  Envoy DaemonSet: disabled (using embedded mode)
 \__/¯¯\__/ Hubble Relay: disabled
 \__/ ClusterMesh: disabled

DaemonSet cilium Desired: 4, Ready: 4/4, Available: 4/4
Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Containers: cilium Running: 4
 cilium-operator Running: 1
Cluster Pods: 3/3 managed by Cilium
Helm chart version: 1.15.6
Image versions cilium quay.io/cilium/cilium:v1.15.6: 4
 cilium-operator quay.io/cilium/operator-generic:v1.15.6: 1

Avantages et Inconvénients

Les plus	Les moins
➕ Installation automatisée de Cilium sur k3s	➖ Permissions `/etc/k8e/k8e.yaml` en “world readable” dans la doc officielle (dangereux !)
	➖ Version de Kubernetes en retard par rapport aux dernières versions
	➖ N’apporte pas énormément de valeur ajoutée par rapport à k3s seul
	➖ Documentation limitée par rapport aux projets plus matures

Conclusion

Dans les points positifs, le projet, sans être populaire, est quand même plutôt suivi avec pas mal de contributions externes et une “vie” (commits réguliers). k8e est un outil pour les fainéants qui veulent installer un cluster k3s avec Cilium plus rapidement (oui c’est un point positif).

Mais, à quel prix ?

Un kubeconfig à 644, lisible par tous les utilisateurs unix des control planes
Une installation en curl | bash (exactement comme k3s, à ceci près que j’ai plus confiance en Rancher labs qu’en xiaods)
Des versions datées (kube 1.31, cilium 1.15)

Pas la peine que je vous dise ce que j’en pense, je pense que vous avez compris.

Migration du routage de cilium de iptables vers eBPF... à chaud !

Fri, 20 Oct 2023 06:00:00 +0200

Contexte

Il se pourrait que j’aie configuré des clusters Kubernetes de prod avec cilium en mode iptables et non pas eBPF. Mais vous n’avez aucune preuve…

Cependant, dans l’hypothèse hautement improbable où j’aurais pu faire une boulette pareille, voilà comment je m’y serai pris pour résoudre le problème.

#trollface

Imaginons donc qu’en vérifiant la configuration de Cilium, voici ce que vous avez trouvé :

kubectl -n cilium exec -it cilium-aaaaa -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]

Damned!

A y regarder de plus près, les containers cilium-agent dans vos pods cilium prennent beaucoup de CPU et de RAM et commencent à engorger vos workers…

C’est la cata.

Pourquoi ça ?

Les premières implémentations du réseau imaginaire de Kubernetes (les fameux CNI plugins) utilisaient iptables. Or, on sait depuis très longtemps, notamment dans le cas d’usage de Kubernetes, qu’iptables est assez mauvais pour gérer de grandes quantités de règles.

Dans le cas particulier de Kubernetes, le nombre de règles à tendance à augmenter de manière exponentielle avec la taille du cluster et le CPU consommé pour router des paquets réseaux avec…

À un moment donné, parcourir la liste des règles prend tout le CPU d’un nœud donné et le rend non réactif.

Allo patron ? On est mal.

C’est une des raisons pour lesquelles j’aime beaucoup cilium comme CNI plugin, les développeurs font partie des premiers à avoir misé sur eBPF comme remplacement d’iptables (même s’il existe d’autres implémentations / d’autres technos qui règles ce problème).

Comment en est on arrivé là ?

A vrai dire, j’ai juste lu la doc et fait confiance…

We introduced eBPF-based host-routing in Cilium 1.9 to fully bypass iptables and the upper host stack, and to achieve a faster network namespace switch compared to regular veth device operation. This option is automatically enabled if your kernel supports it. To validate whether your installation is running with eBPF host-routing, run cilium status in any of the Cilium pods and look for the line reporting the status for “Host Routing” which should state “BPF”.

Grosso modo, selon la doc officielle, si on dispose du kernel correct et des modules qui vont bien, l’installation de cilium est censée activer automatiquement le mode eBPF… Sauf qu’on voit bien un peu plus haut que ce n’est pas le cas, malgré un kernel récent (6.2).

En creusant un peu plus les logs, voilà ce qu’on peut trouver :

kubectl -n cilium logs cilium-7b5cp
[...]
level=info msg="BPF host routing requires enable-bpf-masquerade. Falling back to legacy host routing (enable-host-legacy-routing=true)." subsys=daemon

Bon… visiblement, il manque une option dans la chart Helm.

[...]
 kubeProxyReplacement: strict
+ bpf:
+ masquerade: true
[...]

Problem solved, fin de l’article ?

Problème

Alors oui, forcément, on peut modifier la chart comme un⋅e bourrin⋅e et fin de l’histoire.

Mais admettons qu’on ait pas envie de couper le trafic de production… Comment on fait ?

La solution la plus clean qui me vient en tête est la suivante :

on drain un node
on lui change sa configuration
on l’uncordon pour lui remettre un peu de trafic dessus
on vérifie que la nouvelle configuration fonctionne ET
on vérifie que les nodes peuvent se parler entre eux entre ceux en iptables et ceux en eBPF

Bah oui, ça serait dommage d’avoir la moitié du cluster qui peut pas communiquer avec l’autre moitié…

Vérifier la connectivité

Ce qui est cool avec cilium (je vous ai déjà dit que j’aime cilium ?), c’est qu’on a déjà du tooling pour tout tester.

La CLI cilium dispose d’une sous commande cilium connectivity test qui lance des dizaines de tests internes/externes pour tester que tout est OK.

➜ ~ cilium -n cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [node] Deploying echo-same-node service...
✨ [node] Deploying DNS test server configmap...
✨ [node] Deploying same-node deployment...
✨ [node] Deploying client deployment...
[...]
✅ All 32 tests (265 actions) successful, 2 tests skipped, 0 scenarios skipped.

Il existe aussi une commande cilium-health, embarquée dans le container cilium-agent, qui permet de remonter des statistiques périodiques de latences entre tous les nodes du cluster. Utile !

kubectl -n cilium exec -it cilium-ccccc -c cilium-agent -- cilium-health status
Probe time: 2023-09-12T14:47:03Z
Nodes:
 node-02 (localhost):
 Host connectivity to 172.31.0.152:
 ICMP to stack: OK, RTT=860.424µs
 HTTP to agent: OK, RTT=110.142µs
 Endpoint connectivity to 10.0.2.56:
 ICMP to stack: OK, RTT=783.861µs
 HTTP to agent: OK, RTT=256.419µs
 node-01:
 Host connectivity to 172.31.0.151:
 ICMP to stack: OK, RTT=813.324µs
 HTTP to agent: OK, RTT=553.445µs
 Endpoint connectivity to 10.0.1.53:
 ICMP to stack: OK, RTT=865.976µs
 HTTP to agent: OK, RTT=3.440655ms
[...]

Et enfin, on peut juste regarder la commande cilium status qui nous dit qui est “reachable” (là encore, dans le container cilium-agent)

➜ kubectl -n cilium exec -ti cilium-ddddd -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]
Cluster health: 5/5 reachable (2023-09-14T12:01:51Z)

Changer la configuration d’un node

On a de la chance, car, depuis la version 1.13 de cilium (la dernière en date est la 1.14), il est possible d’appliquer des configurations différentes pour un sous ensemble de nodes (documentation officielle du Per-node configuration).

Note : avant ça, c’était quand même possible, de manière temporaire, en éditant la ConfigMap de cilium à la main, puis en redémarrant les pods concernés pour prise en compte.

Il existe maintenant une CRD pour le faire, qui s’appelle CiliumNodeConfig. Les seules choses qu’on a à faire, c’est ajouter un label sur un node (io.cilium.enable-ebpf: “true”) et ajouter le manifest suivant sur notre cluster :

cat > cilium-fix.yaml << EOF
apiVersion: cilium.io/v2alpha1
kind: CiliumNodeConfig
metadata:
 namespace: cilium
 name: cilium-switch-from-iptables-ebpf
spec:
 nodeSelector:
 matchLabels:
 io.cilium.enable-ebpf: "true"
 defaults:
 enable-bpf-masquerade: "true"
EOF

kubectl apply -f cilium-fix.yaml

kubectl label node node-05 --overwrite 'io.cilium.enable-ebpf=true'

Si jamais on est en production, le plus propre est donc de kubectl drain le Node préalablement.

Par curiosité, j’ai quand même essayé de le faire “à chaud”, pour le fun.

J’ai déployé un daemonset contenant une app en V(lang) qui répond simplement le nom du container dans une page web :

cat > vhelloworld-daemonset.yaml << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: vhelloworld-daemonset
spec:
 selector:
 matchLabels:
 app: vhelloworld
 template:
 metadata:
 labels:
 app: vhelloworld
 spec:
 containers:
 - name: vhelloworld
 image: zwindler/vhelloworld:latest
 ports:
 - containerPort: 8081
 imagePullPolicy: Always
EOF

kubectl apply -f vhelloworld-daemonset.yaml

kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vhelloworld-daemonset-q4h44 1/1 Running 0 3m31s 10.0.4.87 nodekube-05 <none> <none>
vhelloworld-daemonset-w97pv 1/1 Running 0 3m31s 10.0.3.85 nodekube-04 <none> <none>

Puis j’ai créé des containers contenant un shell et curl pour vérifier périodiquement et depuis plusieurs nodes que les containers sont bien accessibles :

kubectl run -it --image curlimages/curl:latest curler -- /bin/sh
If you don't see a command prompt, try pressing enter.
~ $ curl http://10.0.4.87:8081
hello from vhelloworld-daemonset-g2zdw
~ $ curl http://10.0.3.85:8081
hello from vhelloworld-daemonset-65k2n

~ $ while true; do
 date
 curl http://10.0.4.87:8081
 curl http://10.0.3.85:8081
 echo
 sleep 1
done

Une fois le label appliqué sur un node, son pod cilium tué (via un kubectl delete), les pods sont restés accessibles

Fri Sep 15 14:05:34 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:35 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:36 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

A un moment donné, cilium a redémarré, remarqué la présence de pods existants, et pris le relais avec eBPF !

evel=info msg="Rewrote endpoint BPF program" containerID=8b7be1b032 datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=1018 identity=4773 ipv4=10.0.3.85 ipv6= k8sPodName=default/vhelloworld-daemonset-w97pv subsys=endpoint
level=info msg="Restored endpoint" endpointID=1018 ipAddr="[10.0.3.85 ]" subsys=endpoint

Ca fonctionne, mais est ce que c’est mieux en termes de consommation de ressources ?

Ca, c’était la bonne nouvelle. Je m’attendais à des gains car le cluster était vraiment pas loin de souffrir.

Les containers cilium prenaient 10% des CPU de mes nodes, et plusieurs Go de RAM en mode iptables. Ca aurait rapidement pu monter bien plus haut, si j’avais agrandi le cluster au-delà des 50 nodes / 2000 pods.

Le passage au mode eBPF a permis de retrouver des niveaux totalement indolores (1% de CPU par node, 1-2% de RAM) par rapport aux configurations de mes machines.

Pas mal, hein ?

Bonus

Un tutoriel bien velu pour migrer totalement de CNI à chaud (de flannel à cilium)

k3s et cilium rapide et facile

Fri, 01 Sep 2023 10:00:00 +0200

Contexte

K3s est une distribution de Kubernetes éditée par Rancher (et certifiée par la CNCF) que je trouve super pratique car légère et supportant plusieurs plateformes (en particulier ARM):

x86_64
armhf
arm64/aarch64
s390x

Je l’ai déjà utilisée par le passé (ici) pour faire un cluster kubernetes avec des vieux Raspberry Pi. A l’époque, on pouvait même faire tourner les nodes “workers” sur des RPi 1 (je ne sais pas si c’est toujours possible).

La particularité de k3s est que tout est intégré dans un seul binaire. Nécessairement, des choix techniques ont été fais pour rendre l’installation et l’utilisation la plus légère possible. Parmi ces choix techniques, il y a l’utilisation de flannel comme “CNI plugin” (pour faire simple, le réseau virtuel qui permet aux containers de parler en eux).

Je ne suis vraiment PAS fan de flannel qui m’a posé beaucoup de soucis en production, qui ne supporte pas les “Network Policies”, qui a pendant plusieurs années utilisé comme backend etcd2 alors que ce logiciel était marqué comme obsolète (deprecated) depuis plusieurs années, …

A l’inverse, je suis très fan de cilium, qui a beaucoup de fonctionnalités sympa grâce à l’usage de eBPF en termes de performance et de sécurité et a pas mal de traction dans l’écosystème.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez installé un serveur avec Ubuntu 22.04.

Cilium est très friand d’eBPF, dont il tire la plupart de ces fonctionnalités. Et comme eBPF est quelque chose d’assez récent dans le kernel Linux, le mieux est de mettre à jour notre serveur et de lui mettre un kernel plus récent :

$ sudo apt update -y
$ sudo apt upgrade -y
$ sudo apt install curl linux-image-generic-hwe-22.04 -y

Une fois que c’est fait, on reboot le serveur pour la prise en compte du nouveau kernel.

Installation de k3s

On installe donc k3s, en remplaçant flannel par cilium (voir documentation Installation - Network options). La doc conseille de retirer le support des network-policy. Je me demande comment c’est géré puisque flannel n’est pas censé les supporter :thinking_face:.

$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable "traefik"' sh -s - --disable-network-policy

On vérifie que k3s est démarré et fonctionne :

$ systemctl status k3s
● k3s.service - Lightweight Kubernetes
 Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
 Active: active (running) since Fri 2023-09-01 12:32:55 UTC; 1min 13s ago
 Docs: https://k3s.io
 Process: 1724 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
 Process: 1726 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
 Process: 1727 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
[...]

Par défaut, le “kubeconfig” d’administration est déposé dans le fichier /etc/rancher/k3s/k3s.yaml, dont le propriétaire est root. Il existe un flag --write-kubeconfig-mode dans k3s pour modifier les droits de ce fichier mais cela le rendrait “world readable”.

Pour éviter de faire ça, on récupère le kube/config pour notre utilisateur “ubuntu”.

Comme le binaire k3s embarque tout, dont kubectl, on va aussi devoir lui dire de ne pas utiliser ce fichier en forçant la variable d’environnement $KUBECONFIG.

$ mkdir ~/.kube
$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
$ sudo chown ubuntu:ubuntu ~/.kube/config
$ chmod 600 ~/.kube/config
$ export KUBECONFIG=~/.kube/config

$ echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc
$ echo 'source <(kubectl completion bash)' >> ~/.bashrc
$ echo 'alias k=kubectl' >> ~/.bashrc
$ source ~/.bashrc

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kube01 NotReady control-plane,master 70s v1.27.4+k3s1

Ici, kube01 est marqué NOTREADY. C’est normal car on a pas de CNI plugin (donc pas de réseau interne).

Ajout d’un second node

Sur le premier node, récupérez le token pour que le second puisse rejoindre le cluster :

cat /var/lib/rancher/k3s/server/node-token

Une fois que c’est fait, connectez vous sur le node à rajouter au cluster, installez le kernel hwe, rebootez

sudo apt update
sudo apt upgrade
sudo apt install curl linux-image-generic-hwe-22.04 -y
sudo reboot

Une fois que le node est à jour et prêt à rejoindre le cluster, lancez la commande suivante :

IP_MASTER=IP.DE.VOTRE.MASTER
K3STOKEN=le:token:du:master
curl -sfL https://get.k3s.io | K3S_URL=https://${IP_MASTER}:6443 K3S_TOKEN=${K3STOKEN} sh -

Au bout de quelques secondes, votre node va apparaître dans la liste des nodes.

CNI plugin + ingressController

Nos nodes sont toujours en “Not Ready”. On installe helm et on ajoute le CNI plugin :

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
$ CILIUM_VERSION="1.14.2"
$ helm repo add cilium https://helm.cilium.io/
$ helm upgrade --install cilium cilium/cilium --version=${CILIUM_VERSION} \
 --set global.tag="v${CILIUM_VERSION}" --set global.containerRuntime.integration="containerd" \
 --set global.containerRuntime.socketPath="/var/run/k3s/containerd/containerd.sock" \
 --set global.kubeProxyReplacement="strict" \
 --set global.bpf.masquerade="true" \
 --set ingressController.enabled=true \
 --set ingressController.default=true \
 --namespace cilium \
 --create-namespace

Note: pour le fun, j’ai aussi ajouté le support de l’ingressController de cilium. Comme ça c’est fait :D.

Au bout de quelques secondes, notre cluster devrait devenir opérationnel. On a aussi metric server (pour les stats de base).

$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system cilium-operator-86dbc96dd6-hlgtt 1/1 Running 0 56s
kube-system cilium-operator-86dbc96dd6-h7sq6 1/1 Running 0 56s
kube-system cilium-pxrrz 1/1 Running 0 56s
kube-system cilium-psjr4 1/1 Running 0 56s
kube-system svclb-cilium-ingress-c27a13c6-x7tld 2/2 Running 0 32s
kube-system local-path-provisioner-957fdf8bc-5w9n9 1/1 Running 0 6m9s
kube-system coredns-77ccd57875-zlvpc 1/1 Running 0 6m9s
kube-system svclb-cilium-ingress-c27a13c6-8dbf6 2/2 Running 0 34s
kube-system metrics-server-648b5df564-xr29p 1/1 Running 0 6m9s

Conclusion

Voilà pour ce très court article sur k3s et cilium.

Ce setup, rapide à installer sur une install fraîche est ma base pour beaucoup d’expérimentations avec Kubernetes.