Advanced on Tom Meurs

Supply chain security in GitLab CI: SBOM, cosign en het beleid dat blokkeert

Tue, 29 Sep 2026 09:00:00 +0200

TL;DR Een pipeline die images scant en een SBOM schrijft, zonder dat iets daar bij toelating naar kijkt, stond een jaar op groen en hield niks tegen. Vier stappen hieronder: een SBOM die Trivy kan teruglezen, een cosign-handtekening op de digest met de sleutel in Vault, de SBOM eraan gehangen als attestation, en een Kyverno-policy die de rest weigert. Daarna een tabel van welke SLSA Build L3-eisen een zelfgehoste GitLab-runner haalt, en de twee die hij niet haalt.

NIS2 voor platform teams: welke control voldoet aan welk artikel

Sun, 20 Sep 2026 21:00:00 +0200

TL;DR De Cyberbeveiligingswet geldt sinds 15 augustus 2026. Hieronder de tien maatregelen van artikel 21 gelegd op controls die echt draaien, een Kyverno-policy die er één bewijst, de meldtermijnen als drie Prometheus-alertingrules, en de vier plichten waar geen YAML onder past. De eerste run van die policy vond in m’n eigen cluster zeven pods waarvan ik had gezworen dat ze gemirrord waren.

Internal Developer Platform bouwen: waar begin je?

Wed, 06 May 2026 19:30:00 +0100

TL;DR Een Internal Developer Platform is een dunne laag tussen wat een developer wil en wat het cluster eist. Bij mij is dat een Helm base chart, ArgoCD en een handvol Kyverno policies, zo’n 500 regels eigen code. Begin met die drie, en voeg observability en een portal pas toe als de tickets erom vragen.

Moet je een Internal Developer Platform bouwen? Meestal wel. Het is de hóe waar teams op stuklopen.

Chaos engineering: je cluster kapot maken om het sterker te maken

Tue, 28 Apr 2026 19:45:00 +0100

TL;DR Chaos engineering is je eigen cluster expres kapot maken, met de hypothese vooraf op papier en een rollback binnen handbereik. Ik draai het op de homelab met Litmus: een wekelijkse pod-delete, een maandelijkse node drain, elk kwartaal een game day. Tot nu toe heeft het vier dingen gevonden die het dashboard me nooit had laten zien.

M’n dashboard is een muur van groen. Pods draaien, replicas kloppen, CPU rustig, geen alert te bekennen. Ik kijk ernaar en krijg dat kleine shotje “alles is in orde.” En grotendeels klopt dat ook. Het cluster draait al weken en er is niks omgevallen.

Longhorn vs Rook-Ceph: Kubernetes-storage vergeleken

Mon, 20 Apr 2026 19:38:00 +0100

TL;DR Longhorn en Rook-Ceph geven je allebei gerepliceerde block storage die een dode node overleeft. Longhorn is één Helm-install en een UI waarin je ziet wat een volume doet. Rook-Ceph is Ceph met een Kubernetes-operator eromheen, dus je krijgt block, object én filesystem, en het beheer dat daarbij hoort. Ik draai Longhorn op drie nodes. Hieronder waarom, en wanneer ik zou overstappen.

Draai je eerste stateful workload op een self-hosted cluster en je merkt al snel dat niemand je zomaar een PersistentVolume geeft. Geen storage class van een cloudprovider om op te leunen. Alleen je nodes, hun disks en een Postgres-pod die niet wil schedulen. Een uur lezen verder heb je twee namen over die steeds terugkomen. Longhorn en Rook-Ceph .

Quantum-safe GPG-identiteit met meerdere aliassen

Sat, 18 Apr 2026 10:47:00 +0200

TL;DR Eén GPG-masterkey die alleen certificeert, offline. Drie aliassen eraan gebonden, zodat iedereen kan nagaan dat het dezelfde persoon is. Ed25519-subkeys voor signing en SSH, een ML-KEM-plus-X448-subkey voor encryptie zodat opgenomen ciphertext dicht blijft als er een quantumcomputer komt, en drie backups die er elk van uitgaan dat de andere twee weg zijn. Vereist GnuPG 2.5.

Een cryptografische signature betekent nog steeds precies wat er staat. Is de key van jou en klopt de signature, dan komt de inhoud van jou. Geen vendor heeft je die identiteit gegeven, geen CA kan hem intrekken, geen platform kan hem schorsen. Hij bestaat omdat jij de key hebt gegenereerd, en hij is van jou zolang jij de private helft in handen hebt. Het meeste wat “online identiteit” heet is geleend. Een handle die iemand kan bannen, een e-mailadres dat de domeineigenaar terugpakt op de dag dat het hem uitkomt. Een GPG-signature staat daar helemaal buiten.

Alerting dat werkt: van alert fatigue naar actionable notificaties

Thu, 16 Apr 2026 20:15:00 +0100

TL;DR De meeste default alertregels pagen op een getal zonder gebruiker erachter, en na een week lees je geen page meer. Ik alert op error rate, P99-latency, een disk die binnen 24 uur vol zit en een certificaat dat binnen zeven dagen verloopt, een stuk of tien regels bij elkaar, elk met een runbook. Alertmanager stuurt critical naar de pager, warning overdag naar Slack en info nergens heen. Alles wat geen mens nodig heeft gaat weg.

Cilium: eBPF networking voor Kubernetes

Wed, 08 Apr 2026 20:23:00 +0100

TL;DR Cilium is de CNI die ik in elk cluster draai. Het vervangt kube-proxy en z’n iptables-chains door eBPF-programma’s in de kernel, dwingt network policies af op identiteit en op HTTP-paden, en Hubble laat me elke flow en elke drop zien. WireGuard tussen de pods, BGP naar de switch, geen sidecars. M’n productie-values staan onderaan.

De eerste keer dat een service niet meer resolvede in een van m’n clusters, zat ik een avond iptables-chains te lezen. Honderden regels, gegenereerd door kube-proxy, van boven naar beneden afgelopen. Het probleem heb ik nooit gevonden. Node herstart, weg.

Thanos remote write: push-based metrics voor edge en multi-cluster

Fri, 27 Mar 2026 20:38:00 +0100

TL;DR Thanos Receive draait de metricsstroom om. Elke edge-Prometheus pusht z’n samples via remote_write naar één centraal endpoint, buffert in z’n WAL als de link wegvalt, en ziet nooit een object-storage-credential. Hieronder de Receive StatefulSet, de hashring, de edge-config, twee manieren om het endpoint dicht te timmeren, en de hybride die ik draai met sidecars op de core clusters.

In mijn vorige post over Prometheus en Thanos zette ik de sidecar-architectuur op. Thanos Sidecar draait naast Prometheus, uploadt TSDB-blocks naar object storage en stelt de data via gRPC beschikbaar aan de Querier. Voor clusters in hetzelfde datacenter, met een dikke stabiele link naar de centrale infrastructuur, heb ik daar niks op aan te merken. Alles pullt, en alles kan bij alles.

Declaratieve infrastructuur als compliance documentatie: Talos, NixOS en audit-ready systemen

Mon, 23 Mar 2026 19:28:00 +0100

TL;DR Talos en NixOS booten van een bestand dat zegt wat de machine is. Dat bestand is precies wat een ISO 27001-, SOC 2- of NIS2-auditor wil zien, dus het verzamelen van bewijs krimpt tot een git log, een diff zonder output en een inventarisdump. Hieronder de mapping van config naar control, de scripts, en het deel dat gewoon werk blijft.

Een ISO 27001-audit begint weken voordat de auditor binnenstapt, met iemand die screenshots verzamelt. Configuratieschermen, firewallregels, een dashboard dat laat zien welke patches erop staan. Dan de Word-documenten die beschrijven wat de systemen geacht worden te doen. Dan de change tickets, opgediept uit het ticketsysteem, elk met een “serveronderhoud” erin dat een half jaar later niemand meer kan reconstrueren. Iedereen ziet dat als de prijs van zakendoen. Ik ook, jarenlang.

NixOS vs Talos voor Kubernetes nodes: twee smaken immutable infrastructuur

Sun, 15 Mar 2026 20:37:00 +0100

TL;DR Talos en NixOS zijn allebei declaratief en allebei immutable te maken, en daar houdt de gelijkenis wel zo’n beetje op. Talos draait Kubernetes en verder niks, en er is geen shell om in te driften. NixOS is een volledige Linux waarbij de hele machine in één Nix-config staat. Ik draai Talos op m’n clusternodes en NixOS op de machines eromheen, en deze post is hoe ik bij die verdeling uitkwam.

Talos Linux: het immutable Kubernetes OS dat mijn kijk op nodes veranderde

Wed, 11 Mar 2026 21:15:00 +0100

TL;DR Talos Linux is een Linux die Kubernetes draait en verder niks. Geen SSH, geen shell, geen packagemanager. Elke wijziging gaat via een API en een YAML-bestand in Git. Ik draai m’n nodes er nu drie jaar op, en deze post is hoe ik ophield de shell te missen.

De eerste keer dat ik naar een Talos -node probeerde te SSH’en, kreeg ik niks. Geen shell, geen verbinding, niet eens een loginprompt. Ik heb er een minuut naar zitten staren en me afgevraagd hoe ik een machine moest debuggen waar ik niet in kon.

Data-driven Kubernetes migratie: waarom je metrics nodig hebt voordat je beweegt

Sun, 08 Feb 2026 14:00:00 +0100

TL;DR Een e-commerceklant verhuisde een PHP-monoliet in oktober naar EKS, twee weken voor Black Friday, met resource-limits die gegokt waren op de oude serverspecs. Halverwege de ochtend liepen de pods tegen hun memory-limit aan, gingen vier uur lang in een loop dood, en de schatting was €240.000 aan gemiste omzet. De tweede helft gaat over hoe je die getallen uit loadtests en VPA-aanbevelingen haalt in plaats van ze te gokken.

K8sGPT met een lokaal 70B model op Apple Silicon

Thu, 05 Feb 2026 14:00:00 +0100

TL;DR Ik heb K8sGPT op een Llama 3.3 70B-model gezet dat op een Mac Studio in m’n eigen kantoor draait, zodat er geen clustermetadata het netwerk verlaat, en er drie kapotte workloads doorheen gehaald. Alle drie gevonden, en de fixes die het schreef had ik van een collega geaccepteerd, op de resource-getallen na, want die waren verzonnen. Assisted diagnose werkt, met 25 seconden per query. Autonomous cluster management is nog steeds marketing, en de security-sectie is waarom ik een model niks op eigen houtje zou laten aanpassen.

Runtime security met Falco: detecteer verdacht gedrag in je cluster

Thu, 07 Aug 2025 10:00:00 +0200

TL;DR Trivy en Kyverno keuren een image vóór hij draait. Falco kijkt wat de container daarna doet, syscall voor syscall, en slaat alarm als het gedrag niet bij een rule past. Deze post gaat van het ene ding dat Falco doet naar de config die ik draai, met het ruisprobleem ertussenin.

Ik scande m’n images met Trivy. Ik dwong policies af met Kyverno. Mijn workloads kregen cryptografische identiteit via SPIFFE. Drie lagen preventie, allemaal groen, en een tijdlang voelde dat als genoeg.

SPIFFE en SPIRE: zero trust service identity

Sat, 26 Jul 2025 10:00:00 +0200

Hoe weet Service A dat Service B echt Service B is?

Ik blijf bij die vraag terugkomen, want het gangbare antwoord is ongemakkelijk. Jarenlang vertrouwden we op netwerklocatie. Traffic van het juiste IP was legitiem, klaar. Zero trust nam die aanname mee naar buiten en schoot hem dood. Nu moet elke service bewijzen wie hij is, bij elk request, ongeacht waar hij op het netwerk zit.

Dat klinkt prima op een slide. Het lastige is het bewijs. Hoe laat een pod werkelijk zijn identiteit zien aan een andere pod, zonder dat ik overal met de hand secrets uitdeel en daarna eindeloos hun rotatie zit te bewaken?

Kyverno policies: governance as code voor Kubernetes

Mon, 14 Jul 2025 10:00:00 +0200

Ik had ooit een wiki-pagina met de titel “Cluster conventies”. Resource limits op alles. Geen :latest tags. Geen deploys in de default namespace. Het was een prima pagina. Niemand las hem. Na een half jaar overtrad de helft van het cluster die regels, en ik kwam er pas achter toen er iets omviel.

Een regel die in een doc leeft is een suggestie. Een regel die de API server weigert te accepteren is governance. Dat gat is precies waarom deze post bestaat.

Progressive delivery met Argo Rollouts: canary en blue-green deployments

Fri, 20 Jun 2025 10:00:00 +0200

Een standaard Kubernetes Deployment heeft me lang prima gediend. Push een nieuwe image tag, kijk hoe de pods rollen, klaar. Simpel, declaratief, en meestal ging er niks mis. De rolling update gaf me zelfs een warm gevoel van veiligheid: oude pods verdwijnen pas als de nieuwe ready zijn.

Dat gevoel is een leugen. Een rolling update beschermt je tegen pods die niet opstarten. Hij doet niks tegen pods die perfect opstarten en vervolgens kapotte responses serveren. De container is gezond, de readiness probe is groen, en je nieuwe code stuurt stilletjes 500’s naar elke gebruiker. Binnen seconden raakt 100% van je traffic code die niemand onder echte load heeft gevalideerd.

Drift detection met ArgoCD: hoe weet je of je cluster nog in sync is

Sat, 03 May 2025 19:27:00 +0200

De hele belofte van GitOps is dat Git de source of truth is. Die belofte houdt stand tot het moment dat iemand om 2 uur ’s nachts kubectl edit runt op een deployment om een incident te stoppen, een mutating webhook stilletjes een resource herschrijft, of een half afgemaakte sync je cluster ergens tussen wat Git wilde en wat het kreeg achterlaat. Nu zegt Git het ene en doet het cluster het andere, en niemand heeft het je verteld.

App-of-Apps pattern in ArgoCD: schaalbare GitOps architectuur

Mon, 21 Apr 2025 20:18:00 +0200

Mijn homelab begon met één ArgoCD Application. Daarna een handvol. Toen ik mezelf voor de vijftiende keer kubectl apply -f zag draaien om weer een Application te registreren, wist ik dat ik precies had gebouwd wat ik wilde vermijden: handmatige stappen die ik moest onthouden, in een volgorde die ik moest onthouden, zonder enige administratie van wat er zou moeten bestaan.

Het App-of-Apps pattern lost dat op met één idee. Je maakt met de hand een enkele root Application, en die maakt de rest aan. Na een gewist cluster bouw ik het geheel terug met één kubectl apply. Die eigenschap is de hele reden dat ik het draai, en het is dezelfde reden dat ik überhaupt self-host: ik wil dat de repository de waarheid is, niet mijn geheugen.

GitOps disaster recovery: je cluster herstellen vanuit Git

Wed, 09 Apr 2025 19:52:00 +0200

Een paar jaar lang draaide mijn homelab cluster zonder veel drama. Nodes kwamen en gingen, workloads schoven rond, en het ergste waar ik mee te maken kreeg was af en toe een pod die vastzat in CrashLoopBackOff. Het soort stabiliteit waarbij je stopt met nadenken over wat er gebeurt als het allemaal verdwijnt.

Toen runde ik op een avond een terraform destroy tegen de verkeerde workspace. Tegen de tijd dat ik het doorhad, was de control plane weg. Niet degraded. Weg.

Kubernetes offline draaien: edge computing zonder internet

Tue, 04 Mar 2025 20:47:00 +0100

Wat gebeurt er als je Kubernetes cluster geen internet kan bereiken? Ik bedoel geen trage verbinding. Ik bedoel helemaal geen verbinding. Schepen op zee. Afgelegen mijnbouwlocaties. Fabrieksvloeren met air-gapped netwerken. Militaire deployments.

Voor veel mensen klinkt dat exotisch, alsof het een probleem van iemand anders is. Ik behandel het als een basis-ontwerpeis, en ik leg uit waarom het mijn homelab beter maakt terwijl ik de kabel bijna nooit echt eruit trek.

Graceful degradation in Kubernetes: wat gebeurt er als componenten falen

Thu, 20 Feb 2025 14:22:00 +0100

Iedereen herhaalt de zin dat Kubernetes zelf-herstellend is. Pods sterven, ze komen terug. Nodes vallen weg, workloads herschedulen. Het systeem reconcilieert zichzelf naar de staat die je hebt gedeclareerd, en de meeste dagen denk je er nooit over na.

Dan is op een dag het ding dat het herstel doet juist het ding dat kapot ging. De API server is down. etcd reageert niet. De scheduler zit vast. En nu?

Hoe etcd echt werkt: het hart van je Kubernetes cluster

Mon, 27 Jan 2025 21:47:00 +0100

Als er iets misgaat in Kubernetes, leidt het spoor meestal terug naar etcd. API server timeout? Check etcd. Pods stuck in pending? Misschien etcd. Cluster voelt traag? Waarschijnlijk etcd.

Ik behandelde etcd lang zoals de meeste operators dat doen: als een black box die naast het control plane meedraait. “De database.” Je maakt er een backup van en laat het verder met rust. Maar black boxes voelen voor mij als splinters, en de eerste keer dat een etcd cluster om 2 uur ’s nachts omviel besefte ik dat ik geen idee had waar ik naar keek. Dus heb ik het uitgezocht. En het blijkt te draaien op een handjevol ideeën die, zodra ze landen, de meeste etcd problemen diagnoseerbaar maken in plaats van eng.

Kubernetes high availability: stacked vs external etcd uitgelegd

Wed, 15 Jan 2025 20:23:00 +0100

Het eerste “productie” Kubernetes cluster dat ik draaide had één control plane node. Het tikte weken vrolijk door, totdat een disk kapotging en het hele ding meenam. Elke pod, elke service, weg. Die storing leerde me hoe “single point of failure” echt voelt, en duwde me naar een vraag die ik mensen steeds zie struikelen: als je een cluster bouwt dat node-verlies overleeft, draai je etcd dan op je control plane nodes, of op aparte nodes?