<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Jwt on Daniel &#39;f0o&#39; Preussker</title>
    <link>https://f0o.dev/tags/jwt/</link>
    <description>Recent content in Jwt on Daniel &#39;f0o&#39; Preussker</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 06 May 2026 15:14:01 +0000</lastBuildDate><atom:link href="https://f0o.dev/tags/jwt/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Zero Trust in GKE: Envoy, OPA, and Workload Identity</title>
      <link>https://f0o.dev/posts/2026/05/zero-trust-in-gke-envoy-opa-and-workload-identity/</link>
      <pubDate>Wed, 06 May 2026 15:14:01 +0000</pubDate>
      
      <guid>https://f0o.dev/posts/2026/05/zero-trust-in-gke-envoy-opa-and-workload-identity/</guid>
      <description>&lt;p&gt;I have been thinking a lot about internal traffic lately. We spend weeks locking down our perimeters and adding layers of WAFs. But what happens when a rogue pod inside the cluster decides to reach out to your billing service?&lt;/p&gt;
&lt;p&gt;Usually it just works. And that terrifies me.&lt;/p&gt;
&lt;p&gt;We blindly trust local network segments way too much. I wanted to fix this without deploying a massive heavyweight service mesh. I just needed a simple, bulletproof way to authenticate, authorize, and log every single internal request.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
