DevOps on Tom Meurs

Supply Chain Security in GitLab CI: SBOM, cosign, and the Policy That Blocks

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

TL;DR A pipeline that scans images and writes an SBOM, with nothing checking either at admission, had been green for a year and had stopped nothing. Four steps below: an SBOM Trivy can read back, a cosign signature on the digest with the key in Vault, the SBOM attached as an attestation, and a Kyverno policy that refuses the rest. Then a table of which SLSA Build L3 requirements a self-hosted GitLab runner meets, and the two it doesn’t.

NIS2 for Platform Teams: Which Control Satisfies Which Article

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

TL;DR The Cyberbeveiligingswet has applied since 15 August 2026. Below, the ten measures of article 21 mapped onto controls that actually run, a Kyverno policy that proves one of them, the reporting deadlines as three Prometheus alerting rules, and the four duties no YAML covers. The first run of that policy found seven pods in my own cluster I’d have sworn were mirrored.

Infrastructure as Code for People Who Need to Understand

Sat, 30 May 2026 19:45:00 +0100

Someone opens a cloud console, clicks through a wizard, accepts a few defaults, and a resource appears. The dashboard goes green and everyone moves on. That’s still how a lot of infrastructure gets built in 2026, and I’ve built some of it that way myself.

I can’t work like that for long. When I click a button and infrastructure appears, it feels borrowed. I want the configuration written down somewhere I can read it back, and I want to know why something exists, not only that it exists. The console gives me a green tick. It doesn’t give me any of that.

Building an Internal Developer Platform: Where to Start

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

TL;DR An Internal Developer Platform is a thin layer between what a developer wants and what the cluster demands. Mine is a Helm base chart, ArgoCD and a handful of Kyverno policies, about 500 lines of my own code. Start with those three, and add observability and a portal only when the tickets tell you to.

Should you build an Internal Developer Platform? Usually, yes. It’s the how that wrecks teams.

Arch vs NixOS as a Workstation: Professional and Personal Use

Tue, 03 Mar 2026 21:28:00 +0100

TL;DR I’ve run Arch and NixOS as my daily machine, and today it’s Arch on both desktops and NixOS on the servers. Arch’s reputation for breaking is mostly a missing snapshot. With btrfs, Snapper, dotfiles in git and a package list, a rollback takes 2 minutes and the fear of updates goes away. NixOS earns its learning curve when several machines have to stay identical, and on a server I wouldn’t run anything else.

CTF and Forensics Skills That Make You a Better DevOps Engineer

Fri, 27 Feb 2026 19:52:00 +0100

TL;DR I spend my evenings on Hack The Box and it’s made me better at my day job, which is platform engineering and has nothing to do with pentesting. The first ten minutes on a CTF box and the first ten minutes on a broken production server are the same loop, with “flag” swapped for “incident”. Below is the toolkit that loop runs on, from one host up to a Kubernetes pod, with the CTF use and the work use side by side for every command.

Data-Driven Kubernetes Migration: Why You Need Metrics Before You Move

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

TL;DR An e-commerce client moved a PHP monolith to EKS in October, two weeks before Black Friday, with resource limits guessed from the old server specs. Mid-morning the pods hit their memory limit, died in a loop for four hours, and the estimate was €240,000 in lost revenue. The second half is how to get those numbers from load tests and VPA recommendations instead of guessing them.

“We want to migrate to Kubernetes by November.”

Kubernetes RBAC: Least Privilege in Practice

Tue, 19 Aug 2025 10:00:00 +0200

TL;DR Kubernetes ships with a permission model that hands every pod a token and lets the default service account collect rights nobody remembers granting. Least privilege means a service account per workload, no token unless the app talks to the API, and roles that name the namespace, the resource and the verb. Below are the four RBAC resources, the five settings that cap the blast radius, the bindings I copy most often, and how I check and enforce all of it.

Kyverno Policies: Governance as Code for Kubernetes

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

I used to keep a wiki page titled “Cluster conventions”. Resource limits on everything. No :latest tags. No deploys in the default namespace. It was a good page. Nobody read it. Six months in, half the cluster broke those rules and I only found out when something fell over.

A rule that lives in a doc is a suggestion. A rule the API server refuses to accept is governance. That gap is the whole reason this post exists.

Progressive Delivery with Argo Rollouts: Canary and Blue-Green Deployments

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

A standard Kubernetes Deployment had served me well for a long time. Push a new image tag, watch the pods roll, done. It was simple, it was declarative, and most of the time nothing went wrong. The rolling update even gave me a warm feeling of safety: old pods only get torn down once new ones are ready.

That feeling is a lie. A rolling update protects you from pods that fail to start. It does nothing to protect you from pods that start perfectly and then serve broken responses. The container is healthy, the readiness probe is green, and your new code is quietly returning 500s to every single user. Within seconds, 100% of your traffic is hitting code that nobody validated under real load.

Container Image Scanning with Trivy in Your CI Pipeline

Sun, 08 Jun 2025 10:00:00 +0200

Pull a base image, copy in your code, push it to production. That’s the loop most of us run on autopilot. The part nobody looks at is the base image itself, which quietly drags in a few hundred packages you never chose. Any one of them could carry a known CVE , and you’d have no idea.

Automating Semantic Versioning with GitLab CI

Tue, 27 May 2025 19:44:00 +0200

Picture the end state first. You merge a branch to main, walk away to get coffee, and by the time you’re back the project has a new version tag, a fresh changelog entry, and a GitLab release with notes written from your commits. Nobody decided “is this 1.4.0 or 1.3.5?” because nobody had to. The version fell out of the work itself.

That’s where I want to get to in this post. I run a self-hosted GitLab and I do not want versioning to be a thing I think about. A version number that someone picks by hand is a tiny black box: it depends on whether that person remembered the rules, was paying attention, and agreed with everyone else about what counts as a breaking change. I would rather the number be a consequence of the commits, something I can inspect and reproduce.

GitLab CI for Kubernetes: From Commit to Deployment

Thu, 15 May 2025 20:33:00 +0200

For a long time my CI lived on someone else’s servers. Push code, wait for a hosted runner, watch the minutes tick down against a monthly quota, hope the provider doesn’t change the rules next quarter. It worked, right up until I started asking where my source code actually sat while it was being built, and who else could see it.

So I moved GitLab in-house. I run it self-hosted now, on my own hardware, next to the clusters it deploys to. That’s sovereignty applied to CI/CD: my code, my builds, my artifacts, no vendor that can change pricing, deprecate a feature I depend on, or read my repositories without me knowing.

ArgoCD for Beginners: Your First GitOps Deployment

Sun, 16 Mar 2025 19:15:00 +0100

Here is the thing I never want to do again: ask a cluster what it is running and not trust the answer. For years that was normal. Someone ran kubectl apply, maybe from a laptop, maybe from a CI job nobody could find anymore, and the live state slowly drifted away from anything written down. When I switched to GitOps, that whole category of uncertainty disappeared. I push to Git, and the cluster converges to match. If I want to know what is deployed, I read a file.