OpenClaw-Teamserver: Ein Gateway ist eine gemeinsame Vertrauensgrenze

Ein Gateway für eine Vertrauensgruppe

Ein gemeinsamer OpenClaw-Gateway eignet sich nur für Personen, die einander auf Betriebsebene vertrauen dürfen. Rollen verteilen Zuständigkeiten, ersetzen aber keine Vertrauensgrenze.

Operator-Rollen und Session-Eigentum unterstützen die Zusammenarbeit, isolieren jedoch keine gegenseitig unvertrauenswürdigen Nutzer voneinander. Ein Plattformteam kann damit Zugriffe organisieren und Handlungen zuordnen. Eine belastbare Mandantentrennung innerhalb desselben Gateways entsteht dadurch nicht.

Vor der Rollenvergabe steht deshalb die wichtigere Architekturentscheidung: Wer darf dieselbe Betriebsdomäne, Konfiguration und Infrastruktur teilen? Für getrennte oder potenziell gegnerische Gruppen sind separate Gateways, Betriebssystemnutzer oder Hosts die sichere Wahl.

Der Gateway bleibt hinter dem Zugang

Für einen Teamserver kombiniert OpenClaw einen dauerhaft laufenden Gateway mit Cloudflare Tunnel und Access, persönlichen Anmeldungen, GitHub-Identitäten und Operator-Rollen. So kann ein Team gemeinsam arbeiten, ohne den Gateway selbst als öffentlich erreichbaren Dienst zu betreiben.

Der Dienst bleibt an Loopback gebunden; TCP-Port 18789 sollte nicht öffentlich geöffnet werden. Der Cloudflare Tunnel baut die ausgehende Verbindung auf, während Access den vorgeschalteten, authentifizierten Zugang kontrolliert.

Diese Ebenen erfüllen unterschiedliche Aufgaben: Access begrenzt den Einstieg, persönliche Identitäten machen Handlungen zuordenbar, und Rollen strukturieren die Zusammenarbeit innerhalb der zuvor festgelegten Vertrauensgruppe. Keine dieser Schichten verwandelt einen gemeinsam betriebenen Gateway in eine Grenze zwischen misstrauischen Parteien.

Wann ein zweiter Gateway sinnvoll wird

Unterschiedliche Zugangsdaten, Update-Zeitpunkte oder Operatoren sprechen für einen separaten Release- oder Staging-Gateway. Entscheidend ist nicht ein einzelnes Merkmal, sondern die betriebliche Folge: Kann eine Gruppe Konfiguration, Zugangsdaten oder Updates eines anderen Bereichs beeinflussen, obwohl sie das nicht können sollte, ist die gemeinsame Vertrauensgrenze zu weit gezogen.

Der Sollzustand ist eindeutig: Alle Personen innerhalb eines Gateways dürfen dessen gemeinsame Betriebsbasis verantworten. Zeigt die Prüfung stattdessen getrennte Verantwortliche, unabhängige Änderungsfenster oder Zugangsdaten, die voreinander geschützt werden müssen, sollten die Bereiche getrennt betrieben werden. Eine optionale lesende Freigabe aus einem anderen Gateway kann Einblick schaffen, ohne beide Betriebsbereiche zusammenzuführen.

Die Reihenfolge lautet daher: Vertrauensgruppe festlegen, den Gateway hinter einem authentifizierten Zugang betreiben und erst dann Rollen innerhalb dieser Grenze vergeben.