ai-tools/private-proxy-mcp
Watch
2
0
Fork
You've already forked private-proxy-mcp
 0
Code Issues 2 Pull requests 1 Projects Releases 5 Packages 2 Wiki Activity Actions
Page: Shared-Key
Pages
ADR-Browser-Backend ADR-Browser-Identity-Playwright ADR-MCP-Go-SDK ADR-Rust-Proxy-Tauri ADR-Tunnel-Protocol Architecture CLI Compatibility Configuration Deployment Desktop-Proxy Development Home MVP-Acceptance Releases Security-MCP-Exposure Security-Network-Policy Shared-Key Troubleshooting
1 Shared-Key
frank edited this page 2026-07-17 16:36:52 +02:00
Table of contents

Shared Key: Erzeugung, Speicherung und Rotation

Zweck

private_proxy.shared_key authentisiert genau die ausgehende private-proxy-Verbindung am Reverse Connector. Er authentisiert keine MCP-Benutzer. Beide Prozesse müssen bytegleich denselben zufälligen Wert verwenden.

Erzeugung

Ein Key mit 256 Bit Entropie und ohne Whitespace:

umask 077
openssl rand -hex 32

Der ausgegebene Wert wird direkt in den Secret Store übernommen. Er darf nicht in Shell-History, Tickets, Wiki, Repository, Container-Image oder Logs landen. Alle Werte in dieser Dokumentation sind Platzhalter.

Speicherung

Bevorzugt wird ein Plattform-Secret-Store, der den Wert beim Start als geschützte Datei oder Environment-Variable bereitstellt. Für eine lokale Datei:

private_proxy:
  shared_key: "REPLACE_FROM_SECRET_STORE"
  • Eigentümer ist ausschließlich der Service-Account, Modus 0600.
  • Server- und Proxy-Host erhalten getrennte Secret-Kopien mit identischem Wert.
  • Backups sind verschlüsselt; Debug-/Support-Bundles schließen die Datei aus.
  • Ein CLI-Flag ist für kurzlebige Tests vorhanden, aber in Produktion wegen Prozesslisten und Shell-History zu vermeiden.

Der Wert wird beim Prozessstart gelesen. Es gibt weder Live-Reload noch eine API zum Auslesen. Logs redigieren Shared-Key- und Authorization-Werte.

Rotation

Version 1 akzeptiert genau einen Key; eine Rotation hat daher ein kurzes Reconnect-Fenster:

  1. neuen Key erzeugen und atomar in beiden Secret Stores vorbereiten;
  2. mcp-server mit dem neuen Key geordnet neu starten; die alte Verbindung endet und Readiness wird 503;
  3. private-proxy mit dem neuen Key neu starten;
  4. /health/ready muss wieder 200 liefern und Logs müssen eine aktive Session ohne auth_error zeigen;
  5. alten Key aus Secret Store, Deploy-Artefakten und zulässigen Backups entfernen beziehungsweise sperren.

Bei vermuteter Kompromittierung wird der Server zuerst umgestellt, damit der alte Key sofort nicht mehr akzeptiert wird. Geplante Rotationen werden in einem Wartungsfenster durchgeführt. Ein Rollback erfordert bewusstes erneutes Ausrollen des alten Keys auf beiden Seiten.