Geheimnisverwaltung

OpenClaw unterstützt additive SecretRefs, sodass unterstützte Anmeldedaten nicht im Klartext in der Konfiguration gespeichert werden müssen.

Laufzeitmodell

• Secrets werden während der Aktivierung vorab in einen In-Memory-Laufzeit-Snapshot aufgelöst, nicht verzögert in Anfragepfaden.
• Beim Kaltstart des Gateways wird ein wiederholbarer SecretRef-Fehler auf einen bekannten Eigentümer außerhalb des Gateways beschränkt, sofern dieser Eigentümer Isolation unterstützt. Zu den zugeordneten Eigentümerklassen gehören Modell-Provider und Skills, Medien-/TTS-/Cron-Provider, geeignete Authentifizierungsprofile, agentenspezifischer Speicher, Sandbox-SSH, Kanalkonten und im Manifest deklarierte Plugin-Routen. Das Gateway startet, kennzeichnet den Eigentümer als konfiguriert, aber nicht verfügbar, und gibt eine bereinigte Warnung zur eingeschränkten Funktion aus. Gateway-Eingangsauthentifizierung, strukturell ungültige Referenzen oder aufgelöste Werte, ausfallsicher geschlossene Eigentümer und Referenzen, deren Laufzeiteigentümer nicht zugeordnet ist, verhindern weiterhin den Start.
• Beim Neuladen wird jeder zugeordnete Eigentümer unabhängig validiert und anschließend ein einzelner atomarer Snapshot veröffentlicht. Funktionierende Eigentümer werden aktualisiert. Ein geeigneter fehlgeschlagener Eigentümer behält seinen letzten als funktionierend bekannten Wert und wird nur dann veraltet, wenn seine Referenzidentitäten, Providerdefinitionen und sein vollständiger, nicht geheimer Eigentümervertrag unverändert sind; ein geänderter oder neuer fehlgeschlagener Eigentümer wird kalt. Ein strikter Fehler lehnt das Neuladen ab und bewahrt den aktiven Snapshot.
• Richtlinienverstöße (beispielsweise ein Authentifizierungsprofil im OAuth-Modus in Kombination mit einer SecretRef-Eingabe) lassen die Aktivierung vor dem Austausch der Laufzeit fehlschlagen.
• Laufzeitanfragen lesen ausschließlich den aktiven In-Memory-Snapshot. SecretRef-Anmeldedaten von Modell-Providern werden bis zur ausgehenden Übertragung als prozesslokale Sentinel-Werte durch den Authentifizierungsspeicher und die Stream-Optionen weitergegeben. Ausgehende Zustellungspfade (Discord-Antwort-/Thread-Zustellung, Telegram-Aktionssendungen) lesen ebenfalls diesen Snapshot und lösen Referenzen nicht bei jedem Sendevorgang erneut auf.

Dadurch wirken sich Ausfälle von Secret-Providern nicht auf häufig durchlaufene Anfragepfade aus.

Gateway-Eingangsschutz, strukturell ungültige Konfigurationen oder aufgelöste Werte, Richtlinienverstöße und unbekannte Eigentümerschaft werden weiterhin ausfallsicher geschlossen. Isolierte Eigentümer greifen niemals auf eine Anmeldedatenquelle mit niedrigerer Priorität zurück.

Injektion beim ausgehenden Datenverkehr (Sentinel-Werte)

Für durch SecretRefs gesicherte Anmeldedaten von Modell-Providern erzeugt OpenClaw während der Auflösung der Modellauthentifizierung einen undurchsichtigen, prozesslokalen Sentinel-Wert. Authentifizierungsspeicher, Stream-Optionen, SDK-Konfiguration, Protokolle, Fehlerobjekte und die meisten Laufzeitprüfungen sehen daher einen Wert wie oc-sent-v1-... statt der Provider-Anmeldedaten. Der geschützte Modellabruf und die verwalteten Zustandsprüfungen lokaler Provider ersetzen bekannte Sentinel-Werte in URL- und Header-Werten unmittelbar bevor die jeweilige Anfrage den Prozess verlässt.

Unbekannte Werte im Sentinel-Format werden vor jeglicher Netzwerkaktivität ausfallsicher abgelehnt. OpenClaw verweigert das Senden der Anfrage, statt einen nicht aufgelösten Sentinel-Wert an einen Provider weiterzuleiten. Aufgelöste Secret-Werte werden als zusätzliche Schutzmaßnahme außerdem für die Protokollbereinigung bei exakter Wertübereinstimmung registriert.

Provider-Adapter verwenden den spätesten von ihrem SDK unterstützten Injektionspunkt:

• SDKs mit einer benutzerdefinierten Abrufoption erhalten den geschützten Abruf von OpenClaw, sodass das SDK den Sentinel-Wert beibehält.
• SDKs ohne benutzerdefinierte Abrufoption entpacken den Sentinel-Wert unmittelbar vor der Client-Erstellung. Plugin-eigene Provider-Streams und Agent-Harnesses entpacken ihn bei der letzten vom Kern kontrollierten Übergabe, da diese Transporte nicht den geschützten Abruf von OpenClaw verwenden.

Sentinel-Werte verringern die Klartextexposition entlang der Modellaufrufkette, stellen jedoch keine Prozessisolation dar. Der tatsächliche Wert ist weiterhin im Speicher desselben Prozesses vorhanden und erscheint an der abschließenden Adaptergrenze. Klartext-Anmeldedaten aus der Umgebung, die nicht über SecretRefs konfiguriert sind, bleiben Klartext und fallen nicht unter diesen Mechanismus.

Setzen Sie OPENCLAW_SECRET_SENTINELS=off (akzeptiert außerdem 0 oder false, ohne Beachtung der Groß-/Kleinschreibung), um die Erzeugung von Sentinel-Werten während der Reaktion auf Sicherheitsvorfälle oder bei der Kompatibilitätsfehlerbehebung zu deaktivieren. Der Notausschalter deaktiviert nicht die Registrierung der Bereinigung bei exakter Wertübereinstimmung.

Agentenzugriffsgrenze

SecretRefs verhindern, dass Anmeldedaten in Konfigurationsdateien und generierten Modelldateien gespeichert werden, stellen jedoch keine Prozessisolationsgrenze dar. Auf dem Datenträger verbliebene Klartext-Anmeldedaten in einem für den Agenten lesbaren Pfad können weiterhin über Datei- oder Shell-Werkzeuge gelesen werden, wodurch die Bereinigung auf API-Ebene umgangen wird.

Bei Produktionsbereitstellungen, bei denen für den Agenten zugängliche Dateien berücksichtigt werden müssen, gilt die Migration erst als abgeschlossen, wenn alle folgenden Bedingungen erfüllt sind:

• Unterstützte Anmeldedaten verwenden SecretRefs statt Klartextwerten.
• Veraltete Klartextreste wurden aus openclaw.json, auth-profiles.json, .env und generierten models.json-Dateien entfernt.
• openclaw secrets audit --check ist nach der Migration frei von Befunden.
• Alle verbleibenden nicht unterstützten oder rotierenden Anmeldedaten werden durch Betriebssystemisolation, Containerisolation oder einen externen Anmeldedaten-Proxy geschützt.

Aus diesem Grund ist der Arbeitsablauf für Prüfung, Konfiguration und Anwendung ein Sicherheitsmigrations-Gate und nicht lediglich ein Hilfsmittel zur Vereinfachung.

Filterung aktiver Oberflächen

SecretRefs werden nur auf tatsächlich aktiven Oberflächen validiert:

• Aktivierte Oberflächen: Wiederholbare Fehler bei zugeordneten, isolierbaren Eigentümern führen zu einer kalten oder veralteten Einschränkung. Strikte, ausfallsicher geschlossene, für das Gateway erforderliche oder nicht zugeordnete Fehler blockieren den Start beziehungsweise das Neuladen.
• Inaktive Oberflächen: Nicht aufgelöste Referenzen blockieren weder den Start noch das Neuladen; sie geben eine nicht schwerwiegende SECRETS_REF_IGNORED_INACTIVE_SURFACE-Diagnose aus.

Diagnose der Gateway-Authentifizierungsoberfläche

Wenn für gateway.auth.token, gateway.auth.password, gateway.remote.token oder gateway.remote.password eine SecretRef festgelegt ist, protokolliert der Start beziehungsweise das Neuladen des Gateways den Oberflächenstatus unter dem Code SECRETS_GATEWAY_AUTH_SURFACE:

• active: Die SecretRef ist Teil der wirksamen Authentifizierungsoberfläche und muss aufgelöst werden.
• inactive: Eine andere Authentifizierungsoberfläche hat Vorrang oder die Remote-Authentifizierung ist deaktiviert beziehungsweise nicht aktiv.

Der Protokolleintrag enthält den von der Richtlinie für aktive Oberflächen verwendeten Grund.

Vorabprüfung der Onboarding-Referenz

Beim interaktiven Onboarding wird nach Auswahl der SecretRef-Speicherung vor dem Speichern eine Vorabvalidierung ausgeführt:

• Umgebungsreferenzen: Validieren den Namen der Umgebungsvariable und bestätigen, dass während der Einrichtung ein nicht leerer Wert sichtbar ist.
• Provider-Referenzen (file oder exec): Validieren die Provider-Auswahl, lösen id auf und prüfen den Typ des aufgelösten Werts.
• Schnellstartablauf: Wenn gateway.auth.token bereits eine SecretRef ist, löst das Onboarding sie vor dem Start der Prüfung beziehungsweise des Dashboards (für env-, file- und exec-Referenzen) mit demselben sofort abbrechenden Gate auf.

Bei einem Validierungsfehler wird der Fehler angezeigt und Sie können den Vorgang erneut versuchen.

SecretRef-Vertrag

Überall dieselbe Objektstruktur:

{ source: "env" | "file" | "exec", provider: "default", id: "..." }

{ source: "env", provider: "default", id: "OPENAI_API_KEY" }

"${OPENAI_API_KEY}""$OPENAI_API_KEY"

{ source: "file", provider: "filemain", id: "/providers/openai/apiKey" }

{ source: "exec", provider: "vault", id: "providers/openai/apiKey#value" }

Provider-Konfiguration

Definieren Sie Provider unter secrets.providers:

{  secrets: {    providers: {      default: { source: "env" },      filemain: {        source: "file",        path: "~/.openclaw/secrets.json",        mode: "json", // oder "singleValue"      },      vault: {        source: "exec",        command: "/usr/local/bin/openclaw-vault-resolver",        args: ["--profile", "prod"],        passEnv: ["PATH", "VAULT_ADDR"],        jsonOnly: true,      },      "team-secrets": {        source: "exec",        pluginIntegration: {          pluginId: "acme-secrets",          integrationId: "secret-store",        },      },    },    defaults: {      env: "default",      file: "filemain",      exec: "vault",    },  },}

{ "protocolVersion": 1, "provider": "vault", "ids": ["providers/openai/apiKey"] }

{ "protocolVersion": 1, "values": { "providers/openai/apiKey": "<openai-api-key>" } } // Pragma: Geheimnis auf Positivliste zulassen

{"protocolVersion": 1,"values": {},"errors": { "providers/openai/apiKey": { "code": "NOT_FOUND" } }}

Dateibasierte API-Schlüssel

Fügen Sie keine file:...-Zeichenfolgen in den env-Block der Konfiguration ein. Dieser Block ist literal und kann nicht überschrieben werden, daher wird file:... dort nie aufgelöst.

Verwenden Sie stattdessen eine Datei-SecretRef in einem unterstützten Zugangsdatenfeld:

{  secrets: {    providers: {      xai_key_file: {        source: "file",        path: "~/.openclaw/secrets/xai-api-key.txt",        mode: "singleValue",      },    },  },  models: {    providers: {      xai: {        apiKey: { source: "file", provider: "xai_key_file", id: "value" },      },    },  },}

Für mode: "singleValue" lautet die SecretRef id "value". Verwenden Sie für mode: "json" einen absoluten JSON-Zeiger wie "/providers/xai/apiKey".

Unter SecretRef-Zugangsdatenoberfläche finden Sie die Felder, die SecretRefs akzeptieren.

Beispiele für Exec-Integrationen

Eine eigene 1Password-Anleitung zu Dienstkonten, dem mitgelieferten Agent-Skill und zur Fehlerbehebung finden Sie unter 1Password.

{  secrets: {    providers: {      onepassword_openai: {        source: "exec",        command: "/opt/homebrew/bin/op",        allowSymlinkCommand: true, // erforderlich für über Symlinks verknüpfte Homebrew-Binärdateien        trustedDirs: ["/opt/homebrew"],        args: ["read", "op://Personal/OpenClaw QA API Key/password"],        passEnv: ["HOME"],        jsonOnly: false,      },    },  },  models: {    providers: {      openai: {        baseUrl: "https://api.openai.com/v1",        models: [{ id: "gpt-5", name: "gpt-5" }],        apiKey: { source: "exec", provider: "onepassword_openai", id: "value" },      },    },  },}

{  secrets: {    providers: {      bws: {        source: "exec",        command: "/usr/local/bin/openclaw-bws-resolver.mjs",        passEnv: ["BWS_ACCESS_TOKEN", "BWS_SERVER_URL", "PATH", "BWS_BIN"],        jsonOnly: true,      },    },  },  models: {    providers: {      openai: {        baseUrl: "https://api.openai.com/v1",        models: [{ id: "gpt-5", name: "gpt-5" }],        apiKey: {          source: "exec",          provider: "bws",          id: "openclaw/providers/openai/apiKey",        },      },    },  },}

openclaw secrets audit --allow-exec

{  secrets: {    providers: {      vault_openai: {        source: "exec",        command: "/opt/homebrew/bin/vault",        allowSymlinkCommand: true, // erforderlich für über Symlinks verknüpfte Homebrew-Binärdateien        trustedDirs: ["/opt/homebrew"],        args: ["kv", "get", "-field=OPENAI_API_KEY", "secret/openclaw"],        passEnv: ["VAULT_ADDR", "VAULT_TOKEN"],        jsonOnly: false,      },    },  },  models: {    providers: {      openai: {        baseUrl: "https://api.openai.com/v1",        models: [{ id: "gpt-5", name: "gpt-5" }],        apiKey: { source: "exec", provider: "vault_openai", id: "value" },      },    },  },}

#!/usr/bin/env nodeconst { spawnSync } = require("node:child_process"); let stdin = "";process.stdin.setEncoding("utf8");process.stdin.on("data", (chunk) => {  stdin += chunk;});process.stdin.on("error", (err) => {  process.stderr.write(`${err.message}\n`);  process.exit(1);});process.stdin.on("end", () => {  let request;  try {    request = JSON.parse(stdin || "{}");  } catch (err) {    process.stderr.write(`Anfrage konnte nicht analysiert werden: ${err.message}\n`);    process.exit(1);  }   const passBin = process.env.PASS_BIN || "pass";  const values = {};  const errors = {};   for (const id of request.ids ?? []) {    const result = spawnSync(passBin, ["show", id], { encoding: "utf8" });    if (result.status === 0) {      values[id] = result.stdout.split(/\r?\n/, 1)[0] ?? "";    } else {      errors[id] = { message: (result.stderr || `pass wurde mit ${result.status} beendet`).trim() };    }  }   process.stdout.write(JSON.stringify({ protocolVersion: 1, values, errors }));});

{  secrets: {    providers: {      pass_store: {        source: "exec",        command: "/usr/local/bin/openclaw-pass-resolver",        passEnv: ["PATH", "HOME", "GNUPGHOME", "GPG_TTY", "PASSWORD_STORE_DIR", "PASS_BIN"],        jsonOnly: true,      },    },  },  models: {    providers: {      openai: {        baseUrl: "https://api.openai.com/v1",        models: [{ id: "gpt-5", name: "gpt-5" }],        apiKey: {          source: "exec",          provider: "pass_store",          id: "openclaw/providers/openai/apiKey",        },      },    },  },}

openclaw secrets audit --checkopenclaw secrets audit --allow-exec

{  secrets: {    providers: {      sops_openai: {        source: "exec",        command: "/opt/homebrew/bin/sops",        allowSymlinkCommand: true, // erforderlich für über Symlinks verknüpfte Homebrew-Binärdateien        trustedDirs: ["/opt/homebrew"],        args: ["-d", "--extract", '["providers"]["openai"]["apiKey"]', "/path/to/secrets.enc.json"],        passEnv: ["SOPS_AGE_KEY_FILE"],        jsonOnly: false,      },    },  },  models: {    providers: {      openai: {        baseUrl: "https://api.openai.com/v1",        models: [{ id: "gpt-5", name: "gpt-5" }],        apiKey: { source: "exec", provider: "sops_openai", id: "value" },      },    },  },}

Umgebungsvariablen des MCP-Servers

Über plugins.entries.acpx.config.mcpServers konfigurierte Umgebungsvariablen des MCP-Servers akzeptieren SecretInput, sodass API-Schlüssel und Token nicht im Klartext in der Konfiguration stehen:

{  plugins: {    entries: {      acpx: {        enabled: true,        config: {          mcpServers: {            github: {              command: "npx",              args: ["-y", "@modelcontextprotocol/server-github"],              env: {                GITHUB_PERSONAL_ACCESS_TOKEN: {                  source: "env",                  provider: "default",                  id: "MCP_GITHUB_PAT",                },              },            },          },        },      },    },  },}

Klartext-Zeichenfolgenwerte funktionieren weiterhin. Umgebungsvariablen-Vorlagenreferenzen wie ${MCP_SERVER_API_KEY} und SecretRef-Objekte werden während der Gateway-Aktivierung aufgelöst, bevor der MCP-Serverprozess gestartet wird. Wie bei anderen SecretRef-Oberflächen blockieren nicht aufgelöste Referenzen die Aktivierung nur, wenn das Plugin acpx tatsächlich aktiv ist.

SSH-Authentifizierungsmaterial für die Sandbox

Das zentrale ssh-Sandbox-Backend unterstützt außerdem SecretRefs für SSH-Authentifizierungsmaterial:

{  agents: {    defaults: {      sandbox: {        mode: "all",        backend: "ssh",        ssh: {          target: "user@gateway-host:22",          identityData: { source: "env", provider: "default", id: "SSH_IDENTITY" },          certificateData: { source: "env", provider: "default", id: "SSH_CERTIFICATE" },          knownHostsData: { source: "env", provider: "default", id: "SSH_KNOWN_HOSTS" },        },      },    },  },}

Laufzeitverhalten:

• OpenClaw löst diese Referenzen während der Sandbox-Aktivierung auf, nicht verzögert bei jedem SSH-Aufruf.
• Aufgelöste Werte werden mit restriktiven Dateiberechtigungen (0o600) in ein temporäres Verzeichnis geschrieben und in der generierten SSH-Konfiguration verwendet.
• Wenn das effektive Sandbox-Backend nicht ssh ist (oder der Sandbox-Modus off ist), bleiben diese Referenzen inaktiv und blockieren den Start nicht.

Unterstützte Anmeldedatenoberfläche

Die kanonisch unterstützten und nicht unterstützten Anmeldedaten sind unter SecretRef-Anmeldedatenoberfläche aufgeführt.

Erforderliches Verhalten und Rangfolge

• Feld ohne Referenz: unverändert.
• Feld mit Referenz: während der Aktivierung auf aktiven Oberflächen erforderlich.
• Wenn sowohl Klartext als auch eine Referenz vorhanden sind, hat die Referenz auf unterstützten Rangfolgepfaden Vorrang.
• Der Schwärzungs-Sentinel __OPENCLAW_REDACTED__ ist für die interne Konfigurationsschwärzung/-wiederherstellung reserviert und wird als wörtlich übermittelte Konfigurationsangabe abgelehnt.

Warn- und Auditsignale:

• SECRETS_REF_OVERRIDES_PLAINTEXT (Laufzeitwarnung)
• REF_SHADOWED (Auditfund, wenn auth-profiles.json-Anmeldedaten Vorrang vor openclaw.json-Referenzen haben)

Google Chat serviceAccount akzeptiert Inline-JSON oder eine SecretRef. Doctor verschiebt das außer Betrieb genommene benachbarte Feld serviceAccountRef in dieses kanonische Feld, wenn es nicht gesetzt ist.

Aktivierungsauslöser

Die Geheimnisaktivierung wird ausgeführt bei:

• Start (Vorprüfung plus abschließende Aktivierung)
• Hot-Apply-Pfad beim Neuladen der Konfiguration
• Neustartprüfungspfad beim Neuladen der Konfiguration
• Manuellem Neuladen über secrets.reload
• Vorprüfung des Gateway-RPC zum Schreiben der Konfiguration (config.set / config.apply / config.patch), wobei SecretRefs aktiver Oberflächen innerhalb der übermittelten Konfigurationsnutzlast validiert werden, bevor Änderungen dauerhaft gespeichert werden

Aktivierungsvertrag:

• Bei Erfolg wird der Snapshot atomar ausgetauscht.
• Ein strikter Startfehler bricht den Start des Gateway ab.
• Während eines Kaltstarts kann ein wiederholbarer Auflösungsfehler für einen zugeordneten, isolierbaren Nicht-Gateway-Eigentümer den Snapshot veröffentlichen, wobei genau dieser Eigentümer als konfiguriert-nicht-verfügbar markiert ist. Anfragen an den Eigentümer schlagen mit SECRET_SURFACE_UNAVAILABLE fehl; Eigentümer von Modell-Providern greifen nach dem Fehlschlagen einer expliziten Referenz nicht auf Anmeldedaten aus der Umgebung oder aus Authentifizierungsprofilen zurück.
• Neuladen und Neustartprüfung isolieren geeignete zugeordnete Eigentümer. Unveränderte Referenzidentitäten mit unveränderten Provider-Definitionen und einem unveränderten vollständigen, nicht geheimen Eigentümervertrag behalten ihre exakten letzten als funktionsfähig bekannten Werte als veraltet bei; geänderte oder neu konfigurierte, nicht aufgelöste Referenzen werden nur für diesen Eigentümer kalt veröffentlicht. Ein strikter Fehler beim Neuladen bewahrt den zuvor aktiven Snapshot.
• config.set, config.apply und config.patch akzeptieren syntaktisch gültige, nicht aufgelöste Referenzen für isolierbare Eigentümer und geben einen geschwärzten degradedSecretOwners-Bericht zurück. Gateway-Eingangsauthentifizierung, strukturell ungültige Konfigurationen oder aufgelöste Werte, Richtlinienverstöße und unbekannte Eigentümer werden weiterhin vor einer Änderung auf dem Datenträger abgelehnt.
• Funktionsfähige benachbarte Eigentümer werden normal aufgelöst und veröffentlicht, selbst wenn ein anderer Eigentümer kalt oder veraltet ist.
• Die Bereitstellung eines expliziten kanalspezifischen Tokens pro Aufruf für einen ausgehenden Hilfs-/Tool-Aufruf löst keine SecretRef-Aktivierung aus; Aktivierungspunkte bleiben Start, Neuladen und explizites secrets.reload.

Signale für beeinträchtigten und wiederhergestellten Zustand

Wenn die Aktivierung beim Neuladen nach einem funktionsfähigen Zustand fehlschlägt, wechselt OpenClaw in einen beeinträchtigten Geheimniszustand und gibt einmalige Systemereignisse und Protokollcodes aus:

• SECRETS_RELOADER_DEGRADED
• SECRETS_RELOADER_RECOVERED

Verhalten:

• Beeinträchtigt: Funktionsfähige Eigentümer werden aktualisiert, veraltete Eigentümer behalten den letzten als funktionsfähig bekannten Wert und kalte Eigentümer bleiben nicht verfügbar.
• Wiederhergestellt: Wird nach der nächsten erfolgreichen Aktivierung einmal ausgegeben.
• Wiederholte Fehler im bereits beeinträchtigten Zustand protokollieren Warnungen, geben das Ereignis jedoch nicht erneut aus.
• Ein strikter Startfehler gibt niemals ein Beeinträchtigungsereignis aus, da die Laufzeit nie aktiv wurde. Ein erfolgreicher Start mit kalten Eigentümern protokolliert die Beeinträchtigung des Eigentümers, gibt jedoch kein Ereignis des Neuladers aus.
• Referenzbezogene Start- und Neuladefehler geben für jeden betroffenen Eigentümer eine strukturierte SECRETS_DEGRADED-Warnung aus. Provider-bezogene Ausfälle geben stattdessen eine SECRETS_PROVIDER_DEGRADED-Warnung mit dem Provider und der vollständigen Liste betroffener Eigentümer aus, anstatt den Provider-Fehler für jeden Eigentümer zu wiederholen. Warnungen enthalten einen geschwärzten Grund, den Eigentümerzustand cold oder stale und den Wiederholungshinweis openclaw secrets reload. Sie enthalten niemals aufgelöste Werte oder SecretRef-IDs.
• openclaw doctor führt kalte und veraltete Eigentümer mit ihren betroffenen Konfigurationspfaden, dem geschwärzten Grund und Hinweisen zur Wiederholung auf.

Auflösung in Befehlspfaden

Befehlspfade können über einen Gateway-Snapshot-RPC die unterstützte SecretRef-Auflösung aktivieren. Es gelten zwei allgemeine Verhaltensweisen:

Weitere Hinweise:

• Die Snapshot-Aktualisierung nach einer Geheimnisrotation im Backend wird von openclaw secrets reload verarbeitet.
• Von diesen Befehlspfaden verwendete Gateway-RPC-Methode: secrets.resolve.

Audit- und Konfigurationsablauf

Standardablauf für Betreiber:

openclaw secrets audit --check

openclaw secrets configure --apply

openclaw secrets audit --check

Betrachten Sie die Migration erst als abgeschlossen, wenn das erneute Audit keine Befunde mehr ergibt. Wenn das Audit weiterhin dauerhaft gespeicherte Klartextwerte meldet, besteht das Risiko eines Agentenzugriffs fort, selbst wenn Laufzeit-APIs geschwärzte Werte zurückgeben.

Wenn Sie während configure einen Plan speichern, statt ihn anzuwenden, wenden Sie diesen gespeicherten Plan vor dem erneuten Audit mit openclaw secrets apply --from <plan-path> an.

openclaw secrets apply --from /tmp/openclaw-secrets-plan.jsonopenclaw secrets apply --from /tmp/openclaw-secrets-plan.json --allow-execopenclaw secrets apply --from /tmp/openclaw-secrets-plan.json --dry-runopenclaw secrets apply --from /tmp/openclaw-secrets-plan.json --dry-run --allow-exec

Einseitige Sicherheitsrichtlinie

Sicherheitsmodell:

• Die Vorprüfung muss vor dem Schreibmodus erfolgreich sein.
• Die Laufzeitaktivierung wird vor dem Commit validiert.
• Die Anwendung aktualisiert Dateien durch atomaren Dateiaustausch und versucht bei einem Fehler nach bestem Bemühen eine Wiederherstellung.

Hinweise zur Kompatibilität mit veralteter Authentifizierung

Bei statischen Anmeldedaten hängt die Laufzeit nicht mehr von einer veralteten Klartextspeicherung für die Authentifizierung ab.

• Die Quelle der Laufzeitanmeldedaten ist der aufgelöste speicherinterne Snapshot.
• Veraltete statische api_key-Einträge werden entfernt, wenn sie erkannt werden.
• OAuth-bezogenes Kompatibilitätsverhalten bleibt davon getrennt.

Hinweis zur Web-Benutzeroberfläche

Einige SecretInput-Unions lassen sich im Rohdateneditormodus einfacher konfigurieren als im Formularmodus.

Verwandte Themen

• Authentifizierung - Authentifizierung einrichten
• CLI: Secrets - CLI-Befehle
• Vault SecretRefs - HashiCorp-Vault-Provider einrichten
• Umgebungsvariablen - Priorität von Umgebungsvariablen
• SecretRef-Anmeldedatenoberfläche - Anmeldedatenoberfläche
• Vertrag für den Plan zur Anwendung von Secrets - Details zum Planvertrag
• Sicherheit - Sicherheitskonzept