简介：NIST SP 800-190《应用容器安全指南》中文翻译版由译者独立完成，面向系统和安全管理员、安全程序管理员及应用程序开发人员等具备操作系统、网络和虚拟化基础的读者。文件为单个PDF文档，大小约1.37MB，完整收录原版摘要、致谢、读者对象、目录和全部正文，方便随时查阅。已有519人学习。指南围绕容器技术架构层与组件，详细分析容器逃逸、镜像漏洞、网络隔离等核心安全风险，并给出五条针对性建议：调整组织文化与技术流程、采用容器专用主机操作系统、按敏感性与威胁状态划分容器组、实施容器特定的漏洞管理、在硬件信任根上建立安全链。这些内容兼顾风险成因与落地控制措施，能帮助读者在规划、部署和维护容器环境时形成系统化安全防护思路，有效降低安全事件发生的可能性。
1. 容器安全不能照搬虚拟机那套：800-190 中文版到底能帮你解决什么
我最早翻这份编号 800-190 的英文原版时，最大的冲击来自一句话：容器安全不是虚拟机安全的缩小版。所有容器共享同一个内核，攻击面模型、漏洞形态、修复节奏都和传统虚拟化完全不同。这份指南把容器安全拆成镜像、镜像仓库、编排器、容器、主机操作系统五层，逐层列风险、给对策，正好补上中文社区最缺的「有标准出处、能直接拿去评审」的落地材料。这份中文版适合正在做容器平台规划的安全管理员、要跟业务方讲清楚隔离边的开发，以及想建立容器安全基线又不愿从零编方案的运维。读到最后你会发现，多数容器安全事件不是高科技漏洞，而是组件边界没划清楚。
2. 先啃架构再谈加固：五层模型与共享内核这条主线
2.1 文档结构速览：别从头啃，先读风险和对策两张表
这份指南的骨架很清晰：前两章讲容器是什么、架构怎么分层，中间两章是核心——第3章按组件列风险，第4章给一一对应的对策，第5章是三个完整威胁情景，第6章按生命周期讲落地节奏。很多人拿到手习惯从第1页顺序读到尾，结果读到第4章时前面的概念已经忘得差不多。我建议第一次翻阅时把顺序反过来：先读第3章的风险条目，再读第4章的对策，两章对着看，风险编号和策略编号是一一映射的，这样脑子里能快速建立「什么问题对应什么解法」的框架。等你把这两章吃透了，再回头补第2章的架构概念，就完全不费力。
| 阅读目的 | 对应章节 | 关键内容 |
|---|---|---|
| 了解容器基本概念 | 第2章 | 容器与主机操作系统交互、技术架构、主要用途 |
| 定位安全风险 | 第3章 | 镜像、仓库、编排器、容器、主机五层组件各自风险条目 |
| 获取对应对策 | 第4章 | 与第3章一一对应的缓解措施 |
| 看威胁情景 | 第5章 | 镜像漏洞利用、运行时利用、毒化镜像三个示例 |
| 落地生命周期 | 第6章 | 启动、规划、实施、运行维护、处置五阶段建议 |
这份指南还有一个容易被忽略的特点：它不绑定任何具体容器产品。所有建议都抽象到组件层，这意味着你换平台、换运行时，甚至换编排器，这套框架依然能用。对团队来说，这比在网上搜「某某容器平台安全加固十招」那种碎片文章要可靠得多——前者是给你一套分类学，后者只是给你一堆命令。等你在生产环境里遇到文档没覆盖到的新问题时，这套分类学会告诉你该往哪一层去找原因。
需要提醒的是，这份中文翻译里保留了英文术语的对照，比如「Orchestrator」统一译作「协调器/编排器」，「Image Registry」译作「镜像仓库」。第三、四章读起来会略有重复感，但这是标准文档的特性，宁可啰嗦也不要出现歧义。实际阅读时，我一般会在第3章每个风险条目旁边直接写下对应的检查项，把这份文档当工作底稿用，而不是当教材存着。读一遍有一遍的收获，但真正产生价值的是你把它变成自己环境里的检查单那一刻。
2.2 五层模型的核心逻辑：镜像不变，运行时无常
要理解这份指南，必须先接受它的分层方式：镜像（Image）是静态工件，仓库（Registry）是分发通道，编排器（Orchestrator）是调度大脑，容器是运行实体，主机操作系统（Host OS）是共享底座。这五层有一个共同的底层事实——所有容器共享宿主内核，隔离是逻辑上的，而不是硬件级的。这个区别决定了后续所有对策的设计方向，理解不了这一点，后面看什么建议都会觉得「过度设计」。
虚拟机隔离在 hypervisor 层，每个虚拟机有完整的内核实例，一个虚拟机的内核崩溃不会直接拖垮同宿主上的另一个虚拟机。而容器只是内核上的进程组，一旦某个容器里拿到了内核级代码执行能力，影响范围就是整个宿主内核，同主机上的所有容器都无法幸免。指南反复强调「按目的、敏感度、威胁状态对容器分组」，底层逻辑正是这个：既然共享内核无法避免，那就通过分组把一次失陷的影响半径控制在最小。分组不是物理隔离，而是让攻击者突破一个点之后，不能顺势摸到其他敏感资产。
另一个贯穿全文的思路是「信任根」。对于镜像、仓库、运行时这几层，指南建议把信任建立在一个硬件根上，通过可信平台模块（TPM）度量引导过程，引导链层层验证：固件验证引导器、引导器验证内核、内核验证运行时、运行时验证镜像。这套机制的作用不是防止所有攻击，而是让「运行的是不是我批准的镜像」这个问题从「靠自觉」变成「可度量」。实际部署时不一定每个环境都能上全套信任链，但至少应该在镜像签名和节点身份校验这两个环节把根立住。
镜像层的「不变性」也需要专门理解：镜像构建出来后分层存储、不可修改，漏洞一旦被打进某一层，就会随着镜像分发到所有环境。传统漏洞管理工具假设「服务器上跑着一组长期不变的应用」，这套假设在容器世界里完全失效——容器可以随时被调度到任意节点，镜像也不会像传统系统那样在原地打补丁，正确的做法是重新构建镜像、用新镜像替换旧容器。指南把这套逻辑称为「声明式的逐步构建方法」，落地成日常操作就是：镜像固定版本标签、构建过程可复现、扫描门禁前置。
主机层面的建议也值得单独展开。指南明确推荐使用容器专用主机操作系统而不是通用操作系统，理由很简单：攻击面。通用系统自带一堆服务、驱动、管理工具，任何一个暴露的服务都可能成为入口；容器专用系统裁剪到「只运行容器」这个最小功能集。但这里有个权衡点，指南自己也写了——专用系统依然会有漏洞，补丁流程不能省，极简也不等于绝对安全，只能说不必要的攻击面被关掉了。在这个取舍上，我的经验是先评估业务镜像对内核特性的依赖，再决定是把现有系统做加固裁剪，还是直接上极简专用系统，后者省事但需要提前做兼容验证。
3. 把风险清单变成检查项：镜像、仓库、编排、运行时、主机的可操作对策
3.1 镜像风险：漏洞在你拉取的那份压缩包里，不在主机上
镜像风险是这份指南列出的第一组风险，也是日常工作中最常见的盲区。很多人觉得「主机没问题，容器就安全」，但镜像本身自带漏洞、带配置缺陷、甚至带恶意软件和明文密钥。更要命的是镜像会传播：一个基础镜像里的漏洞，会被下游几十个业务镜像继承。更隐蔽的是配置缺陷——比如镜像里默认用 root 用户运行应用程序，一旦容器被攻破，攻击者直接就是 root 权限，连提权这一步都省了。
针对镜像这一层的对策，我的最小实现是三条：固定基础镜像版本、扫描前置、签名验证。固定版本解决「latest 漂移」问题，确保每次构建的依赖链完全一致；扫描前置把漏洞检查放进 CI 门禁，而不是上线前抽检；签名验证让人能确认镜像确实来自内部构建流程，而不是被中间环节替换过的。下面是一个镜像准入检查脚本的雏形，思路直接来自指南第 4.1 节的对策，可以挂到 CI 里当第一道门：
# 镜像准入检查：只放行满足最小安全条件的镜像 # 用法: image-admission-check <镜像标识> image_ref="$1" # 1. 必须来自内部受信仓库，禁止直接拉取公网镜像 if [[ "$image_ref" != "registry.internal/"* ]]; then echo "拒绝: 镜像不在内部受信仓库中" exit 1 fi # 2. 禁止使用 latest 标签，必须显式指定版本 if [[ "$image_ref" == *":latest" ]]; then echo "拒绝: 禁止使用 latest 标签，必须显式指定版本" exit 1 fi # 3. 高危漏洞数为零才放行 high_count=$(image-scan-tool --ref "$image_ref" --severity HIGH --count-only) if [[ "$high_count" -ne 0 ]]; then echo "拒绝: 高危漏洞数量为 ${high_count}" exit 1 fi echo "准入检查通过"这段脚本的核心逻辑是三个「一道门」：仓库来源门、标签规范门、漏洞数量门。第一条把镜像来源限制在内部仓库，公网镜像必须先拉进内部仓库完成扫描才能继续使用；第二条禁止 latest 是因为它会在重新部署时悄悄变化，导致「昨天验证过、明天就不一样」；第三条是高危漏洞阈值，实际使用可以根据团队风险偏好把--severity调整成 CRITICAL 或 HIGH，也可以加一个排除参数暂时豁免已确认无风险的条目。请注意，image-scan-tool是需要替换成你实际使用的扫描命令，registry.internal换成你们内部仓库地址，扫描器支持的命令行参数以具体工具为准。
提示：脚本里的
image-scan-tool是占位命令，你需要按实际扫描工具调整参数格式；核心逻辑保留三段检查即可。
除了脚本能覆盖的部分，还有两类镜像风险需要人工处理。一类是嵌入的明文机密：构建时把数据库密码、API 密钥写进镜像层，等于把密钥分发给所有能拉取这个镜像的人。正确做法是运行时通过密钥管理系统注入，镜像本身不携带任何机密。另一类是镜像配置缺陷：应用应声明非 root 用户运行，配合容器运行时设置的用户映射一起生效。这份指南里对镜像配置缺陷的表述是「验证并强制遵守镜像的安全配置最佳实践」，落到日常就是定期对镜像做配置基线扫描，把「以 root 运行」「开放了额外能力」这类问题在构建阶段就拦下来，而不是等到运行期再靠监控发现。
3.2 仓库与编排器：认证、授权、网络分段是三个重灾区
镜像仓库承担的是「可信分发」职责，但它常年被高估。指南列出的仓库风险主要有三类：与仓库之间的不安全连接、仓库中堆积无法追溯的陈旧镜像、以及认证授权不足导致任何人拉取或篡改镜像。对策也直接对应：传输链路强制加密、建立镜像清理策略、启用身份认证和基于角色的访问控制。第一类问题的根子在于有些部署为了省事跳过加密，在内部网络里裸跑；第二类问题更隐蔽——几个月前的镜像没人记得是谁构建的、里面有什么漏洞，但它静静躺在仓库里，随时可能被拉起来。
编排器这一层的风险更贴近实际攻击路径。指南点名的几个问题值得逐条对照：管理访问没有限制、未授权访问、容器间网络通信分隔差、混合工作负载敏感度、编排器节点信任。这五个问题的共同点是：攻击者不需要攻破容器，只要拿到编排器的一个普通管理入口，就能实施大规模操纵。下表是我在评审容器平台时默认检查的配置项：
| 风险点 | 推荐配置 | 落地动作 |
|---|---|---|
| 管理面暴露 | 管理端口与业务流量分离，限制来源 | 关闭匿名访问，管理证书定期轮换 |
| 未授权访问 | 启用身份认证和基于角色访问控制 | 按角色最小授权，定期复核账号 |
| 网络分隔差 | 默认拒绝 + 白名单放行 | 每个命名空间下发 default-deny 策略 |
| 混合敏感度 | 按敏感度分组调度 | 节点打标签，调度器约束到指定节点池 |
| 节点信任 | 校验节点身份和度量值 | 节点加入集群时核验硬件信任根 |
容器间网络分隔是实战中最容易翻车的环节。很多平台默认允许所有 Pod 互访，这在指南里属于「容器间网络通信分隔不良」，处理方法是把默认策略改成拒绝，再按业务关系一条条放行。下面这份通用网络策略的写法是「默认拒绝入站」，配合具体放行策略使用：
apiVersion: security/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: app-prod spec: podSelector: {} policyTypes: - Ingress这份策略的语义是：app-prod命名空间下所有 Pod 默认拒绝所有入站流量。podSelector: {}表示选中该命名空间下全部 Pod；policyTypes: ["Ingress"]表示只管理入站方向。日常使用中会先下发这份默认拒绝，再根据业务依赖写几条带来源条件的放行策略，允许指定来源访问指定端口。注意网络策略只在启用了相关网络插件的平台上生效，纯桥接网络的老旧部署需要先补网络层能力才能落实这一条。
工作负载敏感度混跑的问题，指南建议「按目的、敏感度和威胁状态分组」。举个例子：测试环境的低防护容器和生产环境含支付数据的容器共享同一个内核，一旦测试容器被攻破并完成了内核级利用，生产容器的隔离边界就是纸糊的。实操上是给节点打设备标签，在编排器的调度配置里强制敏感工作负载运行在专用节点池，不敏感的普通负载不能共享这些节点。这一步做好了，纵深防御才算真正有了形状。
3.3 运行时与主机：共享内核容器的最后一道防线
容器运行时是攻击面最直接的一层。指南列出的运行时风险包括：运行时软件自身漏洞、容器无限制网络访问、不安全的运行时配置、应用漏洞、以及「流氓容器」——未经批准偷偷跑起来的容器。威胁情景章节里专门写了「利用容器运行时」的场景：攻击者利用运行时的配置缺陷提升权限，进而影响宿主机。所以这一层的对策原则是：默认不信任任何容器，能给的权限全部按最小集给。
运行时的最小加固项，我一般依序检查五件事：是否禁止特权模式、是否按需裁剪能力集、根文件系统是否只读、是否挂载了宿主敏感目录、网络出口是否默认拒绝。特权模式是最常见的高危配置，一旦开了，容器内进程几乎拥有宿主机的全部权限，隔离形同虚设。能力集裁剪要按需给，比如只给网络绑定服务的权限允许绑定低端口，不给设备管理这类危险能力。根文件系统只读能防止容器被攻破后在文件系统层面持久化，需要写入的临时目录单独挂卷。宿主敏感目录挂载，尤其是宿主的管理套接字，一旦容器被攻破就等于直接拿到了宿主控制权。
主机操作系统这一层是共享内核的底座，指南的五条风险全部围绕「攻击面过大」和「共享内核」展开。攻击面过大的解决思路是使用容器专用主机 OS，或者对通用系统做加固裁剪，关掉用不到的服务、禁用不必要的内核模块。共享内核风险没有「一劳永逸」，只有纵深防御：及时打内核补丁、按敏感度分组、限制用户权限、对主机文件系统做完整性监控。指南还专门提到「主机 OS 组件漏洞」——包括内核漏洞、驱动漏洞和系统库漏洞，这些漏洞的修补节奏直接决定容器的安全上限，因为容器自己没有内核，它的安全天花板就是宿主机的补丁水平。
主机文件系统篡改值得单独强调。攻击者拿下一个容器后，如果宿主机的/usr、/etc等目录被挂载进容器，它可以改写系统命令或配置，植入后门，而且非常隐蔽。对策是禁止向容器挂载宿主关键目录、对关键文件做只读挂载、以及用完整性监控工具定期校验。这些动作看似基础，却是这份指南里「深度防御」的最扎实落地。我见过不少团队把重兵压在应用防火墙和入侵检测上，回头一看宿主的/usr/bin直接被挂进容器——那是防线内部直接开了一个门。
4. 避坑记录：把这本指南落地到生产环境常踩的 5 个坑
指南读起来条条在理，落地时才见真章。这一章记的是我在给某跨平台系统做容器安全改造时实际遇到的坑，每条都是先讲现象再讲原因，最后给解决办法。这些都是真金白银换来的经验，比文档里的标准答案多一层烟火气。
4.1 换用容器专用主机 OS 后，业务容器原地崩溃
现象：按指南建议把通用主机 OS 换成极简容器专用系统，测试环境一切正常，生产环境部分容器启动即退出，日志只有一句「无法加载动态库」。排查了半天，发现连基础的域名解析组件都没了，容器里跑的应用直接起不来。
原因：极简系统裁剪了大量运行时组件，业务镜像里依赖的系统库、证书库、时区数据、域名解析组件被一并裁掉了。测试环境规模小、路径简单，没触发这些依赖；生产环境一旦用到真实的外部服务调用，缺失立刻暴露。
解决：先做镜像兼容矩阵验证，用一份覆盖典型业务的镜像清单在目标系统上跑冒烟测试，确认内核模块、动态库、网络解析都正常再切换。业务对系统组件依赖深的，先做加固裁剪的通用系统，不要一上来就切极简系统。我把兼容矩阵做成 CI 里的一个任务，每次换主机系统都要先过这一关。
4.2 镜像扫描「零漏洞」，上线两天被入侵
现象：CI 里镜像扫描全部通过，结果生产环境一个容器被植入挖矿进程。事后排查发现，漏洞不在基础镜像里，而在业务构建过程新增的某个老版本依赖库，扫描器根本没扫到这一层。
原因：扫描器默认只扫了基础镜像层，业务构建过程新增的应用依赖没有纳入扫描范围；同时扫描只查 CVE，没有查配置缺陷——容器以 root 运行，被攻破后直接是最高权限，连提权都省了。
解决：扫描范围扩展为构建产物全链路，不仅基础镜像要扫，应用依赖、二进制文件也要扫；扫描之外叠加配置基线检查，把「root 运行」「多余能力」这类问题在 CI 阶段拦下。这次教训让我把验收标准改成了「扫描零高危 + 配置基线零违规」，两条同时满足才算通过。
4.3 把「按敏感度分组」理解成「不要共享主机」，资源利用率崩了
现象：安全评审要求敏感业务独享主机，所有节点打标隔离，结果几十台节点只跑了少量容器，资源成本直接翻倍，运维负担也上去了。业务方天天来问「为什么机器用了不到一成」。
原因：把「按目的、敏感度、威胁状态分组」理解成了物理隔离。指南的原意是同敏感度的工作负载可以共享内核，用分组缩小攻击影响半径，而不是禁止共享。跨敏感度才需要强调隔离，同敏感度共享内核本来就是容器模型的设计前提。
解决：同敏感度的业务放同一节点池，靠网络策略、能力集裁剪来做纵深防御；只有跨敏感度场景（生产与测试混部、多租户隔离）才需要资源隔离。这个区分想清楚后，资源利用率恢复正常，安全目标也没打折。
4.4 默认网络下容器间互访全开，攻破一个容器就打到了数据库
现象：渗透测试时，攻击者从一台低权限容器横向访问到了同命名空间的数据库容器，数据接口直接暴露。安全团队当时还奇怪「数据库没有暴露公网，怎么被打进来的」。
原因：平台默认的容器网络策略是「允许全部」，指南强调的「容器间网络通信分隔」没有落地。攻击者先打下一个边缘容器，然后顺着全开的网络找到了数据库，整个内网横向移动路径畅通无阻。
解决：在命名空间创建时就下发 default-deny 策略，再按业务调用关系逐条放行端口。网络策略变更走评审流程，每次新业务上线先确认它的访问关系图。这个改造动作做完，横向移动路径被直接切断，渗透测试报告里这类问题再没出现过。
4.5 把传统漏洞扫描器直接指向容器运行时，误报率爆炸
现象：安全团队把原有漏洞扫描器接到运行中的容器上，每天几千条告警，一线人员没人敢处理，最终告警全部被忽略。有一次真实入侵告警混在里面，也没人注意到。
原因：传统工具假设「主机长期运行固定应用集合」，而容器是短生命周期的，扫描器扫到的是某个时间切片，很容易和实际运行的镜像不一致。容器也不像虚拟机那样支持原地打补丁，扫出一堆漏洞没法修，告警就成了纯粹的噪声。
解决：把扫描绑定在镜像上，在构建和拉取两个环节做门禁，而不是扫运行态；运行期只做行为监控和完整性校验，发现问题就重建替换，不尝试原地修补。这其实正是指南反复强调的「采用针对容器的漏洞管理流程」，读到和做到之间隔着一整个告警治理体系。
5. 落地路线与验收基线：从镜像准入到运行期自查的一整套节奏
5.1 按生命周期五阶段落地，每一步都有验收标准
指南第 6 章把容器安全拆成五个阶段：启动、规划、实施、运行维护、处置。这五个阶段不是理论流程，而是可以直接对着做检查的。我按自己的项目经验整理了一张落地对照表，每阶段的验收标准都写成了可执行的结果，不搞虚的：
| 阶段 | 关键动作 | 验收标准 |
|---|---|---|
| 启动 | 定义容器化适用范围、组建安全评审角色 | 明确哪些应用允许容器化、审批人是谁 |
| 规划 | 确定基础镜像来源、仓库、编排器、网络模型 | 安全设计文档评审通过 |
| 实施 | 镜像准入、签名验证、配置基线、最小权限 | CI 门禁生效，违规镜像无法部署 |
| 运行维护 | 漏洞跟踪、运行期监控、补丁节奏 | 告警闭环，高危问题有应急路径 |
| 处置 | 镜像退役、数据清理、日志留存 | 下线清单完整，残留数据清除记录 |
启动阶段最容易犯的错是「没有范围」——什么应用都想容器化，结果安全评审资源被摊薄。我一般会在这个阶段先列出三类清单：能容器化的、暂缓的、绝不容器化的，让评审聚焦在高风险的那一小撮。规划阶段是安全设计的主战场，镜像策略、网络模型、编排器选型三条线要同时定，缺一条后面都要返工。实施阶段重点关注 CI 门禁的完整性，指南强调「验证和强制遵守」，「验证」是扫描，「强制」是让不合格镜像根本无法部署，只扫不拦等于没做。
5.2 一个可抄的「异常容器行为」运维自查片段
运行维护阶段除了看监控告警，还要有主动自查的手段。下面这段脚本逻辑在指南第 4.4 节的思路基础上做了简化，适合做成定时任务，每天跑一遍。它的职责不是实时拦截，而是兜底发现——万一有容器绕过了策略以特权模式跑起来，至少能在当天被揪出来：
# 运行期自查：揪出特权容器和宿主敏感目录挂载 core_list=$(runtime-cli ps -q) for c in $core_list; do # 检查是否以特权模式运行 priv=$(runtime-cli inspect "$c" --format '{{.Privileged}}') if [[ "$priv" == "true" ]]; then echo "告警: 容器 $c 以特权模式运行" fi # 检查是否挂载了宿主敏感目录 mounts=$(runtime-cli inspect "$c" --format '{{range .Mounts}}{{.Source}} {{end}}') if echo "$mounts" | grep -qE '^/(etc|usr|var/run)'; then echo "告警: 容器 $c 挂载了宿主敏感目录: $mounts" fi done这段脚本做两件事：遍历所有运行中容器，检查特权模式和敏感目录挂载。runtime-cli需要替换成你们实际的运行时客户端命令；--format的输出字段也要根据实际版本调整，不同运行时的字段名略有差异，跑之前先手动对单个容器试一次确认字段。脚本更适合做成定时任务而不是实时守护，因为它的作用是「兜底发现」，实时拦截应该交给运行时安全策略去处理，两者分工不同。
注意：挂载检查的正则只覆盖了
/etc、/usr、/var/run三个最常见路径，你们如果有其他敏感目录，按同样格式追加即可。
5.3 运维期自检节奏：周/月/季度各查什么
落实到具体节奏，我按周期分了三档。每周查运行态：特权容器是否为零、高危漏洞镜像是否还有运行实例、异常网络连接到哪些目标。每月查配置态：账号权限复核、证书有效期、仓库里是否有新出现的陈旧镜像、网络策略是否符合当前业务拓扑。每季度查体系：完整跑一遍基线合规审计、演练一次容器逃逸的应急响应流程、复盘最近一次安全事件的处理时长。
这个自检节奏不是拍脑袋定的，它对应的是指南里「运营和维护阶段」的几条核心建议——持续监控、定期验证合规、保持补丁和配置的时效性。周检查是快速止血，月检查是发现趋势，季度检查是验证体系本身有没有失效。团队按这个节奏跑下来，安全问题从「等出事」变成「有节奏地排查」，响应路径清晰很多。特别是季度演练，哪怕只是纸上推演，也能把「谁负责拉停」「谁负责溯源」「谁决定重建」这几个角色提前磨合好。
6. 一张「最小可执行基线卡」：我把五层建议压成一页纸
指南全文读完，真正留在手边用的是一张纸。我把第 3 章、第 4 章每一条风险和对策映射成检查项，最后压缩成五层基线卡，每层三到五条，评审任何容器平台时逐条过，全部通过才算放行。这张卡不替代文档，它是文档的索引——每一条后面都能翻回原文找到依据：
| 层 | 最小基线项 |
|---|---|
| 镜像 | 固定版本标签；仅受信仓库来源；扫描零高危漏洞；非 root 运行；构建产物签名验证 |
| 镜像仓库 | 传输加密；认证与权限最小授权；定期清理陈旧镜像；签名密钥与访问凭证分离管理 |
| 编排器 | 管理面与业务网络隔离；默认拒绝容器间访问；按敏感度分组节点；审计日志完整留存 |
| 容器运行时 | 禁用特权模式；能力集最小化；根文件系统只读；禁止挂载宿主敏感目录；限制出口网络 |
| 主机 OS | 最小化系统安装；内核补丁按节奏更新；管理员账号最小化；文件系统完整性监控 |
这张卡怎么用？我一般把它打印出来贴在评审会议旁边，每个新项目上线前逐条打勾。每一条都有对应指南里的依据章节——镜像层对应第 3.1 和 4.1 节，仓库层对应第 3.2 和 4.2 节，编排层对应第 3.3 和 4.3 节，运行时层对应第 3.4 和 4.4 节，主机层对应第 3.5 和 4.5 节。有人问某一条能不能放宽，直接翻到对应对策段落，让文档说话，比谁嗓门大都管用。如果评审时间紧张，我至少会强制过镜像、网络策略、特权容器这三项，它们是历次事件里翻车率最高的位置。
有一次我因为赶上线进度，跳过了「构建产物签名验证」这一条，觉得内部网络慢、仓库也是自己人搭的，不会有问题。结果团队里有人误传了一个未批准的镜像到内部仓库，测试环境直接跑上了带后门的旧版本。虽然发现得早没造成实际损失，但这张卡上的每一行都是用这类小事故换来的。从那以后我给自己定了个硬规矩：任何容器平台评审，都强制走一遍这张基线卡，一条不能省。希望帮到你。
本文还有配套的精品资源，点击获取
