TLS-Gate: NetBox-Connector je Gruppe, Schritt 1–3 (Weg zur ersten Passkante Crumbforest-CA)

Von: Branko → OZMAI, Crew
Stand: 11. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: STAND + DESIGN_INTENT + NACHTRAG. Setzt 2026-10-11_TLS-GATE-V3-14-0-MONITOR-OFFENE-BUCHUNGEN-GETAGGT-NACHTRAG_BRANKO.md fort. Ersetzt keine frĂŒhere Aussage. Nimmt den Faden „NetBox als SOT“ aus v3.6.1 wieder auf.
Quelle: Repo TLS-Gate-Mock-Pipeline, main 949d114, ohne eigenen Tag (nach v3.14.0 = e494a87). Entwurf docs/DESIGN_NETBOX_CONNECTOR.md.
Belege: lokal 37 von 37 Suiten grĂŒn, neu tests/test_netbox.sh (56). Vier absichtlich kaputte Fassungen werden je rot: ohne Tenant-PrĂŒfung, ohne Regel b, ohne UrsprungsprĂŒfung, ohne count. VM nach docker_vm/build.sh aus 949d114 (dirty=0): run 91, p3 48, p4 54, p5 31 (erwartet jetzt 22 Tabellen), p6 22, p7 53, p8 23 (neu, dreimal hintereinander grĂŒn). Regel b einmal von Hand unter MariaDB durch booking_cli add geprĂŒft.

Legende: ✅ real/gebaut · đŸ§Ș gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Tokens, keine echten GerÀte, keine Ausgaben aus der echten NetBox. Alle Testdaten synthetisch (*.test, MACs 02:
).

1. Anlass (Branko, 11.10.)

„Wir sind die Ansible-Node, wir haben eine NetBox und die ganzen Dienste in einem eigenen System bereits am Laufen. Der SOAP-Zugang ist nur wichtig fĂŒr Kaufzertifikate.“ Der Crumbforest lĂ€uft bereits mit WireGuard und Let's Encrypt. Was fehlt, ist der Connector an der BrĂŒcke: ein NetBox-Zugang je Gruppe, der die GerĂ€te in die TLS-DB spiegelt, damit Produkte, Dienste und ZugĂ€nge innerhalb der Gruppe an ein GerĂ€t gebunden werden können. Die Vision ist eine eigene OZM/Crumbforest-CA, und dafĂŒr sind alle Bausteine schon da. Das wĂ€re die erste Passkante.

2. Belege aus dem Ansible-Repo (vom Entwickler gelesen, ohne credentials/, ohne Live-Abfrage)

  • ✅ Gruppengrenze = Tenant, Pseudonym (ozm, kruemel-<opak>); die eiserne Regel lautet „keine Spur zum Kind“ (docs/NETBOX-ORGANISATION.md).
  • ✅ NetBox 4.2+: MAC als eigenes Objekt, am Interface als primary_mac_address (netbox-raspis.yml).
  • ✅ Mobile GerĂ€te: „IdentitĂ€t = der WireGuard-Public-Key, nicht eine MAC“. Der Key steht im Kommentar (netbox-mobile-clients.yml).
  • ✅ VPN: VRF CrumbVPN, 10.42.0.0/24, wg0 mit einer /32 (netbox-vpn.yml).

3. Entscheidungen

# Entscheidung Quelle
N1 Nur lesen, NetBox bleibt fĂŒhrend Entwickler, analog Registrar
N2 Zugang je Gruppe = URL + Token (versiegelt) + Tenant-Slug. Das Gate filtert selbst und lehnt fremde Zeilen ab Entwickler
N3 Regel (b): KrĂŒmel-Tenants werden nur gespiegelt, ohne Bindung an ein Konto. Eine Buchung auf ein solches GerĂ€t wird abgelehnt. Kontobindung gibt es nur, wenn sie ausdrĂŒcklich gesetzt ist (z. B. ozm) Branko, 11.10.: „ja (b)“
N4 Die MAC ist eine beobachtete Tatsache, kein SchlĂŒssel. Über WireGuard sieht niemand eine MAC. Der empfohlene Anker ist der GerĂ€te-Slot netbox:<id> Entwickler, auf Brankos Frage
N5 Kein stilles Umbinden. Eine neue MAC wird als changed alt → neu protokolliert, und die Anker-PrĂŒfung meldet HARDWARE GEÄNDERT Entwickler
N6 „KrĂŒmel verliert seinen Zero, kommt mit altem Zertifikat auf neuer MAC zurĂŒck“ = SchlĂŒsselverlust, kein Umzug: altes Zertifikat keyCompromise widerrufen, fĂŒr das neue GerĂ€t neu ausstellen. Bewusster Reset, Schritt 4 Entwickler, Brankos Fall; BestĂ€tigung offen

4. Was gebaut ist (Schritt 1–3)

  • đŸ§Ș Zugang: netbox_cli.php zugang add|replace|enable|disable|list. Der Token kommt nur ĂŒber STDIN, ist versiegelt (eigener Zweck netbox) und an Gruppe und Label gebunden: Ein kopierter Blob öffnet sich nicht. key migrate versiegelt mit.
  • đŸ§Ș Spiegel: fetch|load|sync|status|events|geraete. Gelesen werden GerĂ€te, MACs, VPN-IP und wg-Key. Kommentare, Adressen und Kontakte verlassen den Client nicht. Wie beim Registrar-Bestand ist der erste Lauf die Baseline, danach werden nur Änderungen protokolliert.
  • đŸ§Ș Fail closed: count muss stimmen. Eine Zeile mit fremdem Tenant lehnt alles ab. Eine ungĂŒltige MAC bricht ab. Kein Redirect, und ein next-Link auf einen fremden Host wird nicht verfolgt, der Token bleibt beim hinterlegten Host. TLS wird geprĂŒft. Jeder Lauf steht mit ctx.build im Audit.
  • đŸ§Ș Anker: netbox_cli.php anker meldet je Buchung ok, unbekannt, weg, mehrdeutig, HARDWARE GEÄNDERT oder REGEL B. Bookings::add lehnt kein_kontobezug und anker_ungueltig ab.
  • đŸ§Ș Fake-NetBox in der VM: Die Szenarien wĂ€hlt der Token: Grundstand, Zero verloren (neue MAC, ein GerĂ€t weg), fremder Tenant, fremder next-Host, falscher Token.

5. Befund beim Testen

Buchung und Hardware-Wechsel in derselben Sekunde wurden nicht als „Hardware geĂ€ndert“ gemeldet (ts > created_at). Jetzt gilt >=: Im Zweifel wird gemeldet statt geschwiegen.

6. Was NICHT belegt ist

  • ⬜ Lauf gegen die echte NetBox (seeds.crumbforest.io). DafĂŒr braucht es je Tenant einen Token, der in NetBox nur lesen und nur diesen Tenant sehen darf (Object Permission). Der heutige globale Token reicht technisch, widerspricht aber Regel 5 der Organisations-Doku. Ergebnis nur als Brankos Aussage.
  • ❓ Die genaue NetBox-Version (laut Repo ≄ 4.2). Der wg-Key steht nur im Kommentar; ein Custom Field wĂ€re robuster.
  • ⬜ Schritt 4, die Passkante: Die Node-CA stellt fĂŒr ein gespiegeltes GerĂ€t aus, und der Reset bei Hardware-Wechsel wird ein gefĂŒhrter Schritt. Offen ist, ob MAC oder wg-Key ins Zertifikat gehören. Vorschlag des Entwicklers: nicht hinein, nur ins Audit.
  • ⬜ Web-Ansicht des Spiegels, VMs, Tags → FĂ€higkeiten (netbox_caps.py).

7. Einordnung als PrĂŒffall (Branko, nicht OZMAI-Geltung)

Ein Spiegel der Verwaltung ist keine Beobachtung der Welt: NetBox sagt, welche MAC Ansible zuletzt eingetragen hat, nicht welche Hardware gerade spricht. Deshalb bindet das Gate an den Slot und behandelt die MAC als Zeugnis, dessen Änderung gemeldet wird. Die eiserne Regel bleibt intakt: Das Gate verbindet KrĂŒmel-GerĂ€te nicht mit Konten (Regel b), es wird also nicht zum Ort, an dem Pseudonym und Person zusammenfinden.