Sortie de Mercure 0.23.5 : un Helm chart blindé pour vos clusters Kubernetes
Publié le 07 mai 2026
Mercure v0.23.5 vient de sortir, et le sujet central de cette release est le Helm chart. Si vous faites tourner des hubs sur Kubernetes, cette version durcit les configurations par défaut et intègre des templates de politiques (policies) qui nécessitaient auparavant de patcher le chart ou de les gérer à l'extérieur.
Le contexte derrière cette version : nous avons audité un cluster Kubernetes de production. Le constat était sans appel : conteneurs en root, absence de NetworkPolicy, durcissement PodSecurity manquant... La question était de savoir où appliquer les correctifs. La réponse s'est imposée d'elle-même : directement dans le Helm chart open source. En effet, tout utilisateur de Mercure sur un cluster multi-tenant ou haute disponibilité rencontre tôt ou tard ces mêmes contraintes ! La version originale, en anglais, de cet article se trouve sur mon blog. Le détail de cette release se trouve aussi sur GitHub.
Templates NetworkPolicy et CiliumNetworkPolicy (opt-in)
Le chart embarque désormais deux nouveaux templates, désactivés par défaut :
- Une NetworkPolicy standard pour les clusters dont le CNI l'applique (Calico, Cilium, etc.).
- Une CiliumNetworkPolicy pour exploiter les fonctionnalités spécifiques à Cilium, comme l'egress filtré par FQDN et les règles L7.
Il vous suffit d'activer celle supportée par votre CNI et de passer vos listes de règles :
ciliumNetworkPolicy:
enabled: true
ingress:
- fromEntities:
- ingress
toPorts:
- ports:
- port: "8080"
protocol: TCP
egress:
- toEntities:
- kube-dns
toPorts:
- ports:
- port: "53"
protocol: ANY
rules:
dns:
- matchPattern: "*"
- toFQDNs:
- matchName: redis.example.com
toPorts:
- ports:
- port: "6379"
protocol: TCPLorsque l'ingress et l'egress sont renseignés, Cilium traite tout ce qui est hors liste comme refusé (default-deny). Cela vous permet de bénéficier d'un default-deny par tenant sans avoir à rédiger vos propres politiques. L'endpointSelector du chart est limité au composant app.kubernetes.io/component: server ; ainsi, le pod de test Helm (qui hérite des labels du sélecteur mais pas de celui du composant) reste hors du périmètre, garantissant le bon fonctionnement de helm test.
readOnlyRootFilesystem "out of the box"
Jusqu'à présent, activer securityContext.readOnlyRootFilesystem: true faisait crasher le Pod au premier accès en écriture car Caddy sauvegarde automatiquement sa config sous XDG_CONFIG_HOME=/config. Désormais, le chart monte inconditionnellement /config et /tmp en tant qu'emptyDir, et /data en tant que PVC dans lequel Mercure peut écrire si persistence.enabled: true est activé.
La bibliothèque Go a également été améliorée : bolt.NewBoltTransport crée maintenant le répertoire parent avant d'ouvrir la base de données, évitant ainsi le crash du hub sur un /data vide.
Voici un extrait de values.yaml pour un fonctionnement rootless avec la v0.23.5 :
podSecurityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
seccompProfile:
type: RuntimeDefault
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: [ALL]
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
service:
targetPort: 8080 # Optionnel sur les runtimes modernesLes runtimes récents (containerd 1.5+, Docker 20.10+) règlent net.ipv4.ip_unprivileged_port_start=0 à l'intérieur du conteneur, permettant à un processus non-privilégié de binder n'importe quel port. Le targetPort: 8080 reste utile comme fallback pour les anciens systèmes.
Alignement sur le standard PodSecurity "Restricted"
Le chart propose maintenant des réglages par défaut alignés sur le standard de sécurité Restricted de Kubernetes, sans casser la compatibilité pour les utilisateurs existants :
serviceAccount.automount: false(Mercure n'appelle pas l'API Kubernetes).enableServiceLinks: falsesur le Pod du hub (évite les fuites de variables d'environnement des services voisins).podSecurityContext.seccompProfile.type: RuntimeDefault.- Le Pod de test Helm a également été blindé : image
busybox:1.37figée, profil seccomp activé, suppression de toutes les capacités (capabilities) et système de fichiers en lecture seule.
Le securityContext au niveau du conteneur (suppression de toutes les capacités, système de fichiers en lecture seule, exécution sans privilèges, etc.) reste activable à la demande (opt-in) via la clé securityContext. En effet, basculer ces options par défaut constituerait une rupture de compatibilité (breaking change) majeure pour les utilisateurs d'images personnalisées. Ce changement est donc reporté à une future version du chart.
Cache du sélecteur de topics limité à 100k entrées
La taille par défaut du cache des sélecteurs de topics était de 2 560 000 entrées. Avec environ 100 octets par entrée, un hub très sollicité pouvait voir son cache grimper à ~256 Mo. Sur un petit Pod, cela frôlait la GOMEMLIMIT, forçant le runtime Go dans une boucle de Garbage Collection permanente consommant 90% du CPU.Le nouveau défaut est fixé à 100 000 entrées (~10 Mo). Vous pouvez ajuster cette valeur via la directive topic_selector_cache dans le Caddyfile.
Mercure Cloud et Mercure Enterprise
Si vous utilisez Mercure Cloud, tous ces réglages de sécurité sont déjà appliqués : nous gérons le cluster pour vous. Vous bénéficiez également des transports de production (Redis, Kafka, Postgres), de l'isolation multi-tenant managée et d'un SLA garanti.
Pour bénéficier du même niveau de durcissement on-premise, des transports haute disponibilité et d'un support prioritaire, tournez-vous vers Mercure Enterprise. De notre côté, nous sommes disponibles pour vous accompagner dans vos problématiques de performance et sécurité !
