#kubernetes

DNS ist das Protokoll, das jeder Firewall durchlässt. Nicht aus Konfigurationsfehler, sondern aus Notwendigkeit: Ohne Namensauflösung funktioniert in einem modernen Netz schlicht nichts — also bleibt Port 53/udp offen, fast immer sowohl Richtung des rekursiven Resolvers des Hauses als auch, häufig genug, Richtung beliebiger öffentlicher Resolver im Internet. Genau das ist der Spalt, durch den sich Exfiltration und Command-and-Control seit drei Jahrzehnten quetschen. dnscat2 hat das 2014 vorgemacht; das Tool ist in die Jahre gekommen, das Prinzip nicht.

Dieser Beitrag stellt wisp (ursprünglich dc - für dnscat) vor — ein Projekt, das ich als Machbarkeitsstudie gebaut habe, um zwei Dinge zu zeigen: erstens, dass ein modernes, kryptografisch hartes DNS-Tunnel-Tool heute ohne viel Aufwand möglich ist, und zweitens — und das ist mir mindestens genauso wichtig —, dass die Verteidigungsseite das nur erkennt, wenn sie es aktiv sucht. wisp ist zugleich Angriffs-POC und Argument für DNS-Firewalling, Response-Rate-Limiting, Egress-Filtering freier Resolver und DoH-Blocking. Wer nur eines davon macht, verliert schon. Zur Reverse-Shell kommt eine !get-Exfiltration über denselben E2E-Kanal — und ein Bootstrap-Modell, das kein PSK jemals ausliefert: jedes gestempelte Binary trägt sein eigenes Token, das beim ersten Frame verbraucht wird.

Tor-Konnektivität im Cluster hatte ich bisher zusammengesteckt: pro Pod ein client-only tor plus ein oder zwei socat-Sidecars, die lokale TCP-Ports in Onion-Services übersetzten — genau das Setup, das ich im IRC-Bouncer-Beitrag beschrieben habe. Das funktioniert, skaliert aber nicht als Muster: Jeder Workload, der eine .onion 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. tor-operator ist ein eigener, in Rust geschriebener Kubernetes-Operator, der Tor-Konnektivität in beide Richtungen als CRD anbietet.

Resource-Requests und -Limits habe ich in meinem Lab lange so gesetzt, wie man es eben macht: ein paar Werte aus dem Bauch, 100m/128Mi als Reflex, und dann nie wieder angefasst. Auf einer dicken Cloud ist das egal. Auf vier RK1-Boards mit endlichem ARM-Speicher ist es das nicht: Setze ich zu hoch, verschenke ich Kapazität, die kein anderer Pod mehr bekommt, weil der Scheduler den Request reserviert, nicht den Verbrauch. Setze ich zu niedrig, holt mir der OOM-Killer nachts einen Pod ab oder die CPU wird in den Boden gethrottlet. Beides hatte ich. Was mir fehlte, war kein Gefühl, sondern eine Zahl.

In Radicle CI — eine Pipeline, die auf Patches reagiert habe ich den Plan beschrieben: Meine Seed-Node läuft in-cluster und führt einen Event-Stream — jede neue Patch-Ref, jedes COB-Update wird sichtbar. Ein CI-Broker abonniert diesen Stream, übersetzt ein Patch-Event in einen Build und schreibt das Ergebnis zurück auf den Patch. Sauberes Diagramm, klare Idee, ein offenes Trust-Problem, das ich für lösbar hielt.

Was dieser Beitrag erzählt, ist die Lücke zwischen dem Diagramm und einem grünen Häkchen. Sie war größer, als mir lieb war. Zwischen „der Broker ist deployt" und „der Broker baut wirklich ein signiertes Image" lagen rund zwei Dutzend Commits, die fast alle fix: heißen — und jeder davon steht für eine Wand, gegen die ich gelaufen bin. Kein Architektur-Pitch, sondern ein Reisebericht durch Entrypoints, die nicht stimmen, durch Flux, das meine Shell-Variablen frisst, durch rootless buildah, das in Kubernetes prinzipiell nicht funktioniert, und durch einen Kernel, der meinen QEMU-Handler immer wieder vergaß.

In meinem Lab läuft seit Wochen ein KI-Agent mit — ZeroClaw , im Chat nur Claw —, der die Cluster überwacht, mir auf Matrix Bescheid gibt und Reparaturen als Radicle-Patches vorschlägt statt sie selbst durchzudrücken. Über genau einen Bug bin ich dabei so lange gestolpert, dass er mich am Ende zu einer der unangenehmsten Migrationen des ganzen Setups getrieben hat: dem Sprung von v0.7.5 auf v0.8.0. Das ist ein brechendes Pre-1.0-Release — ein von Grund auf neu geschriebenes Config-Schema, eine Multi-Agent-Runtime und ein neues On-Disk-Layout. Dieser Beitrag erzählt, warum ich diese Migration trotzdem unbedingt wollte, was dabei alles zerbrochen ist und welche Fehler mir erst zur Laufzeit um die Ohren geflogen sind.