Webship-Ingenieurwesen

Sichere Verbindung von KI-Agenten zum Webship’s MCP Server

Richten Sie die isolierte MCP-Steuerebene von Webship mit TLS 1.3, einem starken Trägertoken, Loopback-Bindung, einem SSH-Tunnel, Konfigurationsvalidierung und einer praktischen Checkliste für das Incident-Response ein.

Veröffentlicht 10. September 2026

# Sichere Verbindung von KI-Agenten zum Webship’s MCP Server

Eine MCP Verbindung zu einem Webserver ist kein Chat-Widget. Es ist eine Betriebsoberfläche, die den Produktionszustand überprüfen, Routing- und Sicherheitspolitik ändern, Zertifikate neu laden, statische Releases aktivieren, Flottenänderungen koordinieren und ein signiertes Webship Update installieren kann.

Behandle es entsprechend: als eine privilegierte Verwaltungs-API. Die sicherste Webship Konfiguration hält den MCP Listener vom öffentlichen Datenbereich fern, bindet ihn an Loopback, schützt ihn mit TLS 1.3 und einem starken Bearer-Token und erreicht ihn über einen authentifizierten SSH-Tunnel.

Dieser Leitfaden erstellt diese Einrichtung, erklärt, warum jede Grenze existiert, und gibt Ihnen eine Checkliste, um sie zu betreiben, ohne Bequemlichkeit in Risiko zu verwandeln.

Beginnen Sie mit der Vertrauensgrenze

Der öffentliche Verkehr von Webship und der Verkehr von MCP verwenden separate Listener. Die MCP-Kontrollebene ist standardmäßig deaktiviert und teilt niemals den normalen HTTP-, HTTP/2-, HTTP/3- oder WebTransport-Listener. Wenn aktiviert, dient sie MCP über einen dedizierten TLS 1.3-HTTP/1.1-Endpunkt.

Eine sichere Bereitstellung hat vier unabhängige Kontrollen:

Netzwerkerreichbarkeit: Der MCP-Listener bindet an 127.0.0.1, nicht an eine öffentliche oder private LAN-Adresse.
Transportidentität: Der Client überprüft ein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes Zertifikat.
Anwendungsauthentifizierung: Jede Anfrage trägt ein starkes Bearer-Token.
Administrativer Zugriff: Betreiber erreichen den Loopback-Listener über ein authentifiziertes SSH-Konto und einen Tunnel.

Keine dieser Kontrollen ersetzt eine andere. TLS ohne einen privaten Netzwerkpfad setzt die Authentifizierungsoberfläche weiterhin einem Risiko aus. Ein Tunnel ohne Zertifikatsüberprüfung macht die Endpunktidentität unklar. Ein Bearer-Token in einer für die Welt lesbaren Datei ist kein Geheimnis.

Bereiten Sie das Zertifikat und das Token vor

Stellen Sie ein dediziertes MCP-Zertifikat von Ihrer internen CA aus. Für den unten gezeigten Tunnel fügen Sie localhost und 127.0.0.1 in die alternativen Namen des Zertifikats ein und installieren Sie dann die ausstellende CA im Trust Store der MCP-Clientmaschine. Lösen Sie keinen Vertrauensfehler mit einer unsicheren TLS-Option.

Erstellen Sie ein einzigartiges Token mit mindestens 32 druckbaren ASCII-Bytes und ohne Leerzeichen. Ein 32-Byte-Zufallswert, der als Hexadezimalcode dargestellt wird, ergibt 64 sichere Zeichen:

umask 077
openssl rand -hex 32

Webship liest derzeit das MCP-Token direkt aus der geschützten TOML-Konfiguration; token_file wird nicht unterstützt. Speichern Sie das Ergebnis in einer Konfigurationsdatei, die nur vom Webship-Servicekonto und seiner Administrationsgruppe gelesen werden kann. Legen Sie das Token nicht in einer systemd-Einheit, Shell-Historie, einem Ticket, einer Chatnachricht oder einer Eingabeaufforderung an ein KI-Modell ab.

Auf einem typischen Debian-Host:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

Passen Sie den Dienstbenutzer und die Gruppe an Ihre Installation an. Der private Schlüssel und die Konfiguration müssen für Webship lesbar sein, jedoch nicht für unbeteiligte Konten.

Den isolierten Zuhörer aktivieren

Fügen Sie diesen Abschnitt der aktiven Webship-Konfiguration hinzu:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

Eine leere allowed_ips-Liste öffnet den Endpunkt nicht. Loopback-Clients bleiben standardmäßig erlaubt. expose_remote = false macht die beabsichtigte Grenze explizit: Wenn später jemand listen auf eine Nicht-Loopback-Adresse ändert, lehnt Webship die Konfiguration ab, anstatt die Steuerungsebene stillschweigend zu veröffentlichen.

Webship lehnt auch einen aktivierten MCP-Listener ohne TLS, ohne Token, mit einem kurzen oder Leerzeichen-enthaltenden Token oder mit leeren Zertifikatspfaden ab. Öffentliche Platzhalter-Token werden vor der Remote-Bereitstellung abgelehnt.

Vor dem Neustart überprüfen

MCP Listener, TLS-Identität und Token-Änderungen rekonstruieren die Steuerungsebene, daher erfordern sie einen Neustart des Prozesses. Überprüfen Sie zuerst die vollständige Konfiguration:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

Bestätigen Sie, dass der Listener nur auf Loopback existiert:

ss -ltn | grep '127.0.0.1:9443'

Fügen Sie den Port 9443 nicht zu den öffentlichen Firewall-Regeln des Hosts hinzu. Der nächste Schritt erreicht ihn über SSH.

Erstelle den privaten Tunnel

Von der Administratorarbeitsstation aus leiten Sie einen lokalen Port an den Loopback-Listener von Webship weiter:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

Der MCP-Client verbindet sich jetzt mit https://localhost:19443/mcp. TCP erreicht den SSH-Server, SSH leitet die Verbindung zum Host weiter, und der Host öffnet die endgültige Verbindung zu Webship auf dem Loopback. Das Schließen der SSH-Sitzung entfernt diesen Pfad sofort.

Verwenden Sie schlüsselbasierte SSH-Authentifizierung, beschränken Sie, welche Administratoren den Tunnel öffnen können, und wenden Sie Ihre normalen Zugriffssteuerungen für Hosts an. Wenn ein Jump Host erforderlich ist, halten Sie den MCP-Listener auf der Loopback-Schnittstelle des Webship-Hosts und erweitern Sie den SSH-Pfad, anstatt den Listener zu verbreitern.

Konfigurieren Sie den MCP-Client

Die Formate der Client-Konfiguration unterscheiden sich, aber ein typischer HTTP-MCP-Eintrag sieht folgendermaßen aus:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Verwenden Sie den geschützten Geheimmechanismus des Clients, wenn einer vorhanden ist. Andernfalls beschränken Sie die Client-Konfiguration auf das aktuelle Betriebssystemkonto. Der HTTP-Client—nicht das Modell—sollte den Autorisierungsheader anhängen. Fügen Sie den Live-Token niemals in ein Gespräch ein.

Lassen Sie die Zertifikatsüberprüfung aktiviert. Wenn der Client das Zertifikat ablehnt, reparieren Sie die alternativen Namen des Zertifikats oder installieren Sie die richtige interne CA. Fügen Sie keine dauerhafte Umgehung hinzu.

Machen Sie die erste Sitzung schreibgeschützt

Nachdem der Tunnel und der Client verbunden sind, beginnen Sie mit der Entdeckung und Inspektion:

Fordern Sie tools/list an; seine Antwort ist das autoritative Argumentschema für die laufende Version.
Rufen Sie webship.get_config an und zeichnen Sie die aktuelle Konfigurationsversion auf.
Überprüfen Sie webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status und webship.tls.get_status nach Bedarf.
Verwenden Sie webship.policy.explain oder webship.security.simulate, bevor Sie eine Richtlinie ändern.
Bestätigen Sie, dass die zurückgegebene Konfiguration Bearer-Token schwärzt.

Testen Sie eine Mutation erst dann in einer Nicht-Produktionsumgebung. Die Konfigurationsmutationen von Webship erfordern die aktuelle Versions-ID. Ein veraltetes Schreiben wird abgelehnt, anstatt eine neuere Änderung zu überschreiben. Die Kandidatenrichtlinie kann vor der Aktivierung mit Schattenüberprüfung und Traffic-Lab-Szenarien überprüft werden.

Webship verweigert auch ausgewählte Live-Sicherheitsabwertungen. Eine MCP-Anfrage kann eine aktive WAF, DDoS-Schicht, API-Schutz, Bot-Herausforderung, Edge-Auth-Richtlinie oder Antwort-Header-Schicht nicht deaktivieren. Prozessgebundene Listener-, Protokoll-, Worker-, Laufzeit- und MCP-Authentifizierungsänderungen erfordern einen bewussten Neustart.

Diese Wächter verringern Fehler; sie machen jedoch nicht jede autorisierte Aktion harmlos. Das Token gewährt eine leistungsstarke Steuerungsoberfläche, einschließlich Update- und Freigabeoperationen. Überprüfen Sie vorgeschlagene Tool-Aufrufe genau so, wie Sie den Shell-Befehl eines Administrators überprüfen würden.

Wenn Fernbindung unvermeidbar ist

Loopback plus SSH wird als empfohlenes Design angesehen. Wenn Ihre Umgebung einen Listener für ein privates Netzwerk erfordert, machen Sie die Ausnahme ausdrücklich:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

Behalten Sie den TLS-Block aus dem früheren Beispiel bei, verwenden Sie ein Zertifikat, das mit dem privaten DNS-Namen übereinstimmt, und erzwingen Sie denselben Quellbereich an den Host- und Netzwerk-Firewalls. Verwenden Sie niemals 0.0.0.0/0 oder ::/0 als bequeme Zulassungsliste. Denken Sie daran, dass eine Anwendungs-Zulassungsliste die Quelladresse sieht, die tatsächlich Webship erreicht; überprüfen Sie das Verhalten, wenn ein Load Balancer, NAT-Gateway oder Service-Mesh davor geschaltet ist.

Fernzugriff erhöht den Wert von zentralisierten Zugriffsprotokollen, kurzen Betriebsfenstern und schneller Rotation. Er ist nicht erforderlich, nur weil der MCP-Client auf einem anderen Rechner läuft; genau das löst der SSH-Tunnel.

Bedienen Sie die Steuerungsebene bewusst

Verwenden Sie diese Checkliste für die Produktion:

Halten Sie MCP deaktiviert, wo kein Agent oder Bediener es benötigt.
An die Loopback-Schnittstelle binden und standardmäßig einen SSH-Tunnel verwenden.
Verwenden Sie eine dedizierte TLS-Identität und halten Sie die Zertifikatsüberprüfung aktiviert.
Generiere ein eindeutiges Berechtigungstoken für jede Webship Umgebung.
Schützen Sie die TOML, die Client-Konfiguration, den TLS-Schlüssel und die SSH-Schlüssel mit Dateisystemberechtigungen.
Getrennte Entwicklungs-, Test- und Produktionsanmeldeinformationen.
Starten Sie Sitzungen mit Status- und Policy-Simulationswerkzeugen vor Mutationen.
Bewahren Sie die Sicherheitsprüfungsereignisse von Webship auf und überprüfen Sie sie.
Drehen Sie das Token und starten Sie Webship nach vermuteter Exposition neu.
Schließen Sie Tunnel, wenn die Verwaltungssitzung beendet ist.

Für die Vorfallreaktion schließen Sie aktive Tunnel, beschränken das SSH-Konto, ersetzen das MCP-Token im geschützten TOML, starten Sie Webship neu und überprüfen Sie die neuesten Sicherheitsprüfungs- und Konfigurationsversionsaufzeichnungen. Wenn der TLS-Private-Key möglicherweise offengelegt wurde, stellen Sie ein neues Zertifikat und einen neuen Schlüssel im Rahmen desselben Neustarts aus. Testen Sie anschließend das alte Token und bestätigen Sie, dass es abgelehnt wird.

Eine Steuerungsebene sollte eine Steuerungsebene bleiben

MCP ist nützlich, weil ein Agent den tatsächlichen Zustand prüfen und validierte Änderungen anwenden kann, ohne diese Operationen über den öffentlichen Anforderungspfad zu leiten. Dieser Vorteil entfällt, wenn der Kontroll-Listener zu einem weiteren Internet-Endpunkt wird.

Halten Sie die Grenze einfach: ein separater Listener, Loopback-Erreichbarkeit, überprüftes TLS, eine geschützte Trägeranmeldeinformation, ein authentifizierter Tunnel, versionsgeprüfte Änderungen und ein menschlicher Überprüfungsprozess für leistungsstarke Operationen. Webship stellt das Protokoll und die Sicherheitsvorkehrungen bereit; der Betreiber entscheidet, wer sie erreichen kann.

Dieser Leitfaden basiert auf der Webship 1.3.1 Betreiberdokumentation, den gelieferten Konfigurationsbeispielen, dem MCP Validierungs- und Transportcode, den Laufzeitkonfigurations-Sicherungen und dem Werkzeugkatalog. Überprüfen Sie die aktuelle Webship Dokumentation und die tools/list-Antwort des laufenden Servers, bevor Sie sie auf eine andere Version anwenden.