#运行时隔离与网络控制

Agent Sandbox 管理工作负载生命周期；它不能替代 Kubernetes 授权、网络隔离、Pod 安全、镜像治理或运行时安全边界。对于任何执行不受信任代码或动态生成代码的工作负载，都应采用纵深防御。

#纵深防御

安全部署会在多个层面组合使用控制措施：

没有任何单一层级可以替代其他层级。

#Pod 安全基线

除非经过审查的工作负载有已记录的例外情况，否则请使用与 restricted 兼容的 Pod 和容器安全上下文：

spec:
  podTemplate:
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: worker
          image: example.registry/approved/sandbox-runtime:1.0.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

避免使用特权容器、host networking、hostPath、host device 挂载，以及不必要的 Linux capability。在业务命名空间中应用 ResourceQuota 和 LimitRange，以防止某个租户耗尽共享集群资源。

#RBAC 和 ServiceAccount

默认情况下，Sandbox 工作负载不应获得 Kubernetes API 凭证。除非工作负载有明确的 API 需求，否则请设置 automountServiceAccountToken: false。

当需要 API 访问时：

1. 在业务命名空间中创建专用的 ServiceAccount。
2. 仅授予应用所需的资源名称和动词。
3. 优先使用命名空间级 Role 和 RoleBinding，而不是集群范围权限。
4. 将平台管理员访问与工作负载访问分离。
5. 不要注入平台管理令牌、cluster-admin 凭证或无关的长期有效 secret。

业务用户通常需要访问 Sandbox 资源，并在需要时具有对受管 Pod 和 pods/exec 的读取访问权限。用户不需要编辑 CRD、controller Deployment、ClusterRoles 或其他命名空间中的资源的权限。

#NetworkPolicy 顺序

默认拒绝策略会立即阻断 DNS、所需的内部 API、遥测、sidecar 或业务端点。请按以下顺序应用网络控制：

1. 通过 podTemplate.metadata.labels 为 Sandbox 工作负载添加标签。
2. 为 DNS 和显式批准的目的地定义允许规则。
3. 应用允许策略。
4. 从测试 Sandbox 验证 DNS 和所需端点的连通性。
5. 应用或收紧默认拒绝策略。
6. 再次验证连通性，并在行为与清单不一致时检查 CNI 策略事件。

对于未托管模板，业务命名空间负责 NetworkPolicy 的生命周期。不要使用不受限制的 0.0.0.0/0 出站规则来代替识别所需的业务目的地。除非工作负载有已批准的需求，否则应避免访问云元数据服务和内部网络范围。

NetworkPolicy 的强制执行取决于集群 CNI。一个成功被接受的 Kubernetes 对象并不意味着所选 CNI 会强制执行每一条请求的规则。

#选择 RuntimeClass

列出集群管理员已安装的 RuntimeClass：

kubectl get runtimeclass

在 Sandbox Pod 模板中选择现有运行时：

spec:
  podTemplate:
    spec:
      runtimeClassName: kata-qemu

kata-qemu 仅为示例名称。请使用目标集群中配置的准确 RuntimeClass。如果 RuntimeClass 不存在，或者其节点不可用，Pod 将保持未调度状态。

一种实用的基于风险的策略是：

• 对于低风险、受信任的内部任务，如果集群安全基线已足够，则使用标准 runtime。
• 如果已安装、经过验证且适合该工作负载，则使用 gVisor 或其他 sandboxed runtime。
• 对于更高风险或不受信任的执行场景，在可用 VM-backed 隔离和兼容节点时使用 Kata Containers。

Agent Sandbox 不会安装或运维这些 runtime。

#Kata Containers 边界

使用 Kata Containers 时，工作负载运行在带有 guest kernel 的轻量级虚拟机中。与共享宿主机内核的标准容器相比，这会在工作负载与节点之间增加 guest VM 和 hypervisor 边界。

Kata 非常适合更高风险的任务，例如用户提交的代码、LLM 生成的代码、浏览器自动化、外部文件处理以及多租户工具执行。其实际隔离强度取决于节点虚拟化、hypervisor、Kata 配置和版本、设备暴露、存储挂载、网络以及凭证注入。

warm pool 可以降低 Kata-backed 工作负载的启动延迟。warm pool 是性能机制，不是安全边界。

#Agent Sandbox 不会替代什么

Agent Sandbox 和 Kata Containers 不能替代以下能力：

• Kubernetes 身份验证和最小权限授权。
• Pod Security 和 admission 控制。
• NetworkPolicy 和 CNI 强制执行。
• 镜像签名、provenance、版本固定和漏洞管理。
• secret 最小化和轮换。
• ResourceQuota、LimitRange、调度治理和审计。
• 对用户输入、上传文件、工具和外部目的地进行应用层验证。

请将 controller 和平台路由组件视为受信任的控制平面服务。除非应用具有更强且经过验证的信任模型，否则应将 Sandbox 工作负载视为不受信任。