在 Kubernetes 上托管 MCP Server 时，第三方代码的安全边界直接决定集群安危。Obot 作为完整的 AI 治理平台（AI Governance Platform），在 Helm Chart 中内置了三层工作负载隔离机制：Kubernetes NetworkPolicy 网络策略、Pod Security Admission（PSA）Pod 安全准入，以及可对接gVisor / Kata Containers 沙箱运行时的 RuntimeClass 配置。本文带你用最小配置成本，把 MCP 托管工作负载彻底"关进笼子"。

为什么需要工作负载隔离：MCP 服务器运行着不可信代码

Obot 的架构中，MCP Gateway 将流量代理到两类后端：集群外部的 Remote MCP Servers，以及由 Obot 在 Kubernetes 中自动部署的Hosted MCP Servers（沙箱层）。后者会执行 npx、uvx 或容器镜像中的第三方代码——一旦某个 MCP Server 被入侵或行为异常，它可能：

• 横向扫描集群内网，访问私有 IP 段的其他服务；
• 以特权容器身份逃逸，攻击宿主机内核；
• 将数据外传给任意互联网地址。

Obot 的隔离策略覆盖"网络、准入、运行时"三个维度，且全部默认启用，生产环境基本零配置即可享受纵深防御。下面逐层拆解。

NetworkPolicy 配置：一条策略封死私网访问

Obot 在 MCP 命名空间（默认{helm-release}-mcp）中创建名为mcp-egress-restrictions的 NetworkPolicy，策略源文件见 chart/templates/networkpolicy.yaml。

启用后的安全模型非常直白：

被明确封禁的地址段包括：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16（私有网段）、127.0.0.0/8（回环）、169.254.0.0/16（链路本地，可防云元数据泄露）、224.0.0.0/4（组播）和240.0.0.0/4（保留段）。

一键启用与调整（默认已开启）

相关 Helm 值定义在 chart/values.yaml：

mcpNamespace: networkPolicy: enabled: true # 默认 true，生产环境强烈建议保持 dnsNamespace: kube-system # 若集群 DNS 不在 kube-system 请修改

两点实战提醒（来自 docs/docs/security/isolation.md）：

• 该策略只约束 MCP 命名空间的 Pod，不限制 Obot Server 自身。若要限制 Obot Server 出站，需要由运维方单独针对其依赖（数据库、身份提供商、对象存储）另行制定策略。
• 如果某些 MCP Server 确实需要访问集群内部服务，请追加允许规则，而不是整体关闭策略。

进阶：域名级出站管控

内置 NetworkPolicy 是"IP 段级别"的粗粒度管控。Obot 还提供MCP Server Egress Control（基于 Aviatrix 提供商），支持为每个 MCP Server 配置域名白名单（如api.github.com、*.example.com），仅在 HTTPS/443 放行白名单域名。通过egressDomains字段即可按服务器粒度配置，详见 docs/docs/configuration/mcp-server-egress-control.md。

Pod Security Admission：命名空间级 restricted 策略默认开启

Obot 为 MCP 命名空间自动打上 Pod Security Admission（PSA）标签，默认 enforce 级别为restricted——Kubernetes Pod Security Standards 中最严格的一档。标签由 Helm 模板 chart/templates/mcp.yaml 写入命名空间 metadata：

mcpNamespace: podSecurity: enabled: true # 默认启用 enforce: restricted # 违规直接拒绝创建 Pod audit: restricted # 违规记入审计日志 warn: restricted # 违规返回警告

三个标签各司其职：pod-security.kubernetes.io/enforce阻止违规 Pod 创建；audit只记录不拦截；warn向用户返回警告。完整参数对照（含OBOT_SERVER_MCPPOD_SECURITY_*环境变量）见 docs/docs/configuration/mcp-deployments-in-kubernetes.md。

Obot 内置的 Pod 安全上下文（无需手动配置）

除了命名空间准入，Obot 在生成每个 MCP Server 的 Deployment 时自动写入硬化的 SecurityContext（实现见 pkg/mcp/kubernetes.go）：

Pod 级：

• runAsNonRoot: true，固定runAsUser/runAsGroup/fsGroup: 1000
• seccompProfile.type: RuntimeDefault

容器级：

• allowPrivilegeEscalation: false（禁止提权）
• capabilities.drop: ["ALL"]（丢弃全部 Linux capabilities）
• seccompProfile.type: RuntimeDefault

这些设置保证了所有托管 MCP Pod 天然符合 restricted 标准，也解释了为什么该命名空间默认就能以最高安全级别运行。

沙箱运行时：用 RuntimeClass 再加一道硬件级隔离

容器即使以非 root、无 capabilities 运行，仍与宿主机共享内核。若 MCP Server 可能运行完全不可信的代码，可以引入沙箱运行时：

• gVisor：用户态内核拦截系统调用，大幅收缩暴露给宿主机的攻击面；
• Kata Containers：每个容器跑在轻量虚拟机中，提供硬件级隔离。

最快配置方法：三步接入 RuntimeClass

1. 在节点上安装 gVisor 或 Kata Containers；
2. 在集群中创建对应的 RuntimeClass（如 handler 为runsc的gvisor）；
3. 在 Obot Helm values 中指定：

mcpServerDefaults: runtimeClassName: "gvisor"

也可通过环境变量OBOT_SERVER_MCPK8S_SETTINGS_RUNTIME_CLASS_NAME或在Admin UI 的 Kubernetes 设置页配置（Helm 未设置时 UI 生效）。Obot 会在漂移检测中核对 Deployment 的实际 RuntimeClass 与期望值是否一致（见 pkg/mcp/kubernetes.go），不匹配会触发修正。

⚠️ 实战提示：沙箱运行时存在一定性能开销，且并非所有节点都支持。建议结合.mcpServerDefaults.affinity将 MCP Pod 调度到已安装沙箱运行时的节点，并在生产前实测性能。

隔离配置速查清单

总结：默认即安全，按需加固

Obot 的隔离设计遵循"安全前置"（secure by default）理念：NetworkPolicy 与 PSA restricted 策略开箱即用，Pod 安全上下文自动硬化，沙箱运行时与域名白名单按需叠加。生产部署只需三步——保持默认策略开启、为不可信代码启用 gVisor RuntimeClass、按服务器配置egressDomains白名单——即可为 AI 工作负载构建完整的纵深防御体系。更多架构细节可参考 docs/docs/configuration/mcp-deployments-in-kubernetes.md 与 docs/docs/security/isolation.md。