为什么容器镜像会产生安全问题？

在传统的部署方式中，应用依赖于操作系统中的环境。在配置好环境后，应用可以稳定地运行。但是随着技术的发展，传统部署带来的问题越来越严重。因为多个应用对运行环境的不同要求，导致应用部署产生了很多出乎意料的麻烦，在琐碎的环境问题上消耗了许多精力。因此，容器化部署被引进以应对这种情景。容器安装了运行时所需要的环境，并且要求开发人员将他们的应用程序及其所需的依赖关系打包到容器镜像中。 无论其他开发人员和操作系统如何，每个开发人员都可以拥有自己的依赖版本。最终不论是用户还是开发者都在这种部署方案中受益匪浅，开发者可以轻松地在不同环境中测试应用的运行情况，在发布新版本的时候也不必为环境的改变而定制升级教程；用户在使用容器部署时也十分便利，并且不同的软件之间也不会相互影响。

理想情况下，容器镜像应该只包含应用程序的二进制文件及其依赖项。 然而实际上，容器镜像往往是相当巨大的。像Ubuntu、Centos这样被广泛使用的基础系统镜像，它们包含了相当多的无用功能。尽管有些功能在调试部署的时候带来了一定的便利，但是在增大的体积面前，收益极低。容器实际上是不透明的，被封装成一个个繁琐的镜像。

最终，当越来越多的容器被创建时，没有人再确定容器到底装载了什么？实际运行着什么？正是因为如此，我们日常使用的镜像面临严峻的安全问题。随着历年来积累的CVE越来越多，很多应用都存在一些问题，在更新频率低的镜像中尤为严重。

本期的交流总结主要围绕以下10个问题进行展开：

1、如何快速大批量的修复基础镜像中的漏洞？

如基础镜像中存在漏洞，如何快速的修复引用此基础镜像而构建出的镜像的漏洞呢?

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
标准的工作步骤：
1.明确影响范围：通过资产管理软件，或者SCA软件查询哪些镜像引用了此基础镜像；
2.查找修复方法：大部分漏洞的修复方法是将对应组件升级成新的版本；
3.重新构建镜像：结合步骤1和2，通过CI工具构建新版本的镜像，从而修复漏洞；
4.验证兼容性：通过各类测试验证版本兼容性，不要因为替换组件版本影响功能的可用性；

如何做到快速修复呢？我觉得可以考虑以下几个因素：
1）预防为主，保持其精简程度，减少冗余组件带来的不必要安全漏洞；
2）定期更新，更早地发现基础镜像中的漏洞并及时修复，不要堆积太多的漏洞导致无从下手；
3）工具辅助，通过工具提升自动化效率；
4）委托第三方，现在有第三方厂商推出黄金镜像运营服务，为客户持续提供无漏洞的基础镜像，也可以节省客户方的精力；

奔跑的蜗牛 高级软件开发工程师 , 武汉家事易农业科技有限公司
1.信息提取模块，用于在ci/cd流程构建容器镜像后，对所述容器镜像提取软件包版本信息；
2.匹配模块，用于在漏洞数据库中，为所述软件包版本信息匹配漏洞信息与补丁信息；
3.修复模块，用于根据匹配到的漏洞信息与补丁信息，修复所述容器镜像，以便ci/cd流程推送发布所述容器镜像。

北京不眠夜 产品经理 , 公司
目前，没有什么好的方法去批量修复镜像漏洞。基础镜像漏洞只能一个一个去修复，然后利用流水线将应用程序打包到基础镜像上，完成应用镜像的更新。

一般来说基础镜像不会很多，大约有10~20个左右。如果基础镜像过多，建议规范和标准化镜像版本，例如：一个大版本下只提供1~2个小版本的基础镜像，这样便于维护和统一管理。

2、如何构建更为安全的容器镜像？

容器镜像的安全将成为云原生时代的重要安全话题，从底层的基础镜像，到上层各公司封装的基线镜像，再到各应用系统的发布镜像，每一步的来源及构建过程都会影响到容器镜像的安全性，因此，就如何构建安全的容器镜像成为一个重要问题，底层基础镜像主要来源于各操作系统厂商的镜像底座，公司封装的基线镜像也往往是各公司根据其个性化要求在镜像底座上进行的封装，但在应用系统发布镜像构建环节上，往往难以统一，存在很多难以标准化的问题，比如开发引入的各依赖包的安全性如何把控，产品厂商提供的成熟产品镜像如何保证其安全性等，因此提出该如何构建更为安全的容器镜像问题。

嘉宾回复

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
对于自研软件的镜像
1）缩减基线镜像的数量：各应用开发项目组确实会有个性化需求，但不能将基线镜像的选择完全放开。与开发部门沟通的基础上，几十种基线镜像应该能满足大多数情况，版本尽量统一，如果版本不统一则维护的工作量会很大。这个要求可以通过技术规范的方式进行推广。
2）增强基线镜像的安全性：通过精简不必要组件，修复中高危漏洞，使基线镜像本身的安全性得到提升，构筑镜像的安全基底；
3）建立软件成分物料清单：对应问题中的“ 开发引入的各依赖包的安全性 ”，SCA工具可以帮助建立镜像内组件成分的完整台账，一是发现已有漏洞；二是有新漏洞被爆出时也可以迅速定位其影响范围；
4）落实镜像发布前的安全门禁：镜像在发布前，一定要通过镜像漏扫和人工渗透测试进行风险自检与加固；存在中高危漏洞、存在配置风险、敏感信息的镜像统统不允许发布；

对于外采的软件镜像

由于采购方不掌握镜像的构建过程和代码编写过程，通常采购方不会指定供应商使用什么样的基线镜像，或者使用什么样的组件。 所以能控制的点相对少很多。 采购方只能从结果着手，通过镜像漏扫和人工渗透测试来保证镜像的安全，不满足要求的镜像坚决不能部署到生产环境。

上述的控制手段，既需要管理规范层面的落实，也需要安全工具的辅助。

3、如何确保构建的容器镜像满足系统安全要求？

容器的镜像生成以后，需要手动运行安全扫描，来确保生成的容器镜像满足系统安全扫描要求，有没有工具能够自动对新生成的容器镜像进行安全扫描，扫描完后自动发送通知安全扫描的结果？？

嘉宾回复

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
手工扫描，说明您那边已经有容器镜像安全扫描的工具，只是没有自动化触发这个流程。
自动化触发扫描的能力，通常不是扫描工具具备，而是由CI/CD流水线工具作触发，例如常见的Jenkins，或者其他DevOps平台。
只要将镜像扫描编排进流水线中，在生成新镜像后将镜像URL传递给镜像扫描工具，并下达扫描指令，然后再等待结果进行展示。
所以您可能缺少的是一个DevOps平台，一方面编排调度各类工具，一方面对各种工具的输出结果进行统计分析度量。

奔跑的蜗牛 高级软件开发工程师 , 武汉家事易农业科技有限公司
对于容器镜像安全的保证,可以秉承预防为主,防治结合的理念来进行。所谓防,就是要在编写 Dockerfle 的时候,遵循最佳实践来编写安全的 Dockerfile;还要采用安全的方式来构建容器镜像;所谓治,即要使用容器镜像扫描,又要将扫描流程嵌入到 CI/CD 中,如果镜像扫描出漏洞,则应该立即终止 CI/CD Pipeline,并反馈至相关人员,进行修复后重新触发 CI/CD Pipeline。

北京不眠夜 产品经理 , 公司
一般的容器云产品中，流水线会集成开源的扫描工具clair用于扫描镜像漏洞，在使用流水线构建镜像的时候就可以对镜像进行安全扫描。

如果对开源的扫描工具不满意，可以购买专业的容器安全产品，这些安全产品基本都支持在构建中进行镜像安全扫描。

4、容器应用镜像制作模版规范？

容器应用镜像制作模版规范应该是怎么样的？
如何让开发人员根据模版规范制作出满足最佳实践的应用镜像。

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
通常而言，镜像的构成包括两部分，一是基础镜像，一是在基础镜像之上进行的各种文件和指令操作。如果想要制作出满足最佳实践的应用镜像，应选取精简的没有安全漏洞（或者尽可能少漏洞）的基础镜像，也要保证Dockerfile的内容遵守制定好的编写规范。
在有了模板文件编写规范后，应通过管理手段和技术手段来确保规范的落实。其中技术手段包括但不限于利用DevOps研发平台内嵌规范，通过自动化来减少开发人员的工作量，减少推行规范过程中遇到的摩擦。也可以通过质量门禁来限制未遵守规范的镜像流转到后续环节。

附一个机翻的dockerfile文件检查规范，仅供参考。各企业应基于自身实践建立对应规范。

奔跑的蜗牛 高级软件开发工程师 , 武汉家事易农业科技有限公司
镜像制作类似于虚拟机的镜像（模版）制作，即按照公司的实际业务需求将需要安装的软件、相关配置等基础环境配置完成，然后将其做成镜像，最后再批量从镜像批量生成容器实例，这样可以极大的简化相同环境的部署工作。

5、云原生架构下东西流量的管控方式？

云原生架构下，资源（pod）生命周期相对传统主机要变化快的多，如何有效和高效的解决此场景下的访问控制问题？

嘉宾回复

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
访问控制有两个层面，一是网络层的可达，一个pod能ping通另一个pod属于这个层面。另一层面是应用层，一个pod能调用另一个pod的API属于这个层面。从安全角度来讲，网络层可达是攻击渗透的基础条件，应用层可达则使漏洞利用成为进一步可能。 相应地，在安全防护上既需要防护网络层，也需要防护应用层。

1）容器网络层防护，通常使用networkpolicy来做微隔离；
networkpolicy可以采用标签的方式，对具备相同标签的一组POD设定入向和出向的访问控制策略。由于是采用标签而非IP，因此容器动态扩缩容时的IP变化对networkpolicy是没有影响的，非常适合容器的场景。另外，使用networkpolicy，控制粒度可以是单个pod，也可以是一个deployment这样的控制器，也可以是整个namespace，当然也可以是固定IP，非常灵活方便。

2）在应用层，根据软件应用架构不同，可以考虑API网关或servicemesh里的sidecar。
通过在应用层部署API网关，可以实现统一接入、协议适配、流量管理与容错、以及安全防护等多项功能，当然也包括了访问控制。sidecar机制能起到的作用类似，相对来说更贴近k8s的生态。

上述两种机制在实际生产运营中可以单独使用，也可以结合起来起到更纵深的防御。但随着业务应用数量增加和POD数量增加，如果通过手工来配置东西向管控的策略，工作量将变得非常大，策略复杂，维护的成本也高。如果配置不当，还可能引发业务中断。因此，上述手段更多是基础能力，后续应思考的是如何将策略配置简易化、自动化、智能化，从而提升安全防护的效率。

6、容器安全升级时遇到的问题？

1.镜像中病毒或木马应如何处理？
2.镜像中有敏感路径挂载时应如何处理？
3.镜像中敏感文件的访问权限如何做到权限隔离，如需要整改时如何平滑升级？

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
1.镜像中病毒或木马应如何处理？
1）如果是已经有运行实例的镜像，建议对容器实例进行下线；
2）清除病毒木马，重新构建镜像，重新部署容器，恢复业务；
3）调查中病毒的原因，是基础镜像污染、还是业务软件部分污染。明确病毒木马通过什么样途径进入到镜像中，修复管理漏洞。
对于服务器端软件，发生病毒木马事件的概率相对较低，有统计分析dockerhub中存在后门的镜像占比0.16%，但虽然是存在的，需要注意，尤其是挖矿类木马和webshell。

2.镜像中有敏感路径挂载时应如何处理？
不挂载。大部分对敏感路径的挂载是不合理的配置导致，移除掉对应挂载即可。

3.镜像中敏感文件的访问权限如何做到权限隔离，如需要整改时如何平滑升级？
镜像中不要保留敏感文件。

通常而言，敏感文件是指用户口令、token之类。此类配置信息可以通过配置中心来进行设定，例如k8s提供的secret机制，或者Java软件可以使用Apollo这类配置中心进行维护。但镜像内不应该存在敏感信息。

7、关于运行容器的监控问题？

运行中的容器，相关漏洞会被恶意利用，产生容器逃逸风险和资源耗尽风险，针对容器运行时的监控，目前有何比较好的开源或者商业化工具？针对监控指标和阈值，是否有比较实用的标准？

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
您的问题可以分开考虑：
1）漏洞利用、逃逸攻击属于典型的安全问题，应采用专业的容器安全工具进行实时入侵检测。容器安全工具会监控进程执行、文件读写、网络流量来发现异常，匹配检测规则来判定容器是否遭受到了网络攻击。但这类容器安全工具不是运维层面的监控工具（Zabbix/Prometheus），所以也没有监控指标和阈值标准。
因为网络安全攻防类似于矛与盾，是一个动态的持续的对抗升级状态，所以入侵检测功能需要持续更新规则，持续运营。

2）资源耗尽风险，有可能是网络安全问题，也有可能是软件自身质量问题。好在容器本身是可以限制资源额度，所以影响也通常限制在当前容器，而不是整个容器云。
a.如果是软件自身质量问题，例如内存溢出，导致的资源耗尽，可以通过Prometheus实时监控 CPU和内存资源使用情况，当超过设定阈值时触发告警。这个阈值通常设定为上限的90%。
b.如果是中招挖矿病毒，也可能会出现资源耗尽情况。 Prometheus可以监控告警，容器安全工具也可以检测病毒样本或者发现连接到矿池的异常连接。

最后回答一下关于工具名称的问题。监控工具已在上文中提到，最常见的开源工具是Prometheus，很普及了。容器安全工具可以考虑开源的StackRox、NeuVector，或者采购商业化的容器安全产品，国内有几家做得还不错。

8、对于镜像安全，如有新增的供应链漏洞，具体有何种手段可以发现镜像中的漏洞并防护？

对于镜像安全，如有新增的供应链漏洞，具体有何种手段可以发现镜像中的漏洞并防护？

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
单讨论技术维度，对于供应链安全，通常建议引入软件成分分析（SCA）工具进行相应的治理。
1）开发阶段，对软件工程的代码和依赖包进行扫描，分析引入的风险；
2）构建阶段，采用黄金镜像（没有漏洞或者只有极少低危漏洞）作为镜像构建的base image；

然后基于分析结果，在上线前清理尽可能多的漏洞，从而降低供应链风险。
但是漏洞是一直在层出不穷的，上线后的镜像被爆出新的漏洞并非是少数场景，反而是一个高概率事件。
当有新增供应链漏洞时，运维和运营团队需要评估漏洞的影响范围，然后确定处理措施。
1）SCA软件更新漏洞库，确定漏洞影响的镜像列表，从镜像的角度则是更新漏洞列表；
2）通过容器云管理软件或者容器安全管理软件，关联镜像对应的容器实例，从而确定漏洞影响的容器、节点、项目、集群；
3）基于不可变基础设施的理念，容器的漏洞应在镜像上修复。
a. 如果能在短时间内修复镜像漏洞，则在对镜像的漏洞进行修复后重新上线，更新版本。所谓的修复过程，通常是指对存在漏洞的组件版本进行升级替换。
b. 如果短时间内无法修复镜像漏洞，则宜通过更新检测规则对漏洞利用的攻击进行监控；

上述解决方案，需要两个前提条件，一个开发过程已经部署了SCA工具，但大部分SCA工具通常只关注到上线前。所以另一个条件是需要将SCA的扫描结果与生产环境运行状态的资产信息库进行比对，从而更完整地评估新增漏洞对生产环境的影响。

然而，实际运营过程中，我们发现并非所有镜像是自行研发构建，也有可能是采购第三方软件的镜像进行生产部署。这样的场景下，我们无法通过SCA软件来对镜像进行深层次的分析。未来我们可能通过推广SBOM机制来强制要求所有软件厂商提供其组件清单，但仍需等待相关规范的确定。目前来说，只能依赖镜像扫描功能做到尽可能细的但不完备的成分分析。

9、关于容器安全基线配置标准？

各位专家好，从权威数据上看，容器配置问题产生的安全风险，目前排名第一，针对容器的安全基线配置，一般注意哪几方面？是否有比较实用的容器安全基线配置标准或者规范可供参考？

嘉宾回复：

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
非常好的问题！
风险来自于两个大的方面，一是漏洞，二是配置不当。容器的配置风险分为三个方面：
1）K8S集群配置，例如kublet是否允许匿名访问；
2）Docker配置，例如是否以特权模式启动；
3）容器镜像配置，例如是否存在不必要的软件组件；
如果考虑得再完善一些，还可以考虑主机上的配置和网络上的配置。其实都在CIS-Benchmark里有相关描述，获取链接：https://learn.cisecurity.org/benchmarks
对应不同的K8S和Docker版本，标准也略有差异。因基线标准内容较多，所以在本回复中就不讨论细节。
备注：CIS的规范制定并未考虑中国的国情，所以在落地时通常需要企业根据自身情况对规范进行裁剪。

leo1234 it技术咨询顾问 , 某金融IT公司
1.任何形式的特权容器
2.容器运行最小权限账户

3. 任何形式的无状态容器，但文件系统可写
   4.容器运行的用户
   5.应用二进制依赖包的安全扫描
   6.镜像安全策略------应该不属于容器内生安全
   7.网络安全策略 ------应该不属于容器内生安全
   8.CIS安全基线扫一扫，kube-bench
   9.镜像安全工具扫一扫，trivy

10、对于容器云平台管理端的安全管控一般是什么级别？是否参考一般多云平台管理的安全管控即可？

嘉宾回复

liubin0521 网信安全运营专家 , 中移动信息技术有限公司
涉及到级别，我推测题主可能是指等保的级别，或者企业内部自己定义的一套安全等级标准。
云平台管理端，不管是容器云，还是虚拟机的云，其安全等级是要看其承载的业务应用系统的安全等级。按照等保要求，云平台不能承载高于自身级别的业务系统。举例如阿里云，通过了等保三级认证，那么属于等保四级就不能部署在阿里云上。

回到题目，假设企业有两套容器云A和B，容器云A里的业务系统属于等保三级，则容器云A也需要不低于等保三级。容器云B里的业务系统属于等保二级，则容器云B也只需要按照二级的标准进行安全建设。

企业内部自己定义的安全等级也是同理，承载的业务系统安全级别越高，则容器云平台和平台管理端的安全级别也越高，相应的管控措施也就越严格。例如用户认证，低级别的可能会要求用户密码有一定复杂度，而高级别的可能会需要口令+短信验证码认证，而顶级的可能就像谍战电影里那种更多因素认证了，物理隔离+视网膜扫描+指纹+口令+走路姿势等等。

综上所述，平台的安全管控级别与承载的业务系统有关系。级别越低，管控措施会少一些，自由度高；级别越高，管控措施越多，越安全，建设成本也会越高。

金融嘉宾
什么级别不太好回答，我们一般是这几个方面进行了安全管控：
1，首先肯定是用户权限管控，分角色，不同角色的工程师拥有角色范围内的权限，同时将管理员权限进行最小化控制；
2，密码以及登录验证增强，包括复杂密码，多因子验证等；
3，留存操作日志并且定期审计；
4，使用容器安全工具定期扫描容器及镜像库，以便及时发现问题；
5，容器运行的虚拟机或物理机操作系统及时更新补丁和安全加固。