Statische Lanstyle-MCP-Credentials¶

Der enge, manifestgebundene Deploymentpfad für die vier zugehörigen Codeartefakte ist in static-token-code-deployment.md dokumentiert. rbac_governance.py gehört zwingend zum gebundenen Satz, weil die credential_management-Autorisierung der POST-Route daraus geladen wird. Der Pfad verändert keine Compose- oder Secret-/Env-Konfiguration.

Das anschließende, create-if-absent gebundene HMAC-/RBAC-Gate beschreibt static-token-bootstrap.md.

Zweck¶

Die Capability verwaltet ausschließlich statische Zugangseinträge des Lanstyle-Remote-MCP aus LANSTYLE_MCPHUB_TOKENS_JSON und dem Legacy-Fallback LANSTYLE_MCPHUB_TOKEN. Sie gibt keine Credentialwerte aus und verändert die Environment-Quelle nicht. Ein Widerruf wird als wirksame, reversible Deaktivierung in einem gemeinsamen Statusstore gespeichert.

Self-Service-Zugänge aus mcp-tokens.json bleiben im bestehenden /opencode-access-Vertrag. MCPHub-Dashboard-Keys unter /api/auth/keys sind ebenfalls ein separater Store.

API¶

Methode	Pfad	Action-Klasse	Inhalt
`GET`	`/mcp-token-admin/policy`	`read_only`	Readiness und Vertrag
`GET`	`/mcp-token-admin/static`	`read_only`	ID, Name, HMAC-Fingerprint, Scope, Status und Revision
`POST`	`/mcp-token-admin/static/disable`	`credential_management`	CAS-gebundene Deaktivierung mit Receipt
`POST`	`/mcp-token-admin/static/rollback`	`credential_management`	Receipt- und CAS-gebundene Wiederherstellung einer exakten Deaktivierung

Für eine Deaktivierung sind immer gemeinsam erforderlich:

run_id
token_id
name
fingerprint
expected_revision
scope_digest
authorization_source: explicit-user-instruction
nicht-sensitiver authorization_digest
optionaler, strikt formatierter reason_code

Name oder ID allein reichen nicht. Mehrere Einträge mit demselben Credential-Fingerprint blockieren die Ausführung als mehrdeutig.

Ein expliziter Rollback akzeptiert ausschließlich:

eine neue, unverbrauchte run_id;
die original_run_id des erfolgreichen Disable-Receipts;
expected_current_revision, die sowohl der aktuellen Inventory-Revision als auch der Result-Revision des Original-Receipts entsprechen muss;
authorization_source: explicit-user-instruction und einen nicht-sensitiven authorization_digest.

Zusätzliche oder fehlende Request-Felder werden verworfen. Die neue Run-ID ist sowohl durch das exklusiv reservierte Receipt als auch durch den verbrauchten Run-ID-Stand gegen Replay geschützt.

Token-ID, Name und HMAC-Fingerprint werden nicht frei vom Aufrufer übernommen, sondern ausschließlich aus dem root-only Original-Receipt geladen und erneut gegen Quelle und Disable-Marker geprüft.

RBAC und Risiko¶

Die Deaktivierung ist fest als Medium Risk eingestuft. Sie ist nur für credential_rotator, autonomous_operator, senior_approver und emergency_approver zugelassen. credential_rotator ist die engste Rolle und besitzt ausschließlich read_only sowie Medium-credential_management. operator, approver und auditor dürfen sie nicht ausführen. Eine klare Benutzeranweisung wird als explicit-user-instruction attestiert; es gibt keine approval_id.

Technische Gates¶

HMAC-Key mindestens 32 Byte und nur serverseitig verfügbar.
Exakte ID-/Name-/HMAC-Fingerprint-Bindung.
Scope-Digest gegen die konkrete Disable-Aktion prüfen.
Dublettenprüfung gegen statische Quelle und den tatsächlich gemeinsam aufgelösten Self-Service-Tokenstore; ein zweiter aktiver Authpfad blockiert.
Exklusives Lock auf dem autoritativen Statusstore.
Inventory-Revision unter Lock erneut berechnen und per CAS vergleichen.
Prestate und Receipt vor dem Write per fsync speichern.
Nur enabled=false als Overlay setzen; keine Quelle löschen oder überschreiben.
Read-after-write über denselben statischen und dynamischen Resolver, den der Remote-MCP verwendet.
Secretfreies Audit und vollständiges Receipt schreiben.
Bei einem Gate-Fehler nach dem Write den vollständigen Prestate automatisch wiederherstellen und erneut lesen; ein nicht verifizierter Rückweg wird ausdrücklich als rollback_failed gemeldet.

Expliziter Disable-Rollback¶

Der Restore ist kein generisches RBAC-rollback. Die Route bleibt Medium credential_management, sodass credential_rotator keine zusätzlichen Rechte erhält. Unter demselben autoritativen flock gelten alle Gates:

Original-Receipt ist regulär, root-owned, 0600, Status complete und Aktion disable.
Original-Receipt bindet Token-ID, Name, HMAC-Fingerprint, Scope-Digest, erfolgreiche Result-Revision und Rollback-Referenz exakt.
Aktuelle Inventory-Revision entspricht gleichzeitig Request und Original-Result.
Der Disable-Marker gehört exakt zur original_run_id und zum gebundenen Fingerprint.
Nur dieser Marker wird entfernt; generation wird erhöht und die neue Run-ID replay-geschützt verbraucht.
Read-after-write bestätigt enabled=true, Overlay absent und genau einen aktiven Treffer im gemeinsamen statischen/dynamischen Auth-Resolver.
Eigenes root-only Receipt und secretfreies Audit dokumentieren den Restore.
Jeder interne Fehler nach dem Write stellt den vollständigen Disable- Prestate automatisch wieder her. Race, Drift, Replay oder unvollständige Original-Receipts blockieren vor der Mutation.

Ein Sperrmarker ist an den HMAC-Fingerprint gebunden. Wird ein Credential bei gleicher ID rotiert, gilt der alte Marker als stale und sperrt den neuen Wert nicht versehentlich.

Runtime-Konfiguration¶

Variable	Zweck
`LANSTYLE_STATIC_MCP_TOKEN_ADMIN_HMAC_KEY`	ausschließlich serverseitiger HMAC-Key
feste root-only Datei `mcp-static-token-admin/hmac.key`	Fallback, falls die Environment-Variable nicht gesetzt ist
`LANSTYLE_STATIC_MCP_TOKEN_ADMIN_DIR`	gemeinsamer Status- und Receipt-Pfad
`LANSTYLE_STATIC_MCP_TOKEN_ADMIN_AUDIT`	secretfreies JSONL-Audit

Ein per Environment injizierter HMAC-Key gehört in Vaultwarden. Alternativ erzeugt der enge Bootstrap-Provider den Key ausschließlich serverseitig in der festen root-only Datei, die über das vorhandene Controlled-Execution-Volume in beiden Runtime-Prozessen sichtbar ist. Ohne HMAC-Key ist die Admin-API not_ready. Existiert bereits ein Statusstore, aber der Key fehlt, behandelt der Remote-MCP statische Credentials fail-closed. Der Statusstore ist zusätzlich an eine nicht-sensitive HMAC-Key-ID gebunden. Ein abweichender Key blockiert Inventar und alle statischen Credentials, statt vorhandene Deaktivierungen still aufzuheben. Eine HMAC-Key-Rotation benötigt daher einen eigenen migrierenden Change.

Abnahme vor Deployment¶

synthetische Unit-Tests für Ambiguität, Revision-Race, Replay, Scope-Manipulation, RBAC und Secretfreiheit ausführen;
Statusvolume muss für Tools API und Remote-MCP identisch gemountet sein;
HMAC-Key-Attest nur als set/not set, nie als Wert oder einfacher Hash;
zuerst neues Credential E2E verifizieren;
alten Eintrag exakt per ID, Name und Fingerprint auswählen;
nach Deaktivierung neuen Zugang erneut erfolgreich und alten Zugang mit erwarteter Auth-Ablehnung prüfen.

Die lokale Implementierung verändert ohne separaten Deployment-Change keine produktiven Prozesse oder Credential-Stores.