4.1 虚拟化与容器安全

4.1 虚拟化与容器安全

本节摘要：多租户是云的经济模型，隔离是云的安全底线。本节讲清虚拟化与容器两种隔离模型的强度差异与适用场景，拆解容器安全的真实风险面（镜像、运行时、编排权限），并纠正"容器天生不安全"或"容器等同虚拟机"两种常见误判。

隔离是底座的一切

云的一切安全承诺都建立在一句技术上难以兑现、工程上必须兑现的话上：你的负载与别人的负载互不可见。这句话的兑现方式就是隔离模型。理解隔离，是理解平台域一切控制的起点——隔离模型的强度决定了"最坏情况下，一个租户的失陷会波及谁"。

虚拟机隔离靠管理程序（hypervisor）：每个虚拟机有独立内核，管理程序仲裁硬件访问。攻击者要从一个虚拟机打到另一个，必须先攻破管理程序本身，这类"逃逸"漏洞极少且一出现就被各方重兵修复，是云厂商责任域的重中之重。容器隔离靠的是内核的功能分组：同一台主机上的所有容器共享一个操作系统内核，靠命名空间与控制组把彼此"看起来"隔开。共享内核是容器轻快的代价——内核一旦有漏洞，隔离强度就打折。工程上的补偿方案是：把不可信负载放进轻量虚拟机沙箱里再跑容器（很多平台已内置这个选项）、及时打内核补丁、限制容器内核能力。

两种模型的定位不是替代关系：虚拟机给"强隔离、慢启动、重负载"，容器给"轻快、高密度、短生命周期"，安全设计的任务是按负载的信任级别选隔离强度——把来路不明的用户代码直接跑进特权容器，是底座层面的重大失误。

图 4-1：虚拟机与容器的隔离层次对比

容器安全的三道检查

容器的事故统计显示，真正出事的环节大多不在内核，而在容器周边的三个环节。三道检查依次过。

镜像检查：镜像是容器的出生证明。风险点是来源不明的基础镜像、夹带的恶意依赖、带洞的老版本。对策是"最小底座 + 私有仓库 + 扫描卡点"：用裁剪到只剩运行必需的最小基础镜像，只允许从内部仓库拉取，仓库入口做漏洞扫描与签名校验，扫描不过的镜像进不了部署。镜像里塞密钥是高频低级错误——分层让"删除"形同虚设，历史层里照样翻得出来。

运行时检查：容器跑起来之后的权限要压到最小：不以特权模式运行、根文件系统只读、禁用不必要的内核能力、限制可挂载的路径。这些选项在编排清单里逐项可配，基线化的做法是把约束写进部署模板（与 2.4 的 IaC 基线同一思路），默认安全、例外审批。

编排权限检查：容器编排平台（如通用容器编排系统）本身是一个带 API 的控制面，权限设计直接套用 4.3 的身份治理：按命名空间划分权限边界、服务账号最小化、API 调用留痕。编排平台失控的后果是"一键全灭"——能改编排清单的身份等于能改所有容器的运行方式。

推演变式与常见误区

三个高频误区值得单独拆。误区一："容器逃逸轻而易举，容器不安全"。事实是按信任级别设计的容器环境风险可控，多数真实容器事故是配置错误（特权模式、挂载宿主敏感路径）而非内核级逃逸。误区二："虚拟机天然安全不用管"。虚拟机的操作系统、补丁、开放端口全是客户责任，共享责任模型别背反了。误区三："多租户隔离是厂商的事我不用验证"。厂商负责隔离机制，客户负责按模型的信任边界选用——把高敏负载放进弱隔离档位，责任在选型的人。

给一套可执行的底座清单收尾：主机与节点自动打补丁、容器默认非特权、镜像走私有仓库加扫描卡点、编排平台按命名空间最小授权、不可信负载进沙箱档、底座审计日志外送。这份清单每条都能在自家环境五分钟内核对，本周就可以跑第一遍。

隔离模型的选择推演

选隔离模型不是技术考试，是信任分级练习。把负载按"代码来源"分三类，模型选择基本自动：自家代码、来源可信且经过卡点（5.4 的流水线扫描）——常规容器或虚拟机即可；第三方商业组件、来源可信但不可控其内部缺陷——容器加收紧的运行时配置；完全不可信的用户提交代码（在线判题、数据清洗脚本）——必须进沙箱档：轻量虚拟机包容器、无持久凭证、网络出口白名单。出事故的环境九成是把第三类塞进了第一类的档位。

再给一个组织级的判断标尺：爆炸半径测试。问一句"这台负载失陷后，攻击者能触到什么"，答案如果是"同网段全部资产"，说明无论用什么隔离模型，网络与身份的配套（4.2、4.3）都没跟上；如果答案是"它自己"，隔离设计才算到位。隔离模型决定起点，配套防线决定终点。

一个镜像投毒的推演案例

把镜像检查的必要性演一遍。背景：团队为图方便直接使用某个公开仓库的第三方基础镜像做业务部署。三个月后安全公告披露该镜像的某个历史版本层被植入挖矿脚本，团队发现自己拉的版本恰好命中。

操作：立即隔离使用该镜像的节点；用镜像扫描工具核对历史层的指纹确认污染范围；从可信源头重建基础镜像、走私有仓库重新部署；把"仅允许私有仓库来源"写进部署基线与流水线卡点。结果：影响限于测试环境（业务环境的镜像恰好晚一周拉取），生产逃过一劫，但全流程耗掉团队两天。

解读：这个案例的两个细节值得咀嚼——污染藏在"历史层"里，只扫最终层的浅层扫描工具会漏掉，所以镜像扫描要选能逐层核验的；而真正的修复不是"换掉这个镜像"，是把来源校验变成机器强制的基线。变式：如果团队对基础镜像做了签名校验（只信自己签名过的），投毒版本根本进不了部署——预防的代价远低于响应。

本节要点回顾

• 隔离强度由内核归属决定：虚拟机每户一内核、容器共享内核，没有绝对优劣，只有与负载信任级别的匹配。
• 容器事故九成在周边三环节：镜像来源、运行时权限、编排控制面，逐项基线化即可挡住绝大多数真实攻击。
• 分层让删除形同虚设：密钥与敏感文件写进镜像历史层照样可翻，敏感材料只走注入不走镜像。
• 按代码来源选隔离档位：不可信用户代码必须进沙箱档，出事的环境多半是把不可信负载塞进了常规档。
• 爆炸半径测试是终极标尺：一台负载失陷后能触到什么，答案比任何隔离选型论证都诚实。

考场速答：三道平台域判断

判断一："容器共享内核所以不能用于生产。"错——共享内核的风险可通过沙箱档、非特权运行与补丁节奏压到可控，生产禁止论混淆了风险与风险可控。

判断二："逃逸漏洞由客户负责修补。"错——管理程序属于厂商责任域，客户的责任是按信任级别选档与验证隔离承诺；把两者混答，是场景题里最常见的责任错位。

判断三："编排平台的权限就是运维内部事务。"错——编排平台是带控制面的高权资产，权限设计要套身份治理原则并留痕，能改部署清单的身份约等于能改整个运行环境。

一问一答：两个底座的延伸问题

问：租户隔离需要客户自己做验证吗？ 要，但验证的是"选型与承诺的对齐"而不是重复厂商的隔离测试。客户侧的验证动作是：把高敏负载实际放进规划好的隔离档位，用爆炸半径测试核一遍，并要求厂商提供隔离机制的第三方审计结论——这是共享责任模型的正确分工，不是不信任，是问责留证。

问：无服务器函数还需要担心底座隔离吗？ 担心，但责任已经转移：函数运行环境由平台托管，隔离机制的选档（比如是否默认启用轻量虚拟机沙箱）属于 8.2 尽调要问的问题。客户侧剩下的动作是把不可信输入照样当敌情处理——底座再稳，函数代码里把用户输入拼进命令的老问题照样出事。底座隔离与代码防线是两个互不替代的层次，考题最爱把它们混在一处。

底座立住了，下一节看通道：攻击者拿到一个落脚点之后，网络分段决定他还能走多远。