Webship teknik

Anslut AI-agenter säkert till Webship’s MCP-server

Ställ in Webship’s isolerade MCP-kontrollplan med TLS 1.3, en stark bärare-token, loopback-bindning, en SSH-tunnel, konfigurationsvalidering och en praktisk checklista för incidenthantering.

Publicerad 10 september 2026

# Anslut AI-agenter säkert till Webship’s MCP-server

En MCP-anslutning till en webbserver är inte en chattwidget. Det är ett operativt gränssnitt som kan inspektera produktionsstatus, ändra routing- och säkerhetspolicy, ladda om certifikat, aktivera statiska utgåvor, samordna flottaändringar och installera en signerad Webship-uppdatering.

Behandla det därefter: som ett privilegierat administrativt API. Den säkraste Webship-konfigurationen håller MCP-lyssnaren avkopplad från det offentliga datalagret, binder den till loopback, skyddar den med TLS 1.3 och en stark bärartoken, och når den genom en autentiserad SSH-tunnel.

Denna guide bygger upp den uppsättningen, förklarar varför varje gräns finns, och ger dig en checklista för att använda den utan att förvandla bekvämlighet till risk.

Börja med förtroendegränsen

Den offentliga trafiken för Webship och trafiken för MCP använder separata lyssnare. MCP kontrollplanet är som standard inaktiverat och delar aldrig den vanliga HTTP-, HTTP/2-, HTTP/3- eller WebTransport-lyssnaren. När det är aktiverat, tjänar det MCP över en dedikerad TLS 1.3 HTTP/1.1-endpoint.

En säker driftsättning har fyra oberoende kontroller:

Nätverksåtkomst: MCP-lyssnaren binder till 127.0.0.1, inte en offentlig eller privat LAN-adress.
Transportidentitet: klienten verifierar ett certifikat utfärdat av en CA som den litar på.
Applikationsautentisering: varje begäran har en stark bärare-token.
Administrativ åtkomst: operatörer når loopback-lyssnaren genom ett autentiserat SSH-konto och tunnel.

Ingen av dessa kontroller ersätter en annan. TLS utan en privat nätverksväg exponerar fortfarande en autentiseringsyta. En tunnel utan certifikatverifiering gör slutpunktens identitet otydlig. En bärare-token i en fil som är läsbar för världen är inte en hemlighet.

Förbered certifikatet och token

Utfärda ett dedikerat MCP-certifikat från din interna CA. För tunneln som visas nedan, inkludera localhost och 127.0.0.1 i certifikatets alternativa namn för ämnet, och installera sedan den utfärdande CA:n i MCP-klientmaskinens betrodda lagringsplats. Lös inte ett förtroendefel med ett osäkert TLS-alternativ.

Skapa en unik token med minst 32 utskrivbara ASCII-byte och utan blanksteg. Ett 32-byte slumpvärde kodat som hexadecimal ger dig 64 säkra tecken:

umask 077
openssl rand -hex 32

Webship läser för närvarande MCP-token direkt från den skyddade TOML-konfigurationen; token_file stöds inte. Spara resultatet i en konfigurationsfil som endast kan läsas av Webship-tjänstekontot och dess administrativa grupp. Placera inte token i en systemd-enhet, skalhistorik, ärende, chattmeddelande eller prompt som skickas till en AI-modell.

På en typisk Debian-värd:

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

Anpassa serviceanvändaren och gruppen till din installation. Den privata nyckeln och konfigurationen måste vara läsbar av Webship, men inte av obehöriga konton.

Aktivera den isolerade lyssnaren

Lägg till denna sektion i den aktiva Webship-konfigurationen:

[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"

En tom allowed_ips-lista öppnar inte slutpunkten. Loopback-klienter förblir tillåtna som standard. expose_remote = false gör den avsedda gränsen tydlig: om någon senare ändrar listen till en icke-loopback-adress, avvisar Webship konfigurationen istället för att tyst publicera kontrollplanet.

Webship avvisar också en aktiverad MCP-lyssnare utan TLS, utan en token, med en kort token eller en token som innehåller blanksteg, eller med tomma certifikatvägar. Offentliga platshållartoken avvisas före fjärrexponering.

Verifiera innan omstart

MCP lyssnare, TLS-identitet och tokenändringar bygger om kontrollplanet, så de kräver en omstart av processen. Validera hela konfigurationen först:

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

Bekräfta att lyssnaren endast finns på loopback:

ss -ltn | grep '127.0.0.1:9443'

Lägg inte till port 9443 i värdens offentliga brandväggsregler. Nästa steg når den via SSH.

Skapa den privata tunneln

Från administratörens arbetsstation, vidarebefordra en lokal port till Webship’s loopback-lyssnare:

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

Klienten MCP ansluter nu till https://localhost:19443/mcp. TCP når SSH-servern, SSH för över anslutningen till värden, och värden öppnar den slutliga anslutningen till Webship på loopback. Att stänga SSH-sessionen tar bort den vägen omedelbart.

Använd nyckelbaserad SSH-autentisering, begränsa vilka administratörer som kan öppna tunneln och tillämpa dina vanliga åtkomstkontroller för värdar. Om en hopphost krävs, behåll MCP-lyssnaren på Webship-värdens loopback-gränssnitt och förläng SSH-vägen istället för att vidga lyssnaren.

Konfigurera MCP-klienten

Klientkonfigurationsformat skiljer sig åt, men en typisk HTTP MCP-post ser ut så här:

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

Använd klientens skyddade sekretessmekanism när den har en. Annars, begränsa klientkonfigurationen till det nuvarande operativsystemkontot. HTTP-klienten—inte modellen—ska bifoga auktoriseringshuvudet. Klistra aldrig in den aktiva token i en konversation.

Håll certifikatverifiering aktiverad. Om klienten avvisar certifikatet, reparera certifikatets alternativa namn eller installera rätt intern CA. Lägg inte till en permanent omgåelse.

Gör den första sessionen skrivskyddad

Efter att tunneln och klienten är anslutna, börja med upptäckt och inspektion:

Be om tools/list; dess svar är det auktoritativa argumentschemat för den aktuella versionen.
Ring webship.get_config och spela in den aktuella konfigurationsversionen.
Inspektera webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status och webship.tls.get_status enligt tillämplighet.
Använd webship.policy.explain eller webship.security.simulate innan du ändrar en policy.
Bekräfta att den returnerade konfigurationen maskerar bärare-token.

Endast då testa en mutation i en icke-produktionsmiljö. Webship’s konfigurationsmutationer kräver det aktuella versions-ID:t. En föråldrad skrivning avvisas istället för att skriva över en nyare ändring. Kandidatpolicy kan kontrolleras med skuggverifiering och traffic-lab-scenarier innan aktivering.

Webship vägrar också valda nedgraderingar av live-säkerhet. En MCP-förfrågan kan inte stänga av en aktiv WAF, DDoS-lager, API Shield, bot-utmaning, edge-auth-policy eller lager för svarshuvuden. Processbundna lyssnare, protokoll, arbetare, runtime och MCP-autentiseringsändringar kräver en medveten omstart.

Dessa vakter minskar misstag; de gör inte varje auktoriserad åtgärd ofarlig. Token ger en kraftfull kontrollyta, inklusive uppdaterings- och släppoperationer. Granska föreslagna verktygsanrop precis som du skulle granska en administratörs shell-kommando.

Om fjärrbindning är oundviklig

Loopback plus SSH är den rekommenderade designen. Om din miljö kräver en privat nätverkslyssnare, gör undantaget explicit:

[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"

Behåll TLS-blocket från det tidigare exemplet, använd ett certifikat som matchar det privata DNS-namnet och upprätthåll samma källområde vid värd- och nätverksbrandväggar. Använd aldrig 0.0.0.0/0 eller ::/0 som en praktisk tillåt-lista. Kom ihåg att en applikations-tillåt-lista ser källadressen som faktiskt når Webship; verifiera beteendet när en lastbalanserare, NAT-gateway eller servicemesh ligger framför den.

Fjärråtkomst ökar värdet av centraliserade åtkomstloggar, korta driftfönster och snabb rotation. Det krävs inte enbart för att MCP-klienten körs på en annan maskin; det är precis vad SSH-tunneln löser.

Manövrera styrplanet med avsikt

Använd denna checklista för produktion:

Håll MCP inaktiverat där ingen agent eller operatör behöver det.
Bind till loopback och använd en SSH-tunnel som standard.
Använd en dedikerad TLS-identitet och håll certifikatverifiering aktiverad.
Generera en unik bärare-token för varje Webship-miljö.
Skydda TOML, klientkonfiguration, TLS-nyckel och SSH-nycklar med filsystemets behörigheter.
Separata inloggningsuppgifter för utveckling, testning och produktion.
Starta sessioner med status- och policy-simuleringsverktyg innan mutationer.
Bevara och granska Webship's säkerhetsgranskningsevenemang.
Rotera token och starta om Webship efter misstänkt exponering.
Stäng tunnlar när den administrativa sessionen avslutas.

För incidenthantering, stäng aktiva tunnlar, begränsa SSH-kontot, ersätt MCP-token i den skyddade TOML, starta om Webship och granska de senaste säkerhetsrevisionerna och konfigurationsversionsposter. Om TLS-privatnyckeln kan ha blivit exponerad, utfärda ett nytt certifikat och nyckel som en del av samma omstart. Testa den gamla token efteråt och bekräfta att den avvisas.

Ett kontrollplan bör förbli ett kontrollplan

MCP är användbart eftersom en agent kan granska det verkliga tillståndet och tillämpa validerade ändringar utan att dirigera dessa operationer genom den offentliga förfrågningsvägen. Den fördelen försvinner om kontrolllisten blir en annan internethändelsepunkt.

Håll gränsen enkel: en separat lyssnare, loopback-åtkomst, verifierad TLS, en skyddad bärareautentisering, en autentiserad tunnel, versionskontrollerade ändringar och en mänsklig granskningsprocess för kraftfulla operationer. Webship tillhandahåller protokollet och säkerhetsskydden; operatören bestämmer vem som kan nå dem.

Denna guide baseras på Webship 1.3.1-operatördokumentationen, levererade konfigurationsexempel, MCP-validerings- och transportkod, runtime-konfigurationsskydd och verktygskatalog. Granska den aktuella Webship dokumentationen och den körande serverns tools/list-svar innan du tillämpar den på en annan version.