Secret & Vaultwarden Readiness Audit¶

Stand: 2026-05-30

Kurzfazit¶

Wiederkehrende Arbeiten wie Obsidian/Qdrant Reindex, Hermes Retrieval Tests, LiteLLM Validierung, Voice Tests und Memory Jobs scheitern nicht am Konzept, sondern am falschen Ausfuehrungsort: Sie werden aktuell oft aus einer lokalen Entwickler-Session gestartet, die produktive Runtime-Secrets nicht dauerhaft und sicher haben soll.

Zielbild: Der Entwickler-Laptop braucht keine produktiven Reindex-/Runtime-Secrets. Reindex, Retrieval Validation, Memory Consolidation und Scheduled Governance Checks gehoeren serverseitig in die Agent Runtime beziehungsweise auf lanstyle-hermes-01.

Aktuell blockierte Aufgaben¶

Aufgabe	Blocker	Bewertung
Obsidian -> Qdrant Reindex	Qdrant API Key und LiteLLM Embedding Key lokal nicht sicher verfuegbar	serverseitig ausfuehren
Hermes Retrieval Test mit Auth	Hermes API Token lokal nicht sicher verfuegbar	serverseitig oder gezielter Testtoken
LiteLLM Smoke mit Auth	Healthcheck-/User-Key lokal nicht fuer Runtime-Checks geeignet	serverseitiger Healthcheck-Key
Voice Tests	Hermes Voice/Service Token lokal nicht stabil bereitgestellt	eigener Voice-Testtoken
Memory Consolidation Jobs	Nous/Hermes/Qdrant/LiteLLM Secrets fehlen lokal	serverseitiger Job
OpenWebUI Model Governance Test	normaler User/Admin Vergleich braucht echte Session oder scoped Testaccounts	Browser-/Server-E2E mit Testuser

Secret-Abhaengigkeiten¶

Secret Purpose	Source of Truth	Vaultwarden Entry	Runtime Location	Auto Available?	Manual Unlock Required?	Blockiert welche Funktionen?
OpenCode LiteLLM User Key	Vaultwarden / Self-Service	`Lanstyle / OpenCode Access / <user-device>`	lokal `~/.config/opencode/secrets.env`	lokal ja, wenn eingerichtet	bei Erstsetup/Rotation	OpenCode Chat/Models
OpenCode MCP Token	Vaultwarden / MCP token store	`Lanstyle / OpenCode Access / <user-device>`	lokal `~/.config/opencode/secrets.env`, serverseitiger MCP Token Store	lokal ja, wenn eingerichtet	bei Erstsetup/Rotation	Remote MCP, OpenCode Tools
Context7 API Key	Vaultwarden	`Lanstyle / OpenCode Context7 API Key`	lokal optional	optional	bei Erstsetup	Context7 Tool
LiteLLM Admin/Master Key	Vaultwarden	`Lanstyle / LiteLLM Admin`	Agent Runtime Env	serverseitig ja	lokal nein	Virtual-Key-Erzeugung, Admin-Smoke
LiteLLM Healthcheck/Embedding Key	Vaultwarden	`Lanstyle / Nous Hermes LiteLLM Routing / lanstyle-hermes-01` oder dedizierter Healthcheck-Key	Agent Runtime / Hermes Runtime Env	serverseitig vorgesehen	lokal nein	Reindex, Retrieval, Healthcheck
Qdrant API Key	Vaultwarden	`Lanstyle / Nous Hermes Qdrant Memory / lanstyle-hermes-01`	Agent Runtime / Qdrant / Hermes Runtime Env	serverseitig vorgesehen	lokal nein	Qdrant Reindex, Retrieval, Snapshot
AI Gateway API Token	Vaultwarden	`Lanstyle / Hermes Service Token / lanstyle-hermes-01`	`/etc/hermes/hermes.env`	serverseitig ja	lokal nein	Authentifizierte Gateway Tests
Hermes Core API Key	Vaultwarden	`Lanstyle / Nous Hermes Core API / lanstyle-hermes-01`	`/etc/nous-hermes/nous-hermes.env` und Gateway Env	serverseitig ja	lokal nein	Gateway -> Nous Core
Hermes Memory Qdrant Key	Vaultwarden	`Lanstyle / Nous Hermes Qdrant Memory / lanstyle-hermes-01`	`/etc/hermes/hermes.env`	serverseitig ja	lokal nein	Gateway Retrieval
Tools API Bearer	Vaultwarden	`Lanstyle / Tools API Token`	Agent Runtime Env	serverseitig ja	lokal nein	Controlled Execution Policy, OpenAPI Tools
NetBox Test Write Token	Vaultwarden	`Lanstyle / NetBox API Token Agent Test Write`	Agent Runtime Env	serverseitig ja	lokal nein	NetBox scoped test writes
Proxmox API Token	Vaultwarden	`Lanstyle / Proxmox API Token Agent`	Agent Runtime Env	serverseitig ja	lokal nein	Proxmox scoped actions
NPM API Token	Vaultwarden	`Lanstyle / Nginx Proxy Manager API`	Agent Runtime Env	serverseitig ja	lokal nein	NPM export/update actions

Readiness Scores¶

Bereich	Score	Begruendung
Secret Readiness	62/100	Runtime-Secrets existieren konzeptionell, aber Jobs verwenden noch uneinheitlich lokale ENV, Runtime ENV und Vaultwarden Unlock.
Vaultwarden Readiness	58/100	Vaultwarden ist Source of Truth, CLI ist aber lokal regelmaessig locked und kein automatisierter serverseitiger Sync fuer Jobs dokumentiert.
Reindex Readiness	45/100	Indexer ist vorhanden, Collection existiert, aber Secret-Loading und serverseitige Scheduling-/Runbook-Reife fehlen.
Developer Laptop Safety	78/100	Lokale Secrets sind fuer OpenCode vorhanden, aber produktive Runtime-Secrets sollten weiter reduziert werden.
Server Job Readiness	55/100	Agent Runtime ist der richtige Ort, braucht aber eigene systemd/Runbook-Jobs fuer Reindex und Retrieval Validation.

Befund: lokale Entwickler-Sessions als Engpass¶

Ja, Hermes/Qdrant/OpenCode-Arbeiten scheitern wiederkehrend daran, dass lokale Entwickler-Sessions Vaultwarden entsperren oder produktive Secrets bereitstellen muessten.

Das ist ein Architektur-Smell:

Entwickler-Laptops sollen keine dauerhaften Qdrant-/LiteLLM-/Hermes-Runtime-Secrets tragen.
Reindex-Jobs gehoeren nicht auf den Laptop.
Authentifizierte Runtime-Smokes sollen serverseitig laufen.
Lokale OpenCode-Secrets sind nur fuer den eigenen Client, nicht fuer Plattformwartung.

Server-seitige Jobs¶

Diese Jobs sollten serverseitig laufen:

Job	Ort	Frequenz	Secrets
Obsidian Reindex	Agent Runtime LXC `259`	manuell + scheduled	Qdrant + LiteLLM Embedding
Qdrant Collection Validation	Agent Runtime	scheduled	Qdrant read
Hermes Retrieval Validation	Hermes LXC oder Agent Runtime	scheduled	Hermes API + Qdrant/LiteLLM
Memory Consolidation Preview	Hermes LXC	scheduled/manual	Hermes Core + local state
Session Summaries	Hermes LXC	scheduled/manual	Hermes Core
Scheduled Governance Checks	Agent Runtime	scheduled	Tools API + LiteLLM Healthcheck
OpenWebUI Model Visibility Test	controlled E2E runner	on change	scoped test user

Zielarchitektur¶

Entwickler-Laptop¶

keine produktiven Runtime-Secrets
keine Qdrant Reindex Jobs
keine dauerhaften Admin-/Master Keys
nur eigene OpenCode User Tokens
optional kurzlebige Evaluation Keys
kein Vaultwarden Unlock als Routine-Abhaengigkeit fuer Plattformjobs

Server¶

Vaultwarden Source of Truth
Runtime Secrets in root-only Env-Dateien
systemd Services/Timers fuer Reindex und Validation
Audit ohne Secretwerte
Secret Rotation Runbooks
Jobs fail-closed bei fehlenden Secrets

LiteLLM-Key Exposure Audit¶

Ein LiteLLM-Key konnte sichtbar werden, weil eine lokale Environment-Inventarisierung zuerst nicht strikt genug redacted war. Es war Tool-Output aus einer lokalen Shell-Session, kein produktiver Service-Log und kein Git-/Doku-Commit.

Ursache:

ENV-Dump/Printenv-Check mit Wertausgabe statt nur SET/MISSING.
Lokale Session enthielt einen echten OpenCode-/LiteLLM-Key.

Secretwert wird hier bewusst nicht wiedergegeben.

Empfehlung:

betroffenen LiteLLM-Key rotieren, wenn Tooltraces als exponiert gelten
kuenftig nur Secret-Namen und Status ausgeben
Shell-Hilfsfunktionen fuer Redaction nutzen
printenv, env, set, Debug Dumps und Exception-Traces mit ENV-Inhalt vermeiden

Vermeidungsregeln¶

Erlaubt:

python3 - <<'PY'
import os
for key in ["LITELLM_API_KEY", "QDRANT_API_KEY"]:
    print(f"{key}={'SET' if os.getenv(key) else 'MISSING'}")
PY

Nicht erlaubt:

printenv
env
set
echo "$LITELLM_API_KEY"

Empfohlene Automatisierungen¶

lanstyle-obsidian-reindex.service + .timer auf Agent Runtime.
lanstyle-hermes-retrieval-validation.service auf Hermes oder Agent Runtime.
lanstyle-memory-consolidation-preview.service auf Hermes, nur Preview und Review-Queue.
lanstyle-secret-readiness-check.service, der nur Secret-Status/Fingerprints prueft.
lanstyle-openwebui-model-visibility-check mit Testuser, ohne Secretwerte im Log.

Naechste konkrete Schritte¶

LiteLLM-Key aus der lokalen Session rotieren, falls Tooltrace-Exposure relevant ist.
Server-seitigen Reindex-Job bauen.
Qdrant/LiteLLM Keys nur serverseitig fuer Reindex nutzen.
Developer-Laptop von Reindex-/Runtime-Validierungsjobs entkoppeln.
Vaultwarden CLI Workflow fuer Server-Jobs dokumentieren: unlock/sync/provision/lock, ohne Secretwerte zu loggen.