Christoph Emsenhuber e9a5b36ecb Passwort-Rotation Etappe 1: dedizierte Service-Accounts statt geteiltem admin
Vor dem Rotieren den Radius erhoben -- und der ist groesser als geplant:
das Admin-Konto teilen sich fuenf Konsumenten. Neben ~/.secrets und der
MikroMCP-Registry haengen der Nautobot-Stack (Portainer-Redeploy noetig)
und VIER HA-mikrotik-Integrationen mit 40 device_tracker daran. Die HA-
Eintraege melden supports_reconfigure=false, sind also nicht skriptbar.

Christophs Entscheid daraufhin: Konten trennen statt ein Passwort teilen.
Nicht das Rotieren ist das Problem, sondern dass ein einziges admin von
fuenf Stellen benutzt wird -- sonst kostet jede Rotation wieder vier
Re-Auths und einen Stack-Redeploy.

Etappe 1 ist durch, rein additiv, kein laufender Dienst beruehrt. Vorher
existierte auf allen vier Geraeten nur admin in der Gruppe full. Jetzt:

  grp-ha        read,api,rest-api,test          -> user ha
  grp-nautobot  ssh,read,write,test,sensitive   -> user nautobot

Passwoerter als MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS in ~/.secrets.
Angelegt ueber ein Skript, das die Werte aus der Datei liest -- bewusst
nicht ueber manage_user, dessen password-Parameter im Transkript landet.

Abnahme auf allen vier Geraeten: ha liest (am Core 59 DHCP-Leases) und
wird beim Schreiben abgewiesen; nautobot kommt per SSH rein und
exportiert. Der Export von nautobot ist byte-identisch zu dem von admin
(391/56/87/87 Zeilen) -- die GC-Compliance driftet beim Umstellen also
nicht, was das Hauptrisiko dieser Etappe war. /user wird von keiner
ComplianceRule abgedeckt, die Konten erzeugen selbst keinen Drift.

Offen: Konsumenten umhaengen (Nautobot-Stack, 4x HA), dann erst admin
rotieren -- danach beruehrt eine Rotation nur noch zwei Dateien.

Eigener Fehler protokolliert: eine Enumeration hat das ap1-Passwort im
Klartext ins Transkript geschrieben. Selber Wert wie der am 22.08.
verbrannte, also keine neue Expositionsklasse -- aber Merkregel ergaenzt,
dass Secrets-Enumeration nur Schluesselnamen ausgibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 21:25:56 +02:00
2026-06-15 19:00:40 +02:00

bf-network-r6

BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.

SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.

Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md

Struktur:

  • docs/vlan-plan.md — VLAN-/Adressplan (final)
  • docs/core-switch-prep.md — Core-Switch Status & Phasen
  • docs/firmware-flash-runbook.md — FW-Flash Historie
  • switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
  • switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
  • inventory/bf.csv / bf.md — IP-Doku (aus IPs.xlsx gespiegelt)
  • inventory/bf-core-ports.csv / .md — Switch-Port-Map

Aktueller Stand (2026-06-09):

  • Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
  • Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
  • Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%