在之前的三篇文章中，我们分析了当前的安全威胁态势，实施了可靠的身份验证和授权机制，并探索了关键的日志记录与运行时安全防护措施，以此为构建安全的模型上下文协议（MCP）生态系统奠定了基础。上述内容主要围绕访问权限管控与交互行为监控展开。本文将聚焦这类系统所处的物理及虚拟环境。
当然，以安全为中心的开发仅仅是安全防护工作的一部分。即使代码本身足够可靠，若部署的 MCP 服务器安全防护薄弱，也会让所有努力付诸东流。近期发生的“NeighborJack”攻击事件便是佐证：部分服务器因绑定至不安全的网络接口、对外公开且未经身份验证，最终遭到恶意利用。随着行业逐步迈向高度自主的代理式 AI 阶段，部署环境的安全防护工作也变得愈发重要。
本文将介绍如何运用红帽技术（主要为容器化与红帽 OpenShift）搭建“安全优先”的部署架构，该架构采用非根容器、只读文件系统及严格的网络策略，为生产环境中的 MCP 服务器提供更有效的安全防护。
保护您的基础架构
代码可靠固然重要，但 MCP 服务器的整体安全水平，归根结底取决于其所处环境。红帽建议将 MCP 服务器部署在容器中，依托容器自带的隔离能力与内核级安全特性强化防护。与 OpenShift 集成后，还可直接使用平台内置的高级安全默认设置，大幅强化部署环境。要实现真正“安全优先”的 MCP 部署，需围绕以下三大核心要点制定策略：
1.强化运行时环境
为防止攻击者获得立足点，必须在操作系统（OS）层面限制容器的各项操作权限。
- 以非根用户运行：严禁使用根权限运行 MCP 服务器。这样，即使工具因提示注入等方式遭到入侵，攻击者也无法访问宿主机文件或设备接口。
- 启用只读文件系统：将根文件系统设为只读挂载，可防范工具篡改与未经授权的数据驻留。通过规定仅允许向
/tmp等特定目录写入，能有效阻止攻击者篡改服务器行为或植入恶意软件。 - 移除危险的功能：API 调用、文件 I/O 等大多数 MCP 功能，无需高阶内核权限。通过显式移除全部 Linux 功能（例如使用
capDrop: ["ALL"]），可有效防范攻击者利用内核实现权限提升。
2.最大限度缩小攻击面
要缩小潜在威胁的“波及范围”，首先要从容器镜像本身入手。
- 使用尽可能少的基础镜像：采用通用基础镜像（UBI）极简版或无发行版镜像构建服务器。剔除 shell、编译器及各类非必要的实用程序，可避免攻击者在入侵后借助此类工具进行横向渗透。
- 使用红帽 Quay进行自动扫描：在 Quay 中托管镜像，以便进行持续的漏洞扫描。此举可避免 Python 或 Node.js 依赖项将已知常见漏洞和披露（CVE）引入生产环境。
- 内核强化：在 OpenShift 中，需保持 SELinux 处于默认强制模式，并应用 seccomp 配置文件，仅允许服务器执行网络与文件操作所需的必要系统调用。
3.网络隔离和流量控制
最后，必须严格控制 MCP 服务器与基础架构其余部分的通信方式。
- 零信任网络：借助 OpenShift NetworkPolicies，确保只有授权服务（如特定的代理网关）才能访问您的 MCP 服务器。
- 出站流量保护：如果服务器需要调用天气或数据工具等外部 API，需将出站流量限制在指定域名范围内。
- 高级防护：对于高敏感性环境，红帽 OpenShift 服务网格可提供双向传输层安全（mTLS）与单客户端身份验证功能，在应用层 OAuth 的基础上，额外增设一层基于身份的安全防护。
超越基础部署模式，充分运用这些以安全为中心的 OpenShift 原生功能，便可打造弹性基础，保护各类 MCP 工具免受外部威胁与内部漏洞的影响。
结语
部署 MCP 服务器绝非仅让代码正常运行这么简单，而是要构建坚固的安全边界，从容应对 AI 驱动型生态系统下特有的各类风险。正如本文所介绍的，结合使用红帽 OpenShift 与容器化技术，有助于构建必要的安全防护机制：从非根执行到严格的网络策略，全方位避免相关工具引发安全风险。
就像对待源代码那样，以安全至上的严谨态度来对待部署环境。如此一来，才能弥合可用的概念验证方案与富有弹性的生产就绪型服务之间的鸿沟。随着您开发出越来越强大的代理式 AI 系统，坚持遵循这些基础架构最佳实践，将有助于防范当前漏洞和未来各类新型安全威胁。
关于作者
Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.
