把runtimeClassName写成某个名字，并不能证明工作负载已经被隔离。还要知道节点运行了哪个后端，以及应用系统调用实际经过了哪里。
应用内核与虚拟化层分清楚
gVisor实现应用内核，在应用和宿主之间增加隔离层。它与运行独立来宾内核的microVM有不同架构和兼容性取舍，不能都称为“物理级微内核”。官方安全模型也明确了硬件侧信道等限制。
基础配置仍然需要最小能力、只读根文件系统和资源控制。把运行时名字换掉，却保留宿主目录、管理员身份或过宽网络，问题不会自动消失。
10月23日OpenAI公开的分层隔离思路可以作为设计参考，不能拿它的部署描述替自己的集群作保证。以下只检查期望配置中几项显式字段。
应用、gVisor与宿主内核是三层，不把gVisor画成硬件hypervisor。
期望配置不能冒充实际状态
以下是可离线运行的最小示例，使用Python标准库。输入均为教学构造，不连接业务系统。
def baseline(spec): sec = spec.get("security", {}) return ( spec.get("runtime") == "runsc" and sec.get("readOnlyRoot") is True and sec.get("allowPrivilegeEscalation") is False and sec.get("capabilities") == [] and spec.get("hostMounts") == [] ) p = {"runtime": "runsc", "hostMounts": [], "security": { "readOnlyRoot": True, "allowPrivilegeEscalation": False, "capabilities": [] }} assert baseline(p) assert not baseline(dict(p, runtime="runc")) assert not baseline(dict(p, hostMounts=["/"])) assert not baseline({}) print("4 desired-configuration cases passed; runtime not started")应用、gVisor与宿主内核是三层，不把gVisor画成硬件hypervisor。
这些字段是本文自定义的配置模型，不是可直接交给Kubernetes或OCI的完整规范。检查通过只表示输入满足本文规则。
部署后再取证
读取节点运行时信息，核对挂载、实际能力和网络出口；让授权测试覆盖文件访问、进程资源和异常回收。兼容性问题可能导致应用失败，也可能诱发运维回退，需要记录回退后的边界。
本机没有启动runsc、容器或Kubernetes。未测兼容性、开销和侧信道，不报告攻击面缩减百分比。
参考资料
- OpenAI containment
- gVisor introduction
- gVisor security model
