Webhook on Zwindler's Reflection

Kyverno a tué mon API Server. Encore.

Thu, 26 Feb 2026 08:00:00 +0200

Le retour de la vengeance

Vous avez peut-être lu mon article précédent sur etcd il y a 3 ans. Si vous vous en souvenez bien, le crash, c’était etcd, mais le vrai coupable, c’était Kyverno. J’adore Kyverno. C’est vraiment un logiciel que j’aime beaucoup. Notamment parce que c’est puissant(issime). J’ai d’ailleurs écrit un article d’intro et un second qui va plus loin sur le sujet.

Mais le nombre d’incidents et de side effects chelou que ça provoque. Mamamia… C’est pas le premier incident de l’année que j’ai avec Kyverno (oui, on est en février) mais comme celui-là est rigolo, je vous le partage.

Lors d’une opération de maintenance de routine pour mettre à jour un cluster Kubernetes vers la version 1.34 (depuis la 1.32), on s’est retrouvé face au scénario redouté par tout admin kube : un API Server totalement injoignable au redémarrage des nœuds du Control Plane.

Ce qui ressemblait initialement à une erreur réseau classique s’est avéré être un deadlock subtil entre les nouvelles fonctionnalités réseau natives de Kubernetes et notre cher Kyverno 😘.

Spoiler : c’était pas un problème réseau. C’est jamais un problème réseau. Enfin si, des fois. Mais pas cette fois.

L’upgrade qui commence bien

Bon, un upgrade de Kubernetes, c’est devenu assez banal à ce stade. On fait ça régulièrement, on a nos procédures, on est des pros (si si). On passe de la 1.32 à la 1.34 en un seul commit, sans faire le petit saut par la 1.33 comme recommandé.

TKT FRR.

Dans le contexte technique dont je parle, tout est géré as code. De la création des machines jusqu’au déploiement de Talos, en passant par les MachineConfig (les CustomResources pour modifier… et bien, la machine).

Pour plus d’infos, voir la documentation Talos sur les Machine Configs.

Le premier cluster qu’on teste n’a qu’un seul control plane (me demandez pas pourquoi, ça n’aurait probablement rien changé). Talos relance l’API Server dans la nouvelle version et là… rien.

Les logs de l’API Server “chelous” (terme technique) parlent d’eux-mêmes :

I0224 15:32:50.979280 1 default_servicecidr_controller.go:166] Creating default ServiceCIDR with CIDRs: [10.1.0.0/20]
W0224 15:32:50.984784 1 dispatcher.go:225] rejected by webhook "validate.kyverno.svc-fail":
admission webhook "validate.kyverno.svc-fail" denied the request:
Get "https://10.1.0.1:443/api": dial tcp 10.1.0.1:443: connect: operation not permitted
I0224 15:32:50.985342 1 event.go:389] "Event occurred" kind="ServiceCIDR"
apiVersion="networking.k8s.io/v1" type="Warning"
reason="KubernetesDefaultServiceCIDRError"
message="The default ServiceCIDR can not be created"

😬😬😬

La root cause : un magnifique cercle vicieux

Après investigation, on a découvert que l’incident était le résultat d’une collision entre une évolution du core de Kubernetes et notre configuration Kyverno. Un beau cas d’école de deadlock.

Décomposons le mécanisme :

Le nouveau Kind ServiceCIDR

Dans les versions récentes (v1.33+), Kubernetes migre la gestion des plages d’IP de services vers des objets dédiés nommés ServiceCIDR. Au premier démarrage après l’upgrade, l’API Server tente de créer automatiquement l’objet par défaut (par exemple 10.1.0.0/20).

Pour les curieux, la KEP-1880 et la documentation officielle du ServiceCIDR détaillent cette évolution.

C’est nouveau, c’est propre, c’est bien pensé. Sauf que…

Interception par le Webhook Kyverno

Kyverno, configuré avec une failurePolicy: Fail (parce qu’on est des gens sérieux qui ne laissent pas passer n’importe quoi en prod), est programmé pour intercepter les créations de ressources afin de les valider, et faire échouer le call si Kyverno ne répond pas.

Y compris le ServiceCIDR fraîchement créé par l’API Server lui-même.

Deadlock

Et c’est là que ça devient magnifique (“la douleur peut être une source de plaisir” - Mozinor) :

L’API Server suspend la création du ServiceCIDR en attendant le “OK” de Kyverno
Pour contacter le service Kyverno, l’API Server doit router la requête via l’IP du service Kubernetes (en général 10.1.0.1)
Sauf que la couche réseau (routage vers les services) ne peut pas s’initialiser tant que l’objet ServiceCIDR n’est pas validé et créé

C’est l’œuf et la poule, version “j’ai les clés de la voiture dans la voiture fermée à clé”.

PTSD. Oui ça m’est arrivé. Dans le désert. Sans réseau.

Profit.

L’API Server tombe en timeout ou renvoie une erreur connect: operation not permitted en tentant de joindre le webhook, bloquant ainsi sa propre initialisation. CrashLoopBackOff sur l’API Server. :D

Sortir du deadlock

Pour sortir de ce deadlock, il faut bypasser temporairement la couche d’admission. Facile, non ?

Le workaround “habituel” : inutile

Les deadlocks avec Kyverno, on a l’habitude à ce stade. Normalement, comme kube-system est ignoré, on peut simplement se connecter avec un kube-config de secours (breaking glass, on est en OIDC normalement) qui a le cluster role cluster-admin et supprimer les validating webhooks de Kyverno :

kubectl delete validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg

Sauf que là, c’est l’API Server qui ne démarre même pas. Mon kubectl ne risque pas de fonctionner !

Le vrai workaround : désactiver les webhooks au boot

La solution qu’on a choisie a été de modifier la configuration de l’API Server pour désactiver temporairement les webhooks de validation au démarrage. Mon éminent collègue Maxime a édité à chaud le machine config (avec un accès talosctl breaking glass) pour ajouter le flag suivant directement dans les extraArgs de l’API server :

--disable-admission-plugins=ValidatingAdmissionWebhook

Pour ceux qui ne savent pas trop comment ça fonctionne l’admission control dans Kubernetes, sachez juste qu’il y a une liste de plugins “par défaut” mais que tout est débrayable. Je ferai peut-être un jour un deep dive sur l’admission control dans Kubernetes, c’est fascinant ;).

Avec ce flag, l’API Server peut enfin créer ses objets ServiceCIDR sans demander la permission à personne (on bypass complètement tous les mécanismes de validation que Kyverno ou assimilé enforce), le réseau s’initialise, Kyverno démarre, et on peut ensuite retirer le flag et relancer proprement.

L’option “golri” qu’on n’a pas testée

Personnellement, je trouvais très rigolo l’idée d’aller modifier directement la base etcd pour supprimer la clé du webhook qui posait problème (là aussi en passant par talosctl) :

# Exemple via etcdctl
etcdctl del /registry/admissionregistration.k8s.io/validatingwebhookconfigurations/kyverno-resource-validating-webhook-cfg

Mes collègues étaient moins chauds : “Ouais mais tu comprends, si on casse etcd ça va être pénible”. On a joué la sécurité avec le flag. Je suis super déçu, on n’a pas testé 😂.

La solution permanente : les MatchConditions

OK, maintenant que le cluster est reparti, comment on s’assure que ça ne se reproduise pas au prochain upgrade ?

La solution propre consiste à utiliser les matchConditions (introduites en Kubernetes 1.27) au niveau de la ValidatingWebhookConfiguration. Ça permet d’exclure les ressources critiques de bootstrap réseau avant même que la requête ne tente de sortir de l’API Server vers le pod Kyverno.

Voir la doc officielle sur les matchConditions.

On utilisait déjà cette option pour limiter le trafic parfois abusif de Kyverno (si vous administrez du Kyverno, vous savez de quoi je parle) sur un certain nombre d’événements (on écroule l’API server et/ou Kyverno en CPU ou RAM, selon les cas). Il a suffi d’ajouter les exclusions pour les nouveaux types :

# Exclusion des ressources de bootstrap réseau pour éviter le deadlock
matchConditions:
 - name: 'exclude-ServiceCIDR'
 expression: '!(request.kind.kind == "ServiceCIDR")'
 - name: 'exclude-IPAddress'
 expression: '!(request.kind.kind == "IPAddress")'

Avec ça, quand l’API Server crée un ServiceCIDR au boot, la requête ne passe même plus par le webhook Kyverno. Pas de dépendance circulaire, pas de deadlock, tout le monde est content.

Conclusion

Comme dirait notre cher (non) président :

qui aurait pu prévoir ?

Bon ok, il suffisait de lire les release notes de Kubernetes 1.33. Cela étant dit, on a un cluster de staging, il sert à ça. On a cassé staging, no big deal

Peut-être qu’on lira quand même, la prochaine fois ?

Automatiser son site Hugo sans Github Action ou Vercel

Tue, 01 Aug 2023 06:00:00 +0200

Contexte

Fin 2021, après plus de 10 ans à écrire des articles de blog tech sur Wordpress, je prenais la décision radicale d’arrêter de maintenir cette bouse infâme (je mâche mes mots) et de partir sur des articles rédigés en markdown et un site statique avec Hugo.

Au tout début, je gérais le blog moi-même mais assez vite j’en ai eu assez de devoir aller rebuild le blog à chaque modification. J’ai rapidement mis un cron qui faisait des git pull régulièrement, mais on ne va pas se mentir, c’est assez crado…

Finalement, on m’a rapidement pointé que je devrais arrêter de m’embêter et utiliser Netlify ou Vercel.

J’étais pas super chaud, car ça allait à l’encontre de ma volonté d’auto héberger mon contenu et de limiter l’impact sur la vie privée de mes lecteurs, mais finalement, l’expérience utilisateur sur Vercel était tellement bonne que j’avais craqué. Je ferai peut-être un article là-dessus d’ailleurs, c’est la première fois que j’ai compris (ressenti) l’intérêt d’un PaaS.

Mais aujourd’hui, je reviens sur cette décision et j’essaye de voir ce qu’il est nécessaire de mettre en place pour disposer soi-même d’un site hugo qui se refresh tout seul dès qu’un commit arrive sur le dépôt git, sans utiliser de plateforme type Vercel ni d’outils types Github action+pages.

Prérequis

Je pars du principe que vous avez déjà un site statique généré avec Hugo. Si ce n’est pas le cas je vous invite à aller lire mes articles précédents sur le sujet (premiers pas, stats avec matomo, migration wordpress vers hugo).

Vous avez donc un serveur Linux sur lequel vous avez la main pour installer des choses et un dépôt git (sous Github dans mon cas, mais on peut probablement adapter l’article pour autre chose).

Hugo étant d’abord un générateur de site statique, je vais utiliser nginx en frontal pour servir les fichiers qu’on va générer. Jusqu’à il y a peu, l’usage du mode “server” de hugo n’était d’ailleurs pas conseillé en production (mais ça ne semble plus être le cas, je n’ai pas vu de warning dernièrement ?).

apt install nginx git

Déposer les sources sur le serveur

Dans mon cas, les sources de mon blog ne sont pas disponibles publiquement (parce que j’ai pas envie, c’est comme ça ¯\_(ツ)_/¯).

Il faut donc préalablement se loguer en SSH avec git avant de pouvoir pull le code. Et comme je n’ai pas envie de laisser ma clé privée sur le serveur qui va héberger mon blog, il faut que j’utilise une autre clé.

Dans mon cas, Github, qui héberge le code markdown de mon blog, a une notion de “deploy keys”, qui servent justement pour ça :

docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys

Je vais donc créer une clé sur le serveur qui héberge le blog :

ssh-keygen -t ed25519 -C "xxx@xxx.tld"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/toto/.ssh/id_ed25519):
[...]

Et je la copie dans le dossier de www-data (l’utilisateur nginx sous Ubuntu)

chmod 600 /root/.ssh/id_ed25519
sudo mkdir /var/www/.ssh/
sudo cp ~/.ssh/id_ed25519* /var/www/.ssh/
chown www-data: /var/www/.ssh/*

Une fois la clé créée, on doit l’ajouter dans Github.com. Je ne lui donne que les droits “read only” puisque le but c’est seulement de récupérer le code et générer le site statique, pas qu’on puisse éditer le code (cé pour la sécuritay).

Je retourne ensuite sur mon serveur et j’essaye de télécharger les sources et le thème:

cd /usr/share/nginx/html
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git
cd blog.example.org/themes
git submodule add -f https://github.com/CaiJimmy/hugo-theme-stack.git
chown -R www-data: /usr/share/nginx/html/blog.example.org

Webhook

Pour réagir à l’arrivée d’un nouveau commit sur notre dépôt source, on va utiliser 2 choses :

un projet qui s’appelle sobrement “Webhook”.
configurer un webhook dans github, qui va envoyer l’info que quelque chose est arrivé sur le dépôt (mais on verra ça plus tard)

Revenons à “Webhook” dans un premier temps :

webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered.

On récupère la dernière release et déposer le binaire sur notre serveur :

github.com/adnanh/webhook/releases/tag/2.8.1

export VERSION="2.8.1"
wget https://github.com/adnanh/webhook/releases/download/${VERSION}/webhook-linux-amd64.tar.gz

tar -xvf webhook*.tar.gz

sudo mv webhook-linux-amd64/webhook /usr/local/bin
rm -rf webhook-linux-amd64*

webhook --version

Une fois que c’est fait, on va générer une chaîne aléatoire qui va nous servir de “secret” qui sera partagé entre le binaire webhook qui tourne sur notre serveur et un webhook sur Github.com :

WHSECRET=`uuidgen | base64`
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa==

On crée un fichier de configuration hook.json pour déclarer nos webhooks

mkdir /etc/webhook
cat > /etc/webhook/hook.json << EOF
[
 {
 "id": "redeploy",
 "execute-command": "/usr/share/nginx/html/blog.example.org/blog_refresh.sh",
 "command-working-directory": "/usr/share/nginx/html/blog.example.org",
 "trigger-rule":
 {
 "match":
 {
 "type": "payload-hmac-sha1",
 "secret": "$WHSECRET",
 "parameter":
 {
 "source": "header",
 "name": "X-Hub-Signature"
 }
 }
 }
 }
]
EOF

Ici, quand le serveur va recevoir l’url /hooks/redeploy, on va lancer le script /usr/share/nginx/html/blog.example.org/blog_refresh.sh depuis le répertoire /usr/share/nginx/html/blog.example.org.

Charge à nous de créer un script qui va soit :

récupérer les sources (git pull)
relancer un build

Voilà à quoi pourrait ressembler le script blog_refresh.sh :

#!/bin/bash
cd /usr/share/nginx/html/blog.example.org

#pull latest version
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git

#refresh theme submodule
git submodule init
git submodule update

#rebuild (fire and forget)
hugo --minify --gc &

On va ensuite créer un service systemd qui va lancer le binaire webhook en tâche de fond

cat > /etc/systemd/system/webhook.service << EOF
[Unit]
Description=Simple Golang webhook server
ConditionPathExists=/usr/local/bin/webhook
After=network.target

[Service]
User=www-data
Group=www-data
Type=simple
WorkingDirectory=/usr/share/nginx/html/blog.example.org
ExecStart=/usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
Restart=on-failure

[Install]
WantedBy=default.target
EOF

systemctl enable webhook
systemctl start webhook

Côté Github.com, on crée le webhook qui va contacter le serveur webhook de la façon suivante :

On a maintenant un serveur web qui est en attente de certains événements webhooks et qui va lancer un script si jamais l’URL de webhook est appelée par Github.com.

Configuration nginx

Il reste maintenant toute la configuration de notre nginx en frontal à faire. En partant du principe qu’on vient juste de faire l’installation du package, on commence par supprimer le fichier /etc/nginx/sites-enabled/default, et on en crée un nouveau :

rm /etc/nginx/sites-enabled/default

cat > /etc/nginx/sites-available/blog.example.org.conf << EOF
# Root configuration
server {
 listen 80;
 server_name blog.example.org;

 location /hooks/ {
 proxy_pass http://127.0.0.1:9000/hooks/;
 }

 error_page 404 /404.html;

 location / {
 root /usr/share/nginx/html/blog.example.org/public;
 index index.html;
 }
}
EOF
ln -s /etc/nginx/sites-{available,enabled}/blog.example.org.conf

On vérifie que la configuration est valide et si oui on redémarre nginx

nginx -t
systemctl reload nginx

A partir de maintenant, toutes les URLs qui arriveront jusqu’à votre serveur en /hooks seront redirigées sur le logiciel “webhook” et le reste ira sur votre site statique (/usr/share/nginx/html/blog.example.org/public).

curl https://blog.example.org/hooks/redeploy -L
Hook rules were not satisfied.%

Ici le hook renvoie une erreur, car on a pas envoyé le token secret mais c’est probable que ça fonctionne. Toutes les autres pages renvoient bien une page du blog :

curl https://blog.example.org/
<!DOCTYPE html>
<html lang="fr-fr" dir="ltr">
 <head>
 <meta name="generator" content="Hugo 0.115.1"><meta charset='utf-8'>
[...]

On peut maintenant envoyer des commits et voir si ça déclenche des rebuilds de notre blog. Ou alors, on peut récupérer un push précédent et cliquer sur “Redeliver” si on veut trigger un rebuild du blog.

root@hugo:~# systemctl status webhook
* webhook.service - Simple Golang webhook server
 Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2023-07-31 07:34:35 UTC; 33s ago
 Main PID: 900109 (webhook)
 Tasks: 15 (limit: 4574)
 Memory: 240.4M
 CPU: 45.504s
 CGroup: /system.slice/webhook.service
 |-900109 /usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
 `-900161 hugo --minify --gc

Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 attempting to load hooks from /etc/webhook/hook.json
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 found 1 hook(s) in file
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 loaded: redeploy
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 serving hooks on http://127.0.0.1:9000/hooks/{id}
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 os signal watcher ready
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] incoming HTTP POST request from 127.0.0.1:43258
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy got matched
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy hook triggered successfully
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] 200 | 0 B | 1.151688ms | 127.0.0.1:9000 | POST /hooks/redeploy
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] executing /usr/share/nginx/html/blog.example.org/blog_refresh.sh
[...]
Jul 31 07:37:28 hugo webhook[900109]: Pages | 3572
Jul 31 07:37:28 hugo webhook[900109]: Paginator pages | 516
Jul 31 07:37:28 hugo webhook[900109]: Non-page files | 14
Jul 31 07:37:28 hugo webhook[900109]: Static files | 2282
Jul 31 07:37:28 hugo webhook[900109]: Processed images | 2
Jul 31 07:37:28 hugo webhook[900109]: Aliases | 1563
Jul 31 07:37:28 hugo webhook[900109]: Sitemaps | 1
Jul 31 07:37:28 hugo webhook[900109]: Cleaned | 0
Jul 31 07:37:28 hugo webhook[900109]: Total in 166131 ms
Jul 31 07:37:28 hugo webhook[900109]: [webhook] 2023/07/31 07:37:28 [f089a0] finished handling redeploy

Conclusion

Si vous êtes à l’aise avec Linux et nginx, ces quelques manipulations sont assez rapides à faire, il n’y a rien de vraiment complexe.

Cependant, ça demande à l’usage un peu d’administration et de vouloir mettre les mains dans le cambouis (avoir une VM à gérer). Je ne peux reprocher à personne de préférer l’utilisation de Github/Gitlab pages, couplé à de Github actions/Gitlab runners, voire de tout déléguer à Vercel/Netlify…

Mais j’avais envie de reprendre la main sur le hosting de mon blog (avec tous les inconvénients que ça va avoir en termes de maintien en condition opérationnelle), notamment pour disposer à nouveau de l’IPv6 (perdue lors du passage à Vercel) et une navigation sur mon blog plus respectueuse de votre vie privée (pas que j’aie pas confiance en Vercel, mais bon…).

Et c’est en revanche beaucoup plus simple que d’héberger son propre serveur Gitlab + Gitlab runners + Gitlab pages ;-).

Donc, pour mon usage, ça fait le taf :)

Webhook on Zwindler's Reflection

Kyverno a tué mon API Server. Encore.

Le retour de la vengeance

L’upgrade qui commence bien

La root cause : un magnifique cercle vicieux

Sortir du deadlock

La solution permanente : les MatchConditions

Conclusion

Automatiser son site Hugo sans Github Action ou Vercel

Contexte

Prérequis

Déposer les sources sur le serveur

Webhook

Configuration nginx

Conclusion

Ressources additionnelles