<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Zero Trust on Tom Meurs</title>
    <link>https://tommeurs.nl/en/tags/zero-trust/</link>
    <description>Recent content in Zero Trust on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Wed, 08 Apr 2026 20:23:00 +0100</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/tags/zero-trust/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cilium: eBPF Networking for Kubernetes</title>
      <link>https://tommeurs.nl/en/posts/cilium-ebpf-networking/</link>
      <pubDate>Wed, 08 Apr 2026 20:23:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/cilium-ebpf-networking/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; Cilium is the CNI I run in every cluster. It replaces kube-proxy and its iptables chains with eBPF programs in the kernel, enforces network policies on identity and on HTTP paths, and Hubble shows me every flow and every drop. WireGuard between the pods, BGP to the switch, no sidecars. My production values are at the bottom.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;The first time a service stopped resolving in one of my clusters, I spent an evening reading iptables chains. Hundreds of rules, generated by kube-proxy, evaluated top to bottom. I never found the problem. I restarted the node and it went away.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Zero Trust Explained: The Hotel Key Card Metaphor</title>
      <link>https://tommeurs.nl/en/posts/zero-trust-explained/</link>
      <pubDate>Thu, 19 Feb 2026 21:34:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/zero-trust-explained/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; The old model is a castle. Get past the wall and you&amp;rsquo;re trusted everywhere inside. Zero trust is a hotel. Your key card opens your room, the gym if you booked it, and nothing else, and every door checks the card every time. Below, the three principles, a day in that hotel, and what the key card turns into once the doors are software.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;&amp;ldquo;So what is this zero trust thing everyone keeps talking about?&amp;rdquo;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kubernetes RBAC: Least Privilege in Practice</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-rbac-least-privilege/</link>
      <pubDate>Tue, 19 Aug 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-rbac-least-privilege/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SPIFFE and SPIRE: Zero Trust Service Identity</title>
      <link>https://tommeurs.nl/en/posts/spiffe-spire-zero-trust/</link>
      <pubDate>Sat, 26 Jul 2025 10:00:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/spiffe-spire-zero-trust/</guid>
      <description>&lt;p&gt;How does Service A know that Service B is actually Service B?&lt;/p&gt;&#xA;&lt;p&gt;I keep coming back to that question because the usual answer is uncomfortable. For years we trusted network location. Traffic from the right IP was legitimate, end of story. Zero trust took that assumption out back and shot it. Now every service has to prove who it is, every single request, no matter where it sits on the network.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kubernetes Network Policies: A Visual Guide to Pod Security</title>
      <link>https://tommeurs.nl/en/posts/kubernetes-network-policies-visual/</link>
      <pubDate>Sat, 08 Feb 2025 19:34:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/kubernetes-network-policies-visual/</guid>
      <description>&lt;p&gt;Picture this: an attacker pops a single pod in your cluster, maybe through a vulnerable image or a leaked token. From that one foothold, they can reach every database, every internal API, every secret-fetching sidecar you run. Nothing stops them, because by default nothing tries to.&lt;/p&gt;&#xA;&lt;p&gt;Network Policies are the thing that stops them. They turn &amp;ldquo;one compromised pod&amp;rdquo; into &amp;ldquo;one compromised pod, and that&amp;rsquo;s it.&amp;rdquo; Everyone knows they should use them. Almost nobody actually does, because the YAML looks scary and the behaviour is weird until the mental model clicks.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
