Sécurité on Zwindler's Reflection

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 :)

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Sat, 21 Feb 2026 10:00:00 +0200

Après l’optimisation des performances du blog (AVIF, pré-compression), j’étais super content de moi. 🥳

Mais c’était sans compter sur Antoine Caron, qui est venu (à très juste titre) me chatouiller sur un autre aspect que j’avais ignoré, le rapport Mozilla Observatory…

J’ai donc lancé un scan Mozilla HTTP Observatory sur mon blog et le résultat était : F.

Cool, je peux pas faire pire.

Le déclic

En relisant l’article de Julien sur codeka.io, qui a aussi parlé avec Antoine, a aussi un blog statique avec Hugo, MAIS qui lui avait fait le taf, j’ai réalisé que c’était à la fois important et peut-être pas si compliqué à corriger.

Julien y détaille les headers de sécurité à ajouter sur un site Hugo, avec des exemples pour Caddy. Moi je suis sur nginx, mais le principe est le même.

Note : si ça vous intéresse, les liens des épisodes précédents sur l’infra du blog sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel
Optimisation webperf : AVIF et pré-compression - Le round précédent (focus sur les images)

Ce que teste HTTP Observatory

HTTP Observatory vérifie une série de headers HTTP que votre serveur devrait envoyer pour protéger vos visiteurs. Les principaux :

Strict-Transport-Security (HSTS) : force le navigateur à toujours utiliser HTTPS
Content-Security-Policy (CSP) : contrôle quelles ressources le navigateur peut charger (scripts, styles, images, iframes…)
X-Content-Type-Options : empêche le navigateur de “deviner” le type MIME des fichiers
Referrer-Policy : contrôle les informations de provenance envoyées aux sites tiers
X-Frame-Options / frame-ancestors : empêche l’inclusion de votre site dans une iframe (clickjacking)

Sur un blog statique, on pourrait se dire que ce n’est pas critique. Pas de base de données, pas de sessions utilisateur, pas de formulaires sensibles. Mais ces headers protègent quand même contre des attaques réelles :

Un script injecté (XSS) pourrait rediriger vos lecteurs vers un site malveillant
Sans HSTS, un attaquant sur un Wi-Fi public pourrait intercepter la connexion initiale en HTTP
Sans frame-ancestors, quelqu’un pourrait inclure le blog dans une iframe piégée

Bref, même pour un blog statique, ça peut valoir le coup de faire l’effort, a minima pour s’habituer aux bonnes pratiques.

Étape 1 : les headers “faciles”

Le piège nginx : add_header et l’héritage

La première chose, c’est que je suis tombé dans un piège classique avec mon nginx. Je l’ignorais, mais les directives add_header dans un bloc location écrasent (et ne complètent pas) celles du bloc server parent.

Ça veut dire que si vous avez un add_header Cache-Control dans une location (c’était mon cas), tous vos headers de sécurité définis au niveau server disparaissent pour cette location. J’ai pété un plomb pendant quelques minutes à reload / restart en boucle sans comprendre.

La solution : créer un fichier snippet et l’inclure partout.

cat > /etc/nginx/snippets/security-headers.conf << 'EOF'
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "..." always;
EOF

Puis dans la config nginx :

server {
 # Headers de sécurité au niveau server
 include /etc/nginx/snippets/security-headers.conf;

 # Cache des assets statiques
 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg|webp|avif)$ {
 expires 1y;
 add_header Cache-Control "public, immutable";
 # OBLIGATOIRE : ré-inclure les headers ici !
 include /etc/nginx/snippets/security-headers.conf;
 }

 location ~* \.html$ {
 expires 1h;
 add_header Cache-Control "public, must-revalidate";
 include /etc/nginx/snippets/security-headers.conf;
 }
}

HSTS, X-Content-Type-Options, Referrer-Policy

Ces trois-là sont les plus simples à ajouter et “ne cassent rien” :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

HSTS avec max-age=63072000 (2 ans) et preload permet à terme (pas encore fait) de s’inscrire sur la HSTS preload list. Le navigateur refusera même la toute première connexion HTTP initiale.
nosniff empêche les navigateurs d’interpréter un fichier texte comme du JavaScript.
strict-origin-when-cross-origin envoie l’URL complète en referrer pour les requêtes same-origin, mais seulement l’origine (domaine) pour les requêtes cross-origin.

Étape 2 : Content-Security-Policy (la vraie difficulté)

La CSP est un header puissant et a priori complexe. C’est lui qui rapporte le plus de points sur Observatory, mais c’est aussi lui qui peut tout casser si on va trop vite.

Le principe : vous déclarez au navigateur exactement quelles ressources votre site a le droit de charger (scripts, styles, images, iframes, fonts…) et depuis quelles origines. Tout le reste est bloqué. C’est la meilleure défense contre le XSS, parce que même si un attaquant arrive à injecter un <script> dans votre HTML, le navigateur refusera de l’exécuter s’il n’est pas dans la liste autorisée.

Le revers de la médaille : si vous oubliez une ressource légitime dans votre CSP, elle sera bloquée et votre site casse silencieusement : un script qui ne charge plus, une font qui disparaît, une iframe vide. Il faut donc faire un inventaire exhaustif avant de verrouiller.

Je me suis fait épauler par un LLM (Opus 4.6) pour les modifs à réaliser et on a fait plusieurs passes jusqu’à ce que tout fonctionne.

Inventaire des ressources externes

Avant d’écrire la CSP, il faut faire l’inventaire de tout ce que le site charge. Voilà une petite synthèse de mon pote Claudio :

Type	Ressource	Origine
Script	GoatCounter analytics	`https://gc.zgo.at/count.js`
Script	Umami analytics	`https://cloud.umami.is/script.js`
Connect	GoatCounter API	`https://blogzwindler.goatcounter.com`
Connect	Umami API	`https://api-gateway.umami.dev`
Script	De mon thème ‘stack’ - vibrant.js (couleurs d’images)	`https://cdn.jsdelivr.net`
Script	De mon thème ‘stack’ - PhotoSwipe (lightbox images)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - PhotoSwipe CSS (lightbox)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - CSS du thème	local (`'self'`)
Font	Luciole	locale
Frame	Widget Deezer (inclu dans un seul article 😖)	`https://widget.deezer.com`
Image	data: URIs (SVGs inline)	`data:`
Form	Mailchimp (abonnement newsletter)	`https://zwindler.us15.list-manage.com`

Le problème des scripts d’analytics externes

Avec une CSP comme script-src 'self' https://gc.zgo.at https://cloud.umami.is, je devais soit :

Faire confiance à ces CDN -> si le CDN est compromis, le script malveillant s’exécute sur mon blog. Nope.
Ajouter des hashes SRI (Subresource Integrity). Problème : ces scripts peuvent changer côté serveur sans prévenir, ce qui casserait le hash.

J’ai choisi une troisième voie : télécharger les scripts à chaque build et les servir localement.

# Dans mon petit script blog_refresh.sh, avant le hugo --minify
mkdir -p static/js
curl -sf --max-time 10 https://gc.zgo.at/count.js -o static/js/count.js \
 || echo "WARN: failed to download GoatCounter script"
curl -sf --max-time 10 https://cloud.umami.is/script.js -o static/js/umami.js \
 || echo "WARN: failed to download Umami script"

Et dans le template Hugo :

<script data-goatcounter="https://blogzwindler.goatcounter.com/count"
 async src="/js/count.js"></script>
<script defer src="/js/umami.js"
 data-website-id="3d8f0ea9-..."></script>

Est-ce que c’est “tricher” ?

Une fois que j’avais fait la modif, je me suis demandé : est-ce qu’héberger les scripts localement à chaque build ne contourne pas l’esprit des vérifications d’Observatory ? Sur ce point précis j’ai un petit doute, n’étant pas expert sur ces points là. J’ai demandé à un LLM qui m’a dit que non, mais je veux bien un avis tiers.

Dans tous les cas, ça semble être l’approche recommandée par la documentation GoatCounter pour les sites avec une CSP stricte.

Supprimer `unsafe-inline` de `script-src`

Observatory pénalise fortement 'unsafe-inline' dans script-src. Et c’est normal, car c’est la porte ouverte au XSS : n’importe quel script injecté dans le HTML s’exécute.

Le problème : mon thème Hugo (hugo-theme-stack) générait 4 scripts inline :

Color scheme init — lit le localStorage pour appliquer le thème clair/sombre avant le premier rendu
Color scheme detection — détecte la préférence système (prefers-color-scheme: dark)
Language switcher — le sélecteur de langue <select onchange="window.location.href=this.selectedOptions[0].value"> dans la sidebar, qui est un attribut d’événement inline (script-src-attr)
Font loader — charge la CSS de la font Luciole dynamiquement

Luciole: A typeface for visual impairment

Pour chacun, j’ai extrait le code dans un fichier .js externe dans static/js/ et remplacé le script inline par une balise <script src="...">.

Par exemple, pour le color scheme, le thème avait dans layouts/partials/head/colorScheme.html :

<script>
 (function() {
 const colorSchemeKey = 'StackColorScheme';
 if(!localStorage.getItem(colorSchemeKey)){
 localStorage.setItem(colorSchemeKey, "auto");
 }
 })();
 /* ... */
</script>

Que j’ai remplacé par un override de template Hugo :

{{- /* Override: external JS file instead of inline (CSP compliance) */ -}}
<script src="/js/color-scheme.js"></script>

Avec le contenu correspondant dans static/js/color-scheme.js. Hugo permet de surcharger n’importe quel template du thème en plaçant un fichier au même chemin dans le dossier layouts/ du projet.

Pour le language switcher, même approche : j’ai surchargé layouts/partials/sidebar/left.html pour retirer l’attribut onchange du <select> et ajouté un id="language-select", puis créé un fichier static/js/language-switcher.js :

(function () {
 var select = document.getElementById('language-select');
 if (select) {
 select.addEventListener('change', function () {
 window.location.href = this.selectedOptions[0].value;
 });
 }
})();

Note importante : il m’a fallu plusieurs allers-retours avec la console du navigateur (F12 -> Console) avant de trouver la totalité des violations CSP. Chaque correction en révélait de nouvelles, il fallait bien regarder tous les différents types de pages sur le blog (pas juste la page d’accueil et les posts), et certaines erreurs affichées dans la console venaient en fait d’extensions navigateur (typiquement les gestionnaires de mots de passe comme Bitwarden, dont le bootstrap-autofill-overlay.js génère des violations style-src-elem) et non du site lui-même. Il faut donc bien distinguer les erreurs du site de celles injectées par les extensions.

Supprimer `unsafe-inline` de `style-src`, la suite

Même logique pour les styles. J’avais quatre sources d’inline CSS :

Un bloc <style> dans custom.html — les CSS custom properties pour ma font Luciole
Des attributs style="" sur les badges de catégories — background-color: #2a9d8f; color: #fff;
Un attribut style="enable-background:..." sur un SVG (export Adobe Illustrator)
Des attributs style="" dans le formulaire Mailchimp du footer — display:none et un positionnement off-screen pour le honeypot anti-spam

Le <style> bloc : déplacé dans assets/scss/custom.scss, le fichier de personnalisation SCSS prévu par le thème.

/* Font family CSS custom properties */
:root {
 --article-font-family: "Luciole";
 --base-font-family: "Luciole";
 /* ... */
}

Les badges de catégories : toutes mes catégories utilisent les mêmes couleurs (#2a9d8f / #fff), définies dans le front matter de chaque _index.md. Le thème les injectait en style="" via le template article/components/details.html. J’ai surchargé ce template pour retirer le style inline et ajouté une règle CSS dans custom.scss :

.article-category a {
 background-color: #2a9d8f;
 color: #fff;
}

Le SVG : j’avais un SVG que j’avais ajouté à la main (un petit Robot mignon pour mon “AI Manifesto”) avec enable-background, qui est un attribut SVG 1.1 déprécié. Je l’ai simplement supprimé du fichier SVG source, sans impact visuel.

Le formulaire Mailchimp : le code HTML Mailchimp utilise style="display:none" pour masquer les divs de feedback et style="position: absolute; left: -5000px;" pour le champ honeypot (pour les robots qui s’inscrivent à ma newsletter 🤔). J’ai remplacé tout ça par des classes CSS dans custom.scss :

#mce-error-response,
#mce-success-response {
 display: none;
}

.mce-honeypot {
 position: absolute;
 left: -5000px;
}

La CSP finale

Après tous ces changements, plus aucun script ni style inline sur le site. La CSP peut donc être stricte :

default-src 'none';
script-src 'self' https://cdn.jsdelivr.net;
style-src 'self' https://cdn.jsdelivr.net;
img-src 'self' data:;
connect-src 'self' https://blogzwindler.goatcounter.com https://api-gateway.umami.dev https://cdn.jsdelivr.net;
font-src 'self';
frame-src https://widget.deezer.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self' https://zwindler.us15.list-manage.com;
manifest-src 'self';
media-src 'self'

Points notables :

default-src 'none' : par défaut, rien n’est autorisé. Chaque type de ressource doit être explicitement listé. C’est la politique la plus restrictive.
Pas de unsafe-inline nulle part : ni dans script-src, ni dans style-src
frame-ancestors 'none' remplace X-Frame-Options: DENY (plus moderne)
cdn.jsdelivr.net dans script-src, style-src ET connect-src : le thème charge vibrant.js (JS avec SRI), les CSS de PhotoSwipe (lightbox d’images) et les source maps associées depuis ce CDN
form-action autorise Mailchimp pour le formulaire d’abonnement dans le footer

Au final, de nombreux morceaux du thème de mon blog ont du être réécrit / overridés. Je suis un peu gêné d’avoir du en arriver là, mais c’était le prix à payer pour une note maximale 😂.

Nettoyage bonus : Mailchimp

En faisant l’inventaire des ressources externes, j’ai découvert un vieux widget Mailchimp dans la sidebar qui chargeait du CSS et du JavaScript depuis chimpstatic.com. Je ne l’utilisais plus : supprimé. Le formulaire d’abonnement dans le footer des articles a été gardé, mais nettoyé de ses style="" inline (voir plus haut).

Résultat final

De F (0/100) à A+ (125/100). Tous les tests sont verts.

Un grand merci à Antoine pour sa patience avec les débutants naïfs comme moi 😂 et ses super talks !

Touraine Tech 2026 - Récap du jour 2

Fri, 13 Feb 2026 18:00:00 +0200

Jour 2 - C’est reparti !

Me voici dans le train du retour et je prend un peu de temps pour mettre en forme mes notes de la journée. C’est parti pour le récap du jour 2 de Touraine Tech 2026 !

Après une soirée speakers très sympa dans un bar à jeux, je me suis levé un poil trop tard et j’ai loupé la keynote… Dommage 😅.

Lorsqu’un simple bug réseau vous emmène dans les entrailles de Linux

Florian Forestier nous a raconté une histoire de debugging épique.

Le contexte : une équipe de 3 devs en mode “You build it, you run it”, avec une stack Golang/Svelte. Tout va bien, quand soudain arrive un manager qui dit “ça marche PAS”. La PKI est en panne, sur du hardware custom… provenant de matériel reconditionné tchèque (pour la modique somme de 200k€ tout de même).

Le matériel incriminé : des DL380 Gen 10 avec des cartes QLogic FastlinQ 45000. Il y en a 8, et aucune ne fonctionne.

L’enquête commence :

Les cartes sont visibles dans le BIOS ✓
lspci les détecte ✓
Mais ip link ne les voit pas ✗
dmesg affiche des erreurs sur les drivers qed/qede

Testé avec Ubuntu, CentOS, Alpine Linux -> KO partout. Impossible d’avoir des drivers pour des kernels récents compatibles avec Proxmox.

Après une semaine d’échecs collectifs, Florian a une “idée à la con” : installer une vieille Ubuntu 18.04. Moi ça me fait rire, parce que j’aurais commencé par là ! Quand on a du vieux matériel, on teste avec un OS contemporain du matériel.

Bingo ! Ça fonctionne.

À partir de là, investigation par dichotomie : Debian 12 avec le kernel 4.15 de Ubuntu -> OK. Bug présent en 4.17, absent en 4.16, puis rechercher le commit dans les modifications sur les pilotes qed/qede.

La solution : un code “non supporté” pas pris en compte dans une fonction ajoutée en 4.16. 3 lignes de fix.

Pour reverser le correctif dans le kernel Linux, il a fallu écrire sur la bonne mailing-list, avec ses 8 pages de règles. 3 semaines entre l’envoi du mail et le merge (habituellement 1-2 semaines).

Un beau REX de debugging bas niveau ! J’étais vraiment content de l’avoir vu :).

L’ampoule qui en savait trop : voyage au cœur de la sécurité des objets connectés

Paul Pinault nous a plongé dans le monde de la sécurité IoT.

Quelques chiffres pour poser le contexte : 300 millions d’ampoules connectées vendues chaque année, dont 60% en WiFi (vs Zigbee/ZWave). Et côté réglementation, ça bouge :

RED (août 2025) : garantie sécurité cyber EN18031, mises à jour possibles et sécurisées, communications chiffrées, données personnelles nettoyées, plus de mots de passe par défaut
Cyber Resilience Act (2026-2027) : SBOM obligatoire, MAJ pendant 10 ans minimum

Paul a donc disséqué (à la DREMMEL 🤣) une ampoule connectée équipée d’un ESP32-U4WD, avec ses 2 oscillateurs RTC/horloge et son eFuse, pour voir s’il pouvait la compromettre.

Les vecteurs d’attaque analysés :

Port série et JTAG : désactivés post-usine
Pairing WiFi : pas RED-compliant (HTTP car pas d’Internet au moment du pairing = pas de certificat, WiFi ouvert)
BLE Pin : pas possible sur une ampoule
BLE pairing : la voie privilégiée

Point rigolo : pour que les télécommandes soient CRA/RED compliant, l’ampoule doit aussi devenir une gateway BLE vers Internet (sinon, pas de mise à jour).

Au secours ! Mes images pourrissent mes perfs

Antoine Caron et Mathieu Mure nous ont parlé d’un sujet crucial pour les performances web : les images.

Un peu d’histoire… En 1992, la toute première image est affichée sur le web : les Cernettes (du CERN, évidemment).

Aujourd’hui, 99.9% des sites web ont au moins 1 image, et 68% des pages mobiles ont leur LCP (Largest Contentful Paint) lié à une image.

Le royaume des formats :

Morts/vieillissants : BMP, GIF, JPEG, PNG
Modernes : WebP, AVIF, SVG, JPEG XL

Après une chouette explication de comment ça fonctionne “en théorie”, Antoine et Mathieu nous on montré qu’à compression égale, les formats récents prennent moins de place, mais surtout, affichent des artefacts visuels bien moindres dans les hauts niveaux de compression (notamment AVIF).

Les bonnes pratiques présentées :

Taille adaptative avec srcset pour laisser le navigateur choisir la meilleure taille
Balises <picture> avec plusieurs <source> pour gérer différents formats
fetchpriority="high" au-dessus de la ligne de flottaison
loading="lazy" en dessous
Sharp en JS pour le traitement côté serveur
Git LFS pour éviter de commit des fichiers lourds
Cache de build pour éviter de reconstruire chaque image à chaque CI

Bref, j’ai du boulot sur ce blog (je le savais…).

Makers de Père en Fils

Matthias et Sylvain Gougouzian nous ont présenté un talk bonbon sur leurs projets makers en famille.

Un duo pétillant, pour ne pas dire explosif 😂 ! Matthias (le fils) est super cash (pour rester poli), c’était très rigolo à voir.

L’idée de Sylvain : initier ses enfants à l’électronique, comme nous à l’époque en cours de techno. Objectif : faire 1 à 2 projets par an ensemble.

Après découverte de Scratch (apprendre le code par blocs), Pyrates (approfondir avec Python), Micro:Bit (code visuel avec accéléromètres et boutons), TinkerCAD (conception 3D de projets physiques), Sylvain s’est dit que c’était le moment de passer à un vrai projet DE ZERO. Recréer un équivalent du Nabaztag !

Ils ont utilisé la méthode MoSCoW pour prioriser :

Must have : Météo (LEDs), Moteurs
Should have : Écran, GreenIT
Could have : Micro, HP, Carte SD
Won’t have : Bourse, Traffic

Choix techniques : ESP32/Raspberry Pico avec MicroPython.

Le moment touchant du talk : apprendre à se dire les choses. Matthias n’osait plus parler à son père quand une tâche était trop grosse, par peur de décevoir. C’est un point qu’en tant que parent, on peut trop facilement oublier…

Une fois les problèmes de communication réglé, ils ont pu découper en étapes : PoC d’abord (NeoLED, écran, servomoteur, bouton, carte microSD), puis passage au MVP avec la forme physique sur TinkerCAD.

Un bel exemple de transmission intergénérationnelle.

Another World, une belle leçon d’architecture logicielle

Olivier Poncet nous a fait découvrir les entrailles d’un jeu cultissime (bon, moi je le connaissais pas 🫣) : Another World.

Un talk que je voulais voir depuis longtemps, mais comme je savais que je le verrai à TNT26, j’avais décidé de ne pas regarder le replay !

Another World, c’est un jeu vidéo d’aventure/action cinématique sorti en 1991, fait par une seule personne (sauf la musique) : Eric Chahi, pionnier du jeu vidéo français des années 80-90.

Les specs impressionnantes :

Exécutable de 24 Ko
Assets de 1.2 Mo (images et sons)
Un moteur graphique polygonal 2D (pour les animations fluides et séquences cinématiques)
Un moteur sonore 4 pistes PCM
Une machine virtuelle pour tout gérer !

Le matériel de l’époque : Amiga 500 avec 1 Mo de RAM et un HDD de 20 Mo, augmenté d’un Genlock (caméscope/magnétoscope) et d’un magnétophone. Eric Chahi a créé ses propres outils en GFA Basic. Il a utilisé la rotoscopie : capturer une image vidéo, détourer les assets pour créer les animations. Toutes les peintures et graphismes sont faits à la main.

Les données sont compressées avec l’algo ByteKiller, répandu sur Amiga, économe en RAM.

La VM est impressionnante agit comme une vrai machine : 64 threads, 256 registres, 29 instructions / 200+ opcodes. Olivier est rentré dans les détails de l’implémentation des opcodes et de leur conception.

Le moteur vidéo utilise des framebuffers avec 4 pages (2 backgrounds + 2 fenêtres principales, 2 actives et 2 inactives). Les polygones sont hiérarchisés dans des “bounding boxes” pour gérer l’affichage et les collisions. Les backgrounds, trop complexes pour être calculés en temps réel, sont pré-dessinés et mis en “cache”.

Difficile de tout retranscrire, Olivier nous a montré 1001 autres annecdotes sur les optimisations et autres astuces malines dans ce jeu. Olivier n’avait plus de temps pour nous montrer sa réimplémentation du jeu en C++ (qui fonctionne dans un navigateur avec WASM, si je ne dis pas de bêtises).

Une vraie leçon d’ingénierie avec les contraintes de l’époque !

Communauté et remerciements

Comme toujours, le meilleur d’une conférence reste les rencontres.

Je retiens surtout les longues (très longues) discussions avec Horacio et Yannick de Clever Cloud. J’ai aussi enfin pris le temps de papoter avec Estelle, Geoffrey, Julien (x3, décidément 🙃), Valentin, Stéphane (x2), Aurélie, Florian, Jérôme, et sûrement plein d’autres que j’ai oubliés dans le “blur” de la conférence.

Un grand merci à l’équipe d’organisation de Touraine Tech pour cette édition 2026 réussie. Le passage sur 2 jours et le changement de lieu ont été de bonnes décisions. À l’année prochaine !

Retrouvez-moi dans le podcast Hack'n Speak (0x33)

Fri, 30 Jan 2026 08:00:00 +0100

Hack’n Speak

J’ai eu le plaisir d’être invité par Martial Puygrenier (aka mpgn) dans son podcast Hack’n Speak !

Pour la première fois dans ce podcast orienté sécurité, on plonge dans Kubernetes, évidemment sous l’angle de la sécurité.

J’y partage mon retour d’expérience après bientôt 10 ans dans le grand bain de Kubernetes : bonnes pratiques, pièges à éviter et vision terrain.

On termine l’épisode en parlant de ce blog, de mon titre de Kubestronaut et de mon livre.

0x33 – Du Kubernetes, de la sécurité, une anecdote

En attendant que la moulinette de MAJ des postcasts côté deezer rattrape le retard (coucou les anciens collègues 🫣), l’épisode est disponible sur Spotify :

Écouter l’épisode sur Spotify

[EDIT] Voilà la version DEEZER

-Écouter l’épisode sur DEEZER

Les liens mentionnés dans l’épisode

Et pour vous faciliter la tâche si vous les cherchez, voici les ressources dont je parle dans l’épisode :

Le post mortem de Datadog - une plongée fascinante dans un incident majeur
Ciel ! Mon Kubernetes mine des bitcoins ! - mon talk sur la sécurité Kubernetes
Mon livre : 50 solutions pour les postes de dev et les clusters de production

Merci Martial !

Un grand merci à Martial pour l’invitation et l’échange. C’était vraiment cool de pouvoir parler de Kubernetes sous l’angle sécu dans un podcast dédié au sujet.

Bonne écoute à toutes et à tous !

Vos politiques de conformité sur Kubernetes avec Kyverno - part 2

Mon, 05 Sep 2022 06:00:00 +0200

Récap’ de la partie 1

Dans le précédent article, j’ai introduit Kyverno, un outil “cloud native” pour gérer des politiques de conformité sur Kubernetes.

Pour illustrer les capacités de l’outil, j’avais pris un exemple : empêcher deux Ingress d’utiliser la même URL d’entrée. J’avais fait le même exercice avec OPA dans un article précédent (Open Policy Agent (OPA) et de son pendant dans Kubernetes, Gatekeeper) et j’avais comparé à la fin les deux syntaxes (Kyverno vs rego).

J’ai une nette préférence pour la syntaxe de Kyverno, même si OPA est là depuis plus longtemps et n’est pas limité à Kubernetes (Kyverno c’est uniquement pour Kube).

Aller un peu plus loin

Au-delà de mon exemple, j’ai indiqué que Kyverno mettait à disposition un très grand nombre de politiques déjà écrites pour vous (191 au moment où j’écris l’article).

kyverno.io/policies

Par défaut, la plupart des politiques disponibles sont positionnées en mode “audit” dans un premier temps. N’oubliez pas de la passer en mode “enforce” quand vous serez assez mature sur votre cluster.

Évidemment, quand on débute on ne sait pas trop par quoi commencer. Le plus simple dans ce cas-là est de déployer la chart Helm kyverno/kyverno-policies, qui contient l’équivalent des Kyverno des “Pod Security Standards” (les PSP étant officiellement obsolètes depuis la 1.21 je crois, et plus utilisables en 1.25).

helm install kyverno-policies kyverno/kyverno-policies -n kyverno
[...]
Thank you for installing kyverno-policies v2.5.2 😀

We have installed the "baseline" profile of Pod Security Standards and set them in audit mode.

Visit https://kyverno.io/policies/ to find more sample policies.

Voilà ce que ça nous a déployé (la dernière étant déjà là à cause de l’article précédent)

kubectl get clusterpolicy
NAME BACKGROUND ACTION READY
disallow-capabilities true audit true
disallow-host-namespaces true audit true
disallow-host-path true audit true
disallow-host-ports true audit true
disallow-host-process true audit true
disallow-privileged-containers true audit true
disallow-proc-mount true audit true
disallow-selinux true audit true
restrict-apparmor-profiles true audit true
restrict-seccomp true audit true
restrict-sysctls true audit true
unique-ingress-host false enforce true

Avec ça, on va déjà avoir pas mal de pain sur la planche pour éduquer nos utilisateurs (les développeurs) à produire des déploiements Kubernetes sécurisés.

User experience

Un des points ennuyeux de ces deux outils, c’est que de base, ils ne sont pas très user friendly. Moi, faire une commande kubectl get events (voire kubectl get events --field-selector=reason=PolicyViolation dans le cas de Kyverno) pour savoir pourquoi un déploiement a échoué, ça ne m’ennuie pas trop (ça m’amuse, presque).

Mais pour certaines personnes, c’est un peu rebutant et je peux l’entendre.

Mon but c’est de rendre l’infrastructure plus simple à des gens dont qui ce n’est pas le métier et imposer ma façon de travailler n’est pas forcément la meilleure méthode.

Souvent, pour aider à adopter un nouvel outil / usage, le plus simple c’est de lui fournir une interface graphique.

Et ça tombe bien, Kyverno dispose d’un outil pour faire ça.

Kyverno policy reporter

En réalité, l’outil ne sert pas tout à fait à ça, à la base. Mais vous allez voir que c’est même encore mieux.

Historiquement, l’outil s’appelle policy reporter, car les développeurs avaient besoin d’un outil permettant d’exporter facilement et rapidement les PolicyReports dont je parle dans l’article précédent :

kubectl describe policyreport polr-ns-default
Name: polr-ns-default
Namespace: default
Labels: managed-by=kyverno
Annotations: <none>
API Version: wgpolicyk8s.io/v1alpha2
Kind: PolicyReport
[...]
Results:
 Category: Sample
 Message: The Ingress host name must be unique.
 Policy: unique-ingress-host
 Resources:
 API Version: networking.k8s.io/v1
 Kind: Ingress
 Name: ingress2
[...]
Summary:
 Error: 0
 Fail: 2
 Pass: 0
 Skip: 2
 Warn: 0

Le policy reporter a donc pour rôle d’exporter les PolicyReports vers plusieurs sources externes pour les traiter plus facilement :

Grafana Loki
Elasticsearch
Slack
Discord
MS Teams
Policy Reporter UI
S3

Je vais vous en parler de 2 : slack et Policy Reporter UI

Policy Reporter UI

Je commence par l’UI, car c’est le plus simple à configurer. Il suffit juste de déployer la Chart helm de Policy Reporter en oubliant pas de spécifier qu’on veut l’UI :

helm repo add policy-reporter https://kyverno.github.io/policy-reporter
helm repo update
helm install -n kyverno policy-reporter policy-reporter/policy-reporter --set kyvernoPlugin.enabled=true --set ui.enabled=true --set ui.plugins.kyverno=true

kubectl -n kyverno get pods
NAME READY STATUS RESTARTS AGE
kyverno-5f8bfd6fc5-xp6bm 1/1 Running 1 (59m ago) 33d
policy-reporter-74cc9bf4b9-9ggwh 1/1 Running 0 18s
policy-reporter-kyverno-plugin-6b48c4bc5f-5rwfb 1/1 Running 0 18s
policy-reporter-ui-5c9449d58-f9fwf 1/1 Running 0 18s

On peut évidemment ajouter un Ingress mais si on est fénéant comme moi dans cette démo un simple port-forward suffit 🙃.

kubectl port-forward service/policy-reporter-ui 8082:8080 -n kyverno

L’UI en elle-même est assez intuitive. On a notamment :

un Dashboard avec un gros indicateur global pour savoir combien on a de violation de politiques
une page avec nos “policy reports”, dans lequel on peut filtrer par namespace ou par politique
la liste de nos politiques
…

Slack

On voit tout de suite l’intérêt d’alerter les administrateurs dans Slack (ou Teams 😭) si jamais une violation de la politique arrive.

On voit que la configuration est assez triviale, on a juste à ajouter un webhook dans Slack et un petit bout de configuration dans Kyverno

kyvernoPlugin:
 enabled: true
ui:
 enabled: true
 plugins:
 kyverno: true
target:
 slack:
 webhook: "https://hooks.slack.com/services/T0xxxxxxxx"
 minimumPriority: "medium"
 skipExistingOnStartup: true
 sources:
 - kyverno

Et on re-applique tout ça à notre release helm

helm upgrade -n kyverno policy-reporter policy-reporter/policy-reporter -f kyverno-values.yaml

Note: Si vous ne savez pas comment faire, il faut être admin du workspace Slack, créer une application dans https://api.slack.com/apps, activer les Incoming Webhooks et en créer un en lui donnant les droits sur un channel.

Et si on faisait une violation de politique, pour voir ?

Pour faire simple, je suis reparti de l’exemple de l’article précédent. Je repasse ma politique unique-ingress-host en mode audit et je recréé l’ingress problématique :

kubectl edit clusterpolicy unique-ingress-host
kubectl apply -f ingress2.yaml

Instantanément, j’ai bien 2 échecs qui apparaissent dans l’UI de Kyverno, ainsi que des messages dans Slack

Victoire :)

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec Kyverno

Mon, 01 Aug 2022 06:00:00 +0000

Introduction

Si le titre de cet article vous dit quelque chose, c’est peut-être parce que je l’ai déjà utilisé il y a 2 ans tout pile pour parler d’un autre logiciel de gestion de politiques de conformité : Open Policy Agent (OPA) et de son pendant dans Kubernetes, Gatekeeper.

Et je ne vais pas mentir, je n’ai pas beaucoup refait de l’OPA depuis cet article de 2020…

La première raison est que j’ai changé d’entreprise pile à ce moment-là et que j’avais d’autres priorités dans la nouvelle entreprise qui m’emploie.

La seconde, certainement plus vraie mais peut être aussi moins avouable, c’est qu’OPA c’est quand même pas super user friendly. Notamment à cause du rego, le langage des politiques de conformités.

Depuis, j’ai découvert Kyverno, un petit nouveau dans le “cloud native” game (promu au niveau de “sandbox CNCF” depuis peu) et qui propose des politiques de conformité pour Kubernetes uniquement (contrairement à OPA + rego qui sont généralistes), écrites en YAML.

With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies.

Prends toi ça, rego ;-)

Note : Cet article va rester relativement simple, c’est une introduction. On ira plus loin dans les articles suivants (coder sa propre politique, l’UI, etc).

Je ne vais pas beaucoup innover par rapport à l’article sur OPA et repartir du même cas d’usage : interdire à deux développeurs d’utiliser la même URL pour leur app web déployée dans Kubernetes (car on a vu que c’était assez nul quand ça arrive).

Et vous allez voir que la première marche d’apprentissage est BEAAAAUCOUP plus accessible avec Kyverno que OPA (même si ça va faire râler la moitié de mon Twitter que je parle encore de YAML 🤣).

Prérequis

Même topo que pour OPA / Gatekeeper, il faut la 1.14 de Kube pour utiliser Kyverno. La 1.14 était déjà pas la plus récente en 2020, c’est carrément la préhistoire maintenant ;-).

Your Kubernetes cluster version must be above v1.14 which adds webhook timeouts.

Bien évidemment, il faut également avoir les droits d’accès admin sur le cluster, car on va devoir créer des Validating Admission Webhooks et des CRDs. Là encore, je vous renvoie au précédent article et à la doc officielle si ça ne vous parle pas.

Pour faire bref, on va s’insérer dans le processus de déploiement de Kubernetes pour interdire aux gens de faire des choses qui ne respectent pas vos bonnes pratiques (avec les webhooks) et on va ajouter des APIs supplémentaires pour étendre Kubernetes (les CRDs), de manière à pouvoir décrire qu’est ce qui n’est pas autorisé.

Déploiement

Niveau installation, on reste sur du simple et efficace.

Kyverno propose plusieurs Charts helm :

une pour Kyverno même
une pour Policy Reporter
une contenant un “pack” de règles par défaut, configurées comme “non bloquantes” (en vrai, l’équivalent de ce qu’on pouvait faire avec les Pods Security policies)

Dans le cadre de cet article, je ne m’intéresse qu’à Kyverno même. Mais comme je l’ai dis plus haut, on reparlera des 2 suivantes dans un prochain numéro.

On commence donc par ajouter Kyverno lui-même :

$ helm repo add kyverno https://kyverno.github.io/kyverno/
$ helm repo update
$ helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
 NAME: kyverno
 LAST DEPLOYED: Mon Jul 25 21:55:11 2022
 NAMESPACE: kyverno
 STATUS: deployed
 REVISION: 1
 NOTES:
 Chart version: v2.5.2
 Kyverno version: v1.7.2

 Thank you for installing kyverno! Your release is named kyverno.
 ⚠️ WARNING: Setting replicas count below 3 means Kyverno is not running in high availability mode.

 💡 Note: There is a trade-off when deciding which approach to take regarding Namespace exclusions. Please see the documentation at https://kyverno.io/docs/installation/#security-vs-operability to understand the risks.

Note : vous remarquerez le WARNING à l’install. Par défaut, Kyverno est déployé avec un seul replica. S’il crashe, vous ne pouvez plus rien déployer ou modifier sur votre cluster (ça m’est arrivé). La solution pour s’en sortir est de supprimer les webhooks de Kyverno pour débloquer la situation. Et bien sûr, de lui donner plus d’air (de plus grandes limites, surtout niveau RAM) et surtout 3 réplicas (ou plus)…

Note 2 : Il est probablement préférable d’exclure certains namespaces (kube-system, kyverno, …) du scope de Kyverno pour éviter de mauvaises surprises. Le blogpost Thibault Lengagne de chez Padok en parle aussi (lien en bas de l’article).

Qu’est-ce qu’on a déployé ?

A première vue, pas grande chose. Si on fait un kubectl -n kyverno get all, on trouve juste un Pod (+ReplicaSet +Deplopyment) et deux Services.

Mais en coulisse, on a déployé bien plus que ça ;)

Si on cherche des CRDs, on voit qu’on a pas mal de nouveaux objets à notre disposition.

$ kubectl api-resources --api-group=kyverno.io
 NAME SHORTNAMES APIVERSION NAMESPACED KIND
 clusterpolicies cpol kyverno.io/v1 false ClusterPolicy
 clusterreportchangerequests crcr kyverno.io/v1alpha2 false ClusterReportChangeRequest
 generaterequests gr kyverno.io/v1 true GenerateRequest
 policies pol kyverno.io/v1 true Policy
 reportchangerequests rcr kyverno.io/v1alpha2 true ReportChangeRequest
 updaterequests ur kyverno.io/v1beta1 true UpdateRequest

De même, on a également des nouveaux webhooks

$ kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io
 NAME WEBHOOKS AGE
 kyverno-policy-validating-webhook-cfg 1 8m48s
 kyverno-resource-validating-webhook-cfg 2 8m48s

$ kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io
 NAME WEBHOOKS AGE
 kyverno-policy-mutating-webhook-cfg 1 11m
 kyverno-resource-mutating-webhook-cfg 2 11m
 kyverno-verify-mutating-webhook-cfg 1 11m

A quoi ça sert ? Comment ça marche ?

Pour simplifier, on va décrire ce qu’on ne veut pas autoriser dans notre cluster à l’aide de la CRD ClusterPolicy.

En fonction des règles qu’on aura écrites dedans, les webhooks vont s’insérer dans le processus normal de déploiement de ressources de Kubernetes pour les autoriser ou pas.

Kubernetes Blog - A Guide to Kubernetes Admission Controllers

Exemple des Ingress avec la même URL

Assez de théorie, le plus simple c’est que je vous montre. Je vous l’ai dit au début de l’article, de manière à comparer les deux produits, je vais repartir du même cas d’usage.

Dans mes clusters Kubernetes, je veux interdire à deux applications de créer un Ingress avec la même URL, car dans mon cas personnel, ce n’est pas autorisé. C’est le signe d’une erreur de copié-collé d’une Chart Helm vers une autre (ou tout autre erreur humaine).

La conséquence de cette erreur est un conflit dans le routage des requêtes HTTP entrantes et on se retrouve avec un genre de round robin chelou où la moitié des requêtes tapent le mauvais backend. En prod, ça la fout mal, et on risque de se retrouver avec des clients qui râlent sur Twitter que l’application est down ;-).

Au même titre qu’OPA propose de régler ce problème dans les politiques mises à disposition par la communauté, il existe la même avec Kyverno.

On verra plus en détails dans l’article suivant comment sont construites ces règles. Dans un premier temps, on va juste déployer cette règle en mode “audit” et voir si ça fonctionne.

spec: validationFailureAction: audit

$ kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/unique-ingress-paths/unique-ingress-paths.yaml
 clusterpolicy.kyverno.io/unique-ingress-host created

Si vous avez un cluster kubernetes sous la main, je vous propose donc d’appliquer ces deux Ingress, configurés pour récupérer du trafic depuis la même URL (toto.example.org) :

$ for counter in 1 2; do
cat > ingress${counter}.yaml <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: ingress${counter}
spec:
 rules:
 - host: toto.example.org
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service${counter}
 port:
 number: 4200
EOF
done

$ kubectl apply -f ingress1.yaml
 ingress.networking.k8s.io/ingress1 created
$ kubectl apply -f ingress2.yaml
 ingress.networking.k8s.io/ingress2 created

Normalement, rien ne se passe. Kyverno ne vous empêche pas de créer ces deux Ingress puisqu’on est en mode “validationFailureAction: audit” (même si les backends n’existent pas derrière, ça n’a pas d’importance).

$ kubectl get ingress
 NAME CLASS HOSTS ADDRESS PORTS AGE
 ingress1 <none> toto.example.org 80 90s
 ingress2 <none> toto.example.org 80 87s

En revanche, en allant lire les Events, vous allez trouver des PolicyViolation :

$ kubectl get events --field-selector=reason=PolicyViolation
LAST SEEN TYPE REASON OBJECT MESSAGE
118s Warning PolicyViolation ingress/ingress1 policy unique-ingress-host/check-single-host fail: The Ingress host name must be unique.
118s Warning PolicyViolation ingress/ingress1 policy unique-ingress-host/check-single-host fail: The Ingress host name must be unique.
118s Warning PolicyViolation clusterpolicy/unique-ingress-host Ingress default/ingress1: [check-single-host] fail
115s Warning PolicyViolation clusterpolicy/unique-ingress-host Ingress default/ingress2: [check-single-host] fail

Le fait qu’on ait 2 Ingress pointant sur la même URL est bien détecté et est remonté dans les Events Kubernetes. Chouette :)

En beaucoup plus verbeux, on pourra également récupérer les PolicyReports, qui disent la même chose en (encore ?) moins lisible.

kubectl describe policyreport polr-ns-default
Name: polr-ns-default
Namespace: default
Labels: managed-by=kyverno
Annotations: <none>
API Version: wgpolicyk8s.io/v1alpha2
Kind: PolicyReport
[...]
Results:
 Category: Sample
 Message: The Ingress host name must be unique.
 Policy: unique-ingress-host
 Resources:
 API Version: networking.k8s.io/v1
 Kind: Ingress
 Name: ingress2
[...]
Summary:
 Error: 0
 Fail: 2
 Pass: 0
 Skip: 2
 Warn: 0

On nettoie pour la suite :

$ kubectl delete ingress ingress1 ingress2

“La loi, c’est moi”

Imaginons que vous avez maintenant bien testé vos politiques, que vos devs ne génèrent plus de manifests ne correspondant pas à vos bonnes pratiques (ex. pas de containers en root, des labels obligatoires présents, limits/requests correctes, etc). Votre cluster est propre !

Vous pouvez passer vos politiques de conformités en mode “enforcing”. Contrairement au mode “audit”, ce mode est bloquant et les manifests qui ne respectent pas les politiques en questions seront refusés par Kubernetes.

$ kubectl patch clusterpolicies.kyverno.io unique-ingress-host --patch '{"spec":{"validationFailureAction":"enforce"}}' --type merge

Oui, je fais un “patch” plutôt qu’un “edit” pour me la péter ;-)

Et on teste à nouveau :

$ kubectl apply -f ingress1.yaml
 ingress.networking.k8s.io/ingress1 created

So far, so good

$ kubectl apply -f ingress2.yaml
Error from server: error when creating "ingress2.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Ingress/default/ingress2.yaml was blocked due to the following policies

unique-ingress-host:
 check-single-host: The Ingress host name must be unique.

ET PAF 💥🍫!

Conclusion

Dans cet exemple basique (mais réellement utile), on arrive aussi facilement qu’avec OPA à empêcher les utilisateurs de créer des Ingress ayant la même URL.

On peut alors se demander “pourquoi préférer Kyverno ?”. Au-delà d’autres trucs sympas que nous verrons dans les billets suivants, ma réponse va tenir en une seule image.

Mon point de vue (très personnel), c’est que le rego, c’est illisible et verbeux, et donc pas maintenable. Là encore, c’est personnel, mais je n’ai jamais réussi à m’y mettre.

Sans aller jusqu’à idéaliser le langage de Kyverno*, je trouve que c’est quand même clairement beaucoup plus simple à écrire, mais surtout, à lire. Dans le cas où vous devriez modifier/écrire/maintenir vos propres politiques, cela sera très utile.

(*Oui, il y a un langage, notamment pour le pattern matching… et point irritant, ce n’est pas jsonpath comme pour kubectl, mais JMESPath, similaire mais pas identique…)

Ressources complémentaires

Retrouvez-moi à Devoxx France 2022

Mon, 18 Apr 2022 12:00:00 +0000

J’ai 10 ans 🎶

Devoxx France revient après deux ans de Covid (chaotique pour tout le monde) en présentiel total. Et ce n’est pas n’importe quelle édition de Devoxx, c’est l’année des 10 ans !

Pour ceux qui ne sont pas familiers de cette conférence, Devoxx c’est :

Conférence pour développeurs organisée par Quantixx au Palais des Congrès, à Paris. 60 exposants pendant 3 jours. 3000 visiteurs. 260 orateurs, 220 présentations, ateliers et plénières.

Et cette fois-ci, je serai présent sur les 3 jours, en particulier le jeudi puisque je donnerai mon talk “Ciel, mon Kubernetes mine des bitcoins” (slides ici, comme d’habitude). Je donnerai la conférence le jeudi à 14:30 en salle 243.

J’en parle dans mon billet sur le temps que je mets à préparer une conférence, être sélectionné à des conférences, c’est compliqué, mais à Devoxx encore plus. Il y a beaucoup de speakers expérimentés et de nombreux talks passionnants en simultanée.

Je suis donc particulièrement content de faire partie des heureux élus :). Une superbe occasion de revoir (ou rencontrer IRL) des copains des Internets et des anciens collègues (va même falloir faire une liste je crois 😅).

Comment on fait pour venir ?

Evidemment, il est trop tard pour prendre un billet pour les conférences (ça part en quelques heures), mais cette année il est possible d’accéder au salon et aux stands d’exposants gratuitement, et même d’accéder à certaines conférences, le jeudi soir.

Seule condition, avoir un billet (gratuit du coup je le répète) pour avoir accès aux stands ou aux BOF (événement terminé).

Dans tous les cas, que vous ayez un billet conférence, speaker ou “salon”, n’hésitez pas à me pinger sur Bluesky, Mastodon (@zwindler@framapiaf.org) ou LinkedIn si vous voulez me faire un coucou 👋, ça sera avec grand plaisir !

Le pitch de mon talk

A tort ou à raison, Kubernetes s’est imposé, ces 4 dernières années, comme un des nouveaux standards dans la gestion des architectures microservices modernes.

Cependant cet outil, riche plus que complexe, amène son lot de pièges dans lesquels les débutants ne manqueront pas de tomber… Et ce n’est pas l’apparente facilité apportée par les offres Kubernetes as a Service qui va arranger les choses !

Après un rapide tour de l’actualité sécurité autour de Kubernetes, je vous donnerai les clés pour éviter de vous faire voler (trop facilement) vos cycles CPU.

Open Source Experience 2021 – Récap’ du 2ème jour

Fri, 12 Nov 2021 07:00:00 +0000

Deuxième jour à OSXP

Je vous parlais plus tôt dans la semaine de ma première journée à OSXP.

Il est donc temps d’enchaîner avec la seconde ;-)

Comment contribuer à l’Open Source (ou pas) sans être éditeur de solutions Open Source

J’ai commencé la journée par un talk de Rémi VERCHERE, qui a fait un retour sur quasiment 20 ans d’expérience d’interaction, en entreprise, avec l’open source.

Ce que je retiens de son intervention, c’est surtout que les entreprises ont pris conscience au fur et à mesure de l’intérêt de l’open source, pour elles.

Quand il travaillait dans le domaine de l’embarqué en début de carrière, l’open source était vu comme un simple moyen de mise en conformité (mise à disposition du code modifié). Au fur et à mesure qu’il a changé d’employeurs, il a pu à la fois influencer (demander à l’entreprise de contribuer financièrement, accepter de laisser les employé en inter-contrat contribuer, …) et contribuer plus ouvertement.

Aujourd’hui, dans son entreprise actuelle, c’est marqué noir sur blanc dans son contrat de travail qu’il peut (doit?) contribuer aux logiciels libres et à l’open source.

Créer à partir de zéro un chabot opérationnel en 20 minutes avec Tock

Dans cette session, François NOLLEN nous a fait une démo live de la création d’un chatbot avec tock, totalement offline et en quelques minutes.

Si l’exemple montré en démo était assez basique, faute de temps, François nous a quand même montré tout un tas de piste d’amélioration pour le chatbot. C’était assez impressionnant de simplicité (intégrations multiples avec des providers tiers genre slack, twitter, etc) et de possibilités (apprentissage).

doc.tock.ai

SEXION d’ASSO (quiz)

Entre midi et deux, le tissu associatif du logiciel libre français a réalisé un quiz rigolo sur les assoss' elles mêmes. C’était très bon enfant et amusant de voir que ces gens sont liés depuis très longtemps.

Et surtout super intro en live de KPTN !

Cloud : enseignements tirés de mes (nos) échecs

Jonathan LE LOUS, Field CTO dans une grande ESN française, a commencé sa session par rappeler 2 choses en anglais :

I fail a lot

To be a master, you have to fail more often than the novice has tried

Grosso modo, dans son métier de consultant, beaucoup de paris qui ont été fait sur l’avenir se sont retrouvés être faux (la fin de VMware, l’ère du tout dans le cloud, l’hégémonie d’openstack, rien ne s’est réalisé).

Ce qu’il explique ensuite, c’est qu’à chaque fois qu’il a “échoué” (terme à prendre avec des pincettes), c’est parce que lui et son équipe étaient trop enthousiastes. Ils pensaient pouvoir gérer tout une nouvelle plateforme, un nouveau produit (eg. Openstack) avec une équipe de 5 personnes.

Sauf qu’il faut plus de 5 personnes et surtout, il faut d’abord casser les silos entre les devs (produit) et les ops, notamment via la communication et la collaboration.

Sans jamais le citer, je pense qu’il voulait parler des principes de devops mais je n’ai pas insisté ;-).

L’Open Source, « contributeur » essentiel au GreenIT

Table ronde avec :

Agnès CRÉPET - directrice Software Longevity & IT - Fairphone
Cyrille CHAUSSON - Rédacteur en chef - IT for Business
Richard HANNA - chargé de mission interministérielle Green Tech - Dinum
Tristan NITOT - Fondateur - Octet Vert
Véronique TORNER - Co-fondatrice et Co-Présidente - Alter way

Le maitre mot de la table ronde était de rappeler que le plus gros pour de GES dans le numérique (et les GES ne sont pas le seul problème) proviennent de la fabrication du terminal et de très loin.

Il est donc important de faire durer les terminaux le plus longtemps possible, notamment en lutant contre l’obsolescence programmée logicielle (aussi bien applicatives que OS).

Les speakers ont mis le doigt sur les éditeurs de logiciels qui refusent de continuer à maintenir les vieux terminaux

La loi de moore a créé une industrie de feignasses. On a des processeurs 100 fois plus puissants mais on ne fait pas 100 fois mieux pour autant ! – Tristan NITOT

Les intervenants ont également parlé de Planet tech care : une association dédiée à la sensibilisation et acculturation des acteurs, notamment l’entreprise, notamment via la mise à disposition d’outils open source.

J’ai un peu décroché quand ça a commencé à parler de The Shift Project…

Comment accueillir plus de femmes dans l’écosystème libre? Éclairage scientifique & pistes concrètes

Lancelot PECQUET, maitre de conférence à Poitier et également auteur d’une enquête sur l’état de l’open source en France, nous a présenté la place des femmes dans l’open source, à partir de données scientifiques, psychologiques et éthiques.

Cette étude est partie d’un constat : il y a proportionnellement moins de dirigeantes dans les entreprises numériques du libre que dans la moyenne des entreprises numériques / startup.

La première question qui vient à l’esprit est “pourquoi ?”. La seconde, la grande question étant “Comment faire un numérique plus inclusif ?”, et plus particulièrement dans le libre ?

Car les enjeux sont multiples : éthiques, sociétaux, économiques (peut on vraiment se priver de 50% des talents ?).

En étudiant ce problème par le scope de code reviews, les chercheurs ont été capables de déceler des biais dans les deux sens. Dans tous les cas, connaître le genre d’un/d’une commiteur/trice affecte négativement la chance que la PR soit acceptée. Cependant, en fonction des cas (contributeur/trice interne ou pas au projet), les codes reviews étaient négativement OU positivement affectées (PR rejetée) si la contributrice est une femme.

On connaît également l’impact plus fort du syndrome de l’imposteur chez les femmes.

Les moyens connus pour combattre ces biais et ces stéréotypes consistent à mettre en avant des femmes qui réussissent dans la tech, des “role model”.

Bien sûr, ce n’est évidemment pas si simple. Il est nécessaire que les femmes puissent s’identifier aux roles models (et donc d’augmenter la diversité dans les role models) pour éviter l’effet de contraste, qui est contre-productif :

“ces femmes sont des wonderwomen, je ne me reconnais pas en elle donc je n’y arriverai pas”

Bref, il reste beaucoup de travail.

Exposants et village associatif

J’ai eu un discussion un peu trop courte mais intéressante avec quelqu’un de chez Prestashop (j’ai malheureusement oublié son nom désolé :-(…) sur les services de streaming en ligne et surtout sur le fait qu’ils utilisent ou non des codecs libres. Une vraie réflexion…

Je me suis fait “pinger” sur Twitter par Jean Couteau, que j’avais connu lors des RRLL avec Alliance Libre en 2020. Je suis donc allé le voir sur le stand de réseau Libre-Entreprise

Le réseau Libre-entreprise regroupe des entreprises à taille humaine ayant des spécialités proches ou complémentaires dans le domaine du logiciel libre. Toutes partagent les mêmes valeurs et modes de fonctionnement, basés sur la démocratie d’entreprise, la transparence et la compétence.

C’était une conversation vraiment très riche, j’ai pu apprendre plein de choses sur les SCOP, mais aussi d’autres modèles d’entreprises comme celles à participation ouvrière. On a parlé entreprise horizontale, transparence, salaire unique.

On a également échangé sur les leviers pour participer au libre en entreprise (mécénat, participation à des projets, hackatons, …). De quoi donner quelques idées :-).

Côté SIDO, j’ai rencontré la société Smile qui a présenté une petite maquette d’industrie 4.0 avec des machines connectées, des capteurs connectés, des serveurs open source, … et réalité augmentée pour aider le technicien qui remplace les pièces détectées comme usées.

Ca m’a fait sourire car c’est des choses que j’ai déjà vu (depuis longtemps) dans un contexte technique précédent ;-).

Globalement, j’ai profité de ce dernier jour pour l’imprégner de la bonne ambiance générale dans le village associatif, avec des gens ouverts et respectueux, à 1000 lieues de tous les clichés qui peuvent encore tourner…

A refaire !

Sécurité on Zwindler's Reflection

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

Flannel, flannel, flannel…

On vérifie pour être bien sûr

Les alternatives pour ajouter le support

Installer Cilium en mode CNI chaining

Prérequis

Récupérer la configuration CNI de flannel

Créer le ConfigMap de chaining

Installer Cilium via Helm

Vérification

Tester les NetworkPolicies

Bonus : Hubble, l’observabilité réseau

Combien ça coûte en ressources ?

Conclusion

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Le déclic

Ce que teste HTTP Observatory

Étape 1 : les headers “faciles”

Étape 2 : Content-Security-Policy (la vraie difficulté)

Inventaire des ressources externes

Le problème des scripts d’analytics externes

Supprimer unsafe-inline de script-src

Supprimer unsafe-inline de style-src, la suite

La CSP finale

Nettoyage bonus : Mailchimp

Résultat final

Touraine Tech 2026 - Récap du jour 2

Jour 2 - C’est reparti !

Lorsqu’un simple bug réseau vous emmène dans les entrailles de Linux

L’ampoule qui en savait trop : voyage au cœur de la sécurité des objets connectés

Au secours ! Mes images pourrissent mes perfs

Makers de Père en Fils

Another World, une belle leçon d’architecture logicielle

Communauté et remerciements

Retrouvez-moi dans le podcast Hack'n Speak (0x33)

Hack’n Speak

0x33 – Du Kubernetes, de la sécurité, une anecdote

Les liens mentionnés dans l’épisode

Merci Martial !

Vos politiques de conformité sur Kubernetes avec Kyverno - part 2

Récap’ de la partie 1

Aller un peu plus loin

User experience

Kyverno policy reporter

Policy Reporter UI

Slack

Et si on faisait une violation de politique, pour voir ?

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec Kyverno

Introduction

Prérequis

Déploiement

Qu’est-ce qu’on a déployé ?

Exemple des Ingress avec la même URL

“La loi, c’est moi”

Conclusion

Ressources complémentaires

Retrouvez-moi à Devoxx France 2022

J’ai 10 ans 🎶

Comment on fait pour venir ?

Le pitch de mon talk

Open Source Experience 2021 – Récap’ du 2ème jour

Deuxième jour à OSXP

Comment contribuer à l’Open Source (ou pas) sans être éditeur de solutions Open Source

Créer à partir de zéro un chabot opérationnel en 20 minutes avec Tock

SEXION d’ASSO (quiz)

Cloud : enseignements tirés de mes (nos) échecs

L’Open Source, « contributeur » essentiel au GreenIT

Comment accueillir plus de femmes dans l’écosystème libre? Éclairage scientifique & pistes concrètes

Exposants et village associatif

Supprimer `unsafe-inline` de `script-src`

Supprimer `unsafe-inline` de `style-src`, la suite