<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Obfs4 on Fuchsbau</title><link>https://this-is-fine.io/tags/obfs4/</link><description>Recent content in Obfs4 on Fuchsbau</description><generator>Hugo</generator><language>de-DE</language><lastBuildDate>Wed, 01 Jul 2026 14:30:00 +0200</lastBuildDate><atom:link href="https://this-is-fine.io/tags/obfs4/index.xml" rel="self" type="application/rss+xml"/><item><title>Tor als CRD: ein eigener Operator statt Sidecar-Bastelei</title><link>https://this-is-fine.io/posts/20260701-tor-operator-kubernetes/</link><pubDate>Wed, 01 Jul 2026 14:00:00 +0200</pubDate><guid>https://this-is-fine.io/posts/20260701-tor-operator-kubernetes/</guid><description>&lt;p&gt;Tor-Konnektivität im Cluster hatte ich bisher zusammengesteckt: pro Pod ein client-only &lt;code&gt;tor&lt;/code&gt; plus ein oder zwei &lt;code&gt;socat&lt;/code&gt;-Sidecars, die lokale TCP-Ports in Onion-Services übersetzten — genau das Setup, das ich im &lt;a href="https://this-is-fine.io/posts/20251117-irc-znc-tor-inspircd/"&gt;IRC-Bouncer-Beitrag&lt;/a&gt;
 beschrieben habe. Das funktioniert, skaliert aber nicht als Muster: Jeder Workload, der eine &lt;code&gt;.onion&lt;/code&gt; erreichen oder selbst eine anbieten wollte, brachte seinen eigenen Tor-Prozess und seine eigene Klebeschicht mit. Also habe ich das Ganze zu dem gemacht, was es im Lab sein sollte: einer Custom Resource. &lt;strong&gt;&lt;code&gt;tor-operator&lt;/code&gt;&lt;/strong&gt; ist ein eigener, in Rust geschriebener Kubernetes-Operator, der Tor-Konnektivität in beide Richtungen als CRD anbietet.&lt;/p&gt;</description></item></channel></rss>