Webship pang-inhinyeriya

Ligtas na Ikonekta ang mga Ahente ng AI sa Webship’s MCP Server

I-set up ang hiwalay na MCP control plane ni Webship gamit ang TLS 1.3, isang malakas na bearer token, loopback binding, isang SSH tunnel, pagpapatunay ng configuration, at isang praktikal na checklist para sa incident-response.

Ipinag-publish September 10, 2026

# Ligtas na Ikonekta ang mga Ahente ng AI sa Webship’s MCP na Server

Ang isang MCP koneksyon sa isang web server ay hindi isang chat widget. Ito ay isang interface ng operasyon na maaaring suriin ang estado ng produksyon, baguhin ang ruta at patakaran sa seguridad, i-reload ang mga sertipiko, i-activate ang mga static na release, i-coordinate ang mga pagbabago sa fleet, at mag-install ng isang pinirmahang Webship update.

Tratuhin ito nang naaayon: bilang isang pribilehiyadong administratibong API. Ang pinakaligtas na Webship na setup ay pinananatiling naka-off ang MCP listener mula sa pampublikong data plane, ina-attach ito sa loopback, pinoprotektahan ito gamit ang TLS 1.3 at isang malakas na bearer token, at naaabot ito sa pamamagitan ng isang na-authenticate na SSH tunnel.

Ang gabay na ito ay bumubuo ng setup na iyon, ipinaliwanag kung bakit umiiral ang bawat hangganan, at nagbibigay sa iyo ng checklist para patakbuhin ito nang hindi nagiging sanhi ng panganib ang kaginhawaan.

Magsimula sa hangganan ng tiwala

Ang pampublikong trapiko ng Webship at trapiko ng MCP ay gumagamit ng hiwalay na mga tagapakinig. Ang control plane ng MCP ay hindi pinapagana bilang default at hindi kailanman nagbabahagi ng normal na HTTP, HTTP/2, HTTP/3, o WebTransport na tagapakinig. Kapag pinagana, naghahatid ito ng MCP sa isang nakalaang TLS 1.3 HTTP/1.1 na endpoint.

Ang isang ligtas na pagpapatupad ay may apat na independiyenteng kontrol:

Pag-abot ng network: ang MCP na tagapakinig ay nakakabit sa 127.0.0.1, hindi sa pampubliko o pribadong-LAN na address.
Pagkakakilanlan sa transportasyon: sinusuri ng kliyente ang isang sertipiko na inilabas ng isang CA na pinagkakatiwalaan nito.
Pagpapatunay ng aplikasyon: bawat kahilingan ay may dalang isang malakas na bearer token.
Pang-administratibong access: naaabot ng mga operator ang loopback listener sa pamamagitan ng isang na-authenticate na SSH account at tunnel.

Wala sa mga kontrol na ito ang pumapalit sa isa pa. Ang TLS na walang pribadong network path ay patuloy na nagpapakita ng isang authentication surface. Ang isang tunnel na walang certificate verification ay ginagawang malabo ang pagkakakilanlan ng endpoint. Ang isang bearer token sa loob ng isang world-readable na file ay hindi isang lihim.

Ihanda ang sertipiko at token

Mag-isyu ng nakalaang MCP sertipiko mula sa iyong internal CA. Para sa tunnel na ipinapakita sa ibaba, isama ang localhost at 127.0.0.1 sa subject alternative names ng sertipiko, pagkatapos ay i-install ang issuing CA sa trust store ng MCP client machine. Huwag lutasin ang error sa pagtitiwala gamit ang insecure-TLS na opsyon.

Gumawa ng natatanging token na may hindi bababa sa 32 printable ASCII bytes at walang puwang. Ang isang 32-byte na random na halaga na naka-encode bilang hexadecimal ay nagbibigay sa iyo ng 64 na ligtas na karakter:

umask 077
openssl rand -hex 32

Webship kasalukuyang binabasa ang MCP token nang direkta mula sa protektadong TOML na konfigurasyon; ang token_file ay hindi sinusuportahan. I-imbak ang resulta sa isang configuration file na mababasa lamang ng Webship service account at ng grupo ng mga administrador nito. Huwag ilagay ang token sa isang systemd unit, shell history, ticket, mensahe sa chat, o prompt na ipinadala sa isang AI na modelo.

Sa isang karaniwang host na Debian:

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

Iakma ang gumagamit ng serbisyo at grupo sa iyong pag-install. Ang pribadong susi at pagsasaayos ay dapat mabasa ng Webship, ngunit hindi ng mga hindi kaugnay na account.

Paganahin ang nakahiwalay na tagapakinig

Idagdag ang seksyong ito sa aktibong Webship na configuration:

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

Ang isang walang laman na allowed_ips listahan ay hindi nagbubukas ng endpoint. Ang mga loopback client ay nananatiling pinapayagan bilang default. Ginagawa ng expose_remote = false na malinaw ang nais na hangganan: kung sakaling baguhin ng isang tao ang listen sa isang non-loopback na address, tinatanggihan ng Webship ang konfigurasyon sa halip na tahimik na ilathala ang control plane.

Webship ay tumatanggi rin sa isang pinagana na MCP na tagapakinig na walang TLS, walang token, may maikling token o token na may whitespace, o may walang laman na mga path ng sertipiko. Ang mga pampublikong placeholder na token ay tinatanggihan bago ang malayuang pagpapakita.

Suriin bago mag-restart

MCP listener, TLS identity, at pagbabago ng token ay muling binubuo ang control plane, kaya kailangan nilang i-restart ang proseso. I-validate muna ang kumpletong configuration:

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

Kumpirmahin na ang tagapakinig ay umiiral lamang sa loopback:

ss -ltn | grep '127.0.0.1:9443'

Huwag idagdag ang port 9443 sa pampublikong firewall ng host. Ang susunod na hakbang ay maaabot ito sa pamamagitan ng SSH.

Gumawa ng pribadong lagusan

Mula sa administrator workstation, i-forward ang lokal na port sa loopback listener ng Webship:

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

Ang MCP na kliyente ngayon ay kumokonekta sa https://localhost:19443/mcp. Naabot ng TCP ang SSH server, dinadala ng SSH ang koneksyon sa host, at binubuksan ng host ang panghuling koneksyon sa Webship sa loopback. Ang pagsasara ng SSH session ay agad na nag-aalis ng landas na iyon.

Gumamit ng key-based SSH authentication, limitahan kung aling mga administrator ang maaaring magbukas ng tunnel, at ilapat ang iyong normal na host-access controls. Kung kinakailangan ang jump host, panatilihin ang MCP listener sa loopback interface ng Webship host at palawakin ang SSH path sa halip na palawakin ang listener.

I-configure ang MCP na kliyente

Magkakaiba ang mga format ng configuration ng kliyente, ngunit ang isang tipikal na entry ng HTTP MCP ay ganito:

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

Gamitin ang protektadong mekanismo ng lihim ng kliyente kapag mayroon ito. Kung wala, limitahan ang pagsasaayos ng kliyente sa kasalukuyang account ng operating system. Ang HTTP client—hindi ang modelo—ang dapat maglagay ng authorization header. Huwag kailanman i-paste ang live token sa isang pag-uusap.

Panatilihing naka-enable ang beripikasyon ng sertipiko. Kung tinanggihan ng kliyente ang sertipiko, ayusin ang subject alternative names ng sertipiko o i-install ang tamang internal CA. Huwag magdagdag ng permanenteng bypass.

Gawing read-only ang unang sesyon

Pagkatapos na mag-connect ang tunnel at kliyente, simulan ang pagtuklas at inspeksyon:

Humingi ng tools/list; ang sagot nito ay ang pangunahing balangkas ng argumento para sa kasalukuyang inilabas na bersyon.
Tawagan ang webship.get_config at i-record ang kasalukuyang bersyon ng configuration.
Suriin ang webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status, at webship.tls.get_status kung naaangkop.
Gamitin ang webship.policy.explain o webship.security.simulate bago baguhin ang isang patakaran.
Kumpirmahin na ang ibinalik na configuration ay nagtatanggal ng mga bearer token.

Doon lamang subukan ang isang mutasyon sa isang non-production na kapaligiran. Nangangailangan ang mga configuration mutation ng Webship ng kasalukuyang bersyon ID. Ang lumang pagsusulat ay tinatanggihan sa halip na palitan ang mas bagong pagbabago. Maaaring suriin ang candidate na polisiya gamit ang shadow verification at traffic-lab na mga senaryo bago paganahin.

Webship ay tumatanggi rin sa napiling live na pagbawas ng seguridad. Ang isang MCP na kahilingan ay hindi maaaring patayin ang isang aktibong WAF, DDoS layer, API Shield, bot challenge, edge-auth policy, o response-header layer. Ang mga pagbabago sa process-bound listener, protocol, worker, runtime, at MCP-authentication ay nangangailangan ng sinasadyang pag-restart.

Pinapaliit ng mga guwardiya na iyon ang mga pagkakamali; hindi nila ginagawang walang kapabayaan ang bawat awtorisadong aksyon. Nagbibigay ang token ng makapangyarihang kontrol na saklaw, kasama na ang mga operasyon ng pag-update at pagpapalabas. Suriin ang mga iminungkahing tawag sa tool nang eksakto gaya ng pagsusuri mo sa shell command ng isang administrador.

Kung hindi maiiwasan ang malayuang pagkakabit

Ang Loopback kasama ang SSH ang inirerekomendang disenyo. Kung ang iyong kapaligiran ay nangangailangan ng listener para sa pribadong network, gawin ang pagbubukod na malinaw:

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

Panatilihin ang TLS block mula sa naunang halimbawa, gumamit ng sertipiko na tumutugma sa pribadong pangalan ng DNS, at ipatupad ang parehong saklaw ng pinagmulan sa host at network firewall. Huwag kailanman gamitin ang 0.0.0.0/0 o ::/0 bilang madaling allowlist. Tandaan na ang isang application allowlist ay nakikita ang address ng pinagmulan na talagang nakarating sa Webship; tiyakin ang pag-uugali kapag may load balancer, NAT gateway, o service mesh sa harap nito.

Pinapataas ng malayuang exposure ang halaga ng naka-centralize na access logs, maikling operational windows, at mabilis na rotation. Hindi ito kinakailangan dahil lamang tumatakbo ang MCP client sa ibang makina; iyon mismo ang nilulutas ng SSH tunnel.

Patakbuhin ang control plane nang sinasadya

Gamitin ang checklist na ito para sa produksyon:

Panatilihing naka-disable ang MCP kung wala itong kinakailangan ng ahente o operator.
I-bind sa loopback at gamitin ang SSH tunnel bilang default.
Gumamit ng dedikadong TLS na pagkakakilanlan at panatilihing naka-enable ang beripikasyon ng sertipiko.
Gumawa ng natatanging bearer token para sa bawat Webship na kapaligiran.
Protektahan ang TOML, configuration ng kliyente, TLS key, at SSH keys gamit ang mga pahintulot sa filesystem.
Paghiwalayin ang mga kredensyal para sa pag-unlad, pagsubok, at produksyon.
Simulan ang mga sesyon gamit ang mga tool sa status at policy-simulation bago ang mga pagbabago.
Itaguyod at suriin ang mga kaganapan sa pag-audit ng seguridad ng Webship.
Iikot ang token at i-restart ang Webship matapos ang pinaghihinalaang pagkakalantad.
Isara ang mga tunel kapag natapos ang sesyon ng administratibo.

Para sa pagtugon sa insidente, isara ang mga aktibong tunnel, limitahan ang account ng SSH, palitan ang MCP token sa protektadong TOML, i-restart ang Webship, at suriin ang mga kamakailang tala ng seguridad at bersyon ng konfigurasyon. Kung maaaring na-expose ang TLS private key, mag-isyu ng bagong sertipiko at key bilang bahagi ng parehong restart. Subukan ang lumang token pagkatapos at tiyaking ito ay tinanggihan.

Ang control plane ay dapat manatiling isang control plane

Kapaki-pakinabang ang MCP dahil maaaring inspeksyunin ng isang ahente ang totoong estado at ipatupad ang mga napatunayang pagbabago nang hindi dumadaan ang mga operasyon na iyon sa pampublikong daan ng kahilingan. Nawawala ang bentahang iyon kung ang control listener ay maging isa pang endpoint sa internet.

Panatilihing simple ang hangganan: isang hiwalay na tagapakinig, abot ng loopback, napatunayang TLS, isang protektadong kredensyal ng bearer, isang na-authenticate na tunnel, mga pagbabagong sinuri ang bersyon, at isang proseso ng pagsusuri ng tao para sa makapangyarihang operasyon. Ang Webship ay nagbibigay ng protocol at mga panangga sa kaligtasan; ang operator ang magpapasya kung sino ang maaaring maabot ang mga ito.

Ang gabay na ito ay nakabatay sa Webship 1.3.1 dokumentasyon ng operator, mga halimbawa ng naka-ship na konfigurasyon, MCP validation at transport code, mga guards sa runtime configuration, at katalogo ng tool. Suriin ang kasalukuyang Webship dokumentasyon at ang tumatakbong tools/list response ng server bago ito ilapat sa ibang release.