随着云计算的发展，以容器和微服务为代表的云原生技术，受到人们的广泛关注，其中Docker和Kubernetes （K8S）是企业容器运行时和容器编排的首要选择。然而，在应用容器和K8S过程中，大多数企业都遇到过不同程度的安全问题，如何保障容器安全，已成为企业最关心的问题。

为了能更好的解决大家在容器云安全方面的所遇到的难题，twt社区近期持续组织了多场同行交流和话题研讨。先将干货内容整理如下，希望能够帮助更多金融企业做好容器云场景下的安全建设。

一、 趋势分析

（一）传统信息安全面临的新挑战及与容器安全的联系和区别

尚峰 某大型国有银行资深云计算专家：
传统安全是基础。可以认为传统的安全包裹着容器安全，容器安全不是独立存在的。没有一个体系能够完全脱离传统的安全完成容器云的安全。因此，先要做好传统安全，然后再做容器安全。

那么，针对容器安全能否使用一些传统的安全方案？有一些领域确实是没有办法去适应容器安全。

在容器云中，如果是彻底的原生概念，基于容器的动态肯定会是短平快，即容器的变化会是非常快的。容器是一个不可变基础设施，一般不会基于原有的技术、原有的东西去做变更，而是彻底摒弃掉老的，生成一个新的，对于这种情况，其安全体系需要能够识别新和老的这种更替，必须能够适应这种新的场景。

容器云要监控的对象比传统的全面监控对象要多很多倍，这样就会有很多的关系存在，这张网就会越来越复杂，这也是对容器云安全的的一大挑战。

此外，因为容器是标准化的，标准化就意味着要做的事情几乎是一定的，在运行的过程中间，如果超出了这个范围即是异常，所以这种情况也需要有机制能够去识别，去监测，并且有一定的机制能够去进行阻挡，或是人为的干预等等。

王洪涛 红帽资深解决方案架构师：

传统信息安全和容器安全，其实是两个互补的部分，容器安全不能够解决所有问题，传统安全也不能捎带着把容器安全解决了，因为它们各司其责，或者说各自的侧重点是不一样的。

以一个比较形象的比喻来说：传统的信息安全，就好像一个小区，小区门口设立一个保安；现在在容器云平台上，这个小区太大了，光在门口做保安检查是不够的，需要在这个小区的每栋楼，甚至每户门口都要有保安才能解决问题。这是容器的一些特点所决定的。而像日常的传统信息安全的范畴，比如说操作系统杀毒，其实就不应该放在容器的安全的成本内去考虑。比如平台上的网络抓包分析，如果通过容器云平台的安全机制去解决，其性能损耗其实是不值得的，肯定要借助于之前的传统网络解决方案，传统的走路由器或者做F5。

因此，传统安全和容器安全是互补的关系，需要搞清楚它们各自的职责和角色分工，它们是缺一不可的。

（二）容器云安全防护的需求

在容器云使用过程中，会发现与传统的安全有很大的区别。传统的安全管控，主要是在网络边界或者主机层面使用防火墙进行限制。但是使用容器云之后，所有的容器都运行在集群的内部，传统的防火墙，对该类防护已经无能为力了。需要从容器化基础设施、容器编排平台、云原生应用以及无服务等方面分析云原生安全威胁、云原生安全漏洞风险、容器镜像、容器运行时、容器网络、云原生可观测性、宿主机威胁检测等方面综合考虑 ，具体体现在如下几点需求：

1) 同一个容器云集群中，不同namespace之间的网络防护：默认情况下我们是不希望不同的namespace可以直接互相访问，这样不利于安全控制，如果有一个pod 失陷，攻击者就可以进行横向移动，造成的危害。
2) 怎样对个别Pod进行网络防护：在同一个Namespace中，默认情况下，Pod之间是可以互相访问的，但是有时可能会有特殊需求，不希望该Pod被其他Pod 访问到或者只能访问指定的端口。
3) 出容器云集群后的流量识别：在传统应用部署上，应用被部署在特定的几台机器上，那么出口流量也就是固定的几个IP，但是在容器云上，出口的IP有可能是容器云集群中的任何一个Node，而且与其他在容器云上的应用混杂在一起，那么在网络的边界，传统的防火墙如何去识别这些流量，对不用的应用去做不同的网络策略。
4) Pod之间的流量加密：这个需求在自建私有云上用到的比较少，但是如果是租用公有云的用户，这种需求就可能存在了，毕竟底层的网络流量不能在用户自己的掌控下，被流量抓包和分析的可能性还是很大。
5) 容器基础镜像的安全：基础镜像作为我们的应用运行的底层，基础镜像的如果出现安全漏洞，所有以该镜像所生成的应用镜像都受到影响，如何确保基础镜像的安全。
6) 容器运行状态下的安全检测：当容器在镜像仓库中时，可以通过扫描镜像仓库发现一些可疑镜像，但是如果镜像已经部署在容器云中，那么使用哪些手段可以快速发现可疑容器以及对应的镜像。

二、容器云安全防护典型问题及解决办法

（一）上云之后安全的管理边界和方式

典型问题1：老师们都强调编制规范、标准、基线很重要，那在研发中心和运维中心中，哪个中心组织编制这些资料会更好？还是会针对开发和运维分别编制？

rechen 某股份制银行云计算架构师：
以我们行为例，整个规范是架构办，负责整个应用的推广，整个规范的制定过程或者审核过程其实是个虚拟工作组，会把数据中心的同事拉上来，最终会做K8S集群的运维。基本上我们是归口在架构管理团队，发布、牵头制定职能规范。我们容器这边有一个团队，主体是各个职能团队，但是整个发布出来的话，是放在架构的完善。

尚峰 某大型国有银行资深云计算专家：
有一个这样的作法：谁运维谁定规范。当然不是说其一家独大或者一言堂，对于开发而言，需要参与制定过程，尤其是云上应用的运行规范，基本上要运维方确定怎么运行更好，保证稳定安全，这些是由运维方指定的。我们特殊在我们既是建设方又是运维方，所以我们的规范基本上包含了全流程。开发平台的部门也要介入规范的制定，最终是由运维方来牵头做这件事。我们的做法是这样。

典型问题2：好多容器安全都没有七层防护，而红帽有像WAF这种防护能力， WAF要是基于HTTPS，是怎么去做的？这个产品还有其他功能吗？

王洪涛 红帽资深解决方案架构师：
WAF的功能界定，就看你要用到多深。毕竟有专门做WAF的这种Web应用的防火墙的。红帽的这个产品，还是把重心关注在容器层的，用来弥补传统的WAF软件的不足，比如：在复杂的容器环境下，网络噪音和攻击信号更难识别，容器安全产品以容器而不是以应用为检测对象，使攻击信号更容易分辨; 在受到危险的攻击后，容器安全产品可采用积极主动的响应手段，调动orchestrator重启容器

除此之外，对于对于Web应用的启动防护。还可以利用容器安全产品的微隔离技术，实现声明式网络安全；利用容器平台，比如OpenShift，有一个Router层的安全加固能力，实现HTTPS加密、防DDOS攻击等这些层面的能力。

典型问题3：微隔离如何实现？对于那种横向的移动攻击，可以主动发现或主动防护吗？

王洪涛 红帽资深解决方案架构师：
微隔离的实现，主要利用 Kubernetes 内置的网络执行功能，确保一致、可移植和可扩展的分段；另外，微隔离还需要实现命名空间、部署和容器集之间的网络流量可视化，包括允许流量、活动流量、集群内外流量；以声明式安全为准则，消除不必要的网络连接许可，以最大化的减少对环境的运维风险。还应该提供一种能力，比如自动提取当前网络访问的策略，然后给出网络策略的最佳推荐（基于当前活动的网络连接），还可以跟踪和定位每一个网络连接，便于安全人员进行判断和处理。

对于横向的移动攻击，有网络基线的能力，服务运行一段时间后，安全平台自动创建网络基线，若网络活动一旦违反基线，比如做左右平移的时候违反了基线，马上就能发现，并出现异常告警。

典型问题4：对于一个传统的企业来讲，隔离和安全可能有一个安全职能的部门来负责，上云的过程对运维和安全部门等组织架构有什么影响？由哪个职能部门来牵头或者具体执行？

张立 某银行资深工程师
我们现在其实还是尽量沿用以前的边界，但是比如微隔离，以及现在跟防火墙联动等，这些还是以前的网络安全部门有人去负责去控制，但是跟我们会有交互有联动，我们会推送他们这些pod变化，然后他们去开通相应的策略，这些都是自动化的。但是整体策略的维护还是由他们来负责。

然后像一些安全方面，比如说一些防护入侵检测，包括防护这些介质的安全，还是交给安全部门去负责，需要向容器部门的人提相应的需求，包括一些平常部署管控的方式。比如说安全的人可能说，我希望部署哪些，那你就要评估这种方式是否合适，是不是可以换成那种方式可能会更好一些。但是整体上来说，我们尽量不打破原有的分工的体系，因为我认为这语言本身是一个大的体系，需要很多周边部门的配合、合作，才能把它落地，才能把它做得好，如果什么东西都想伸一手，都自己去搞的话，其实不一定会搞得太好。把大家的边界说清楚了，然后大家互相通力合作会更好一些。

（二）基础镜像和镜像仓库的管理

典型问题1：按银行监管方面要求，开发测试生产这些环境，正常来说都是要从最开始的进行物理隔离，这样一来，我们这些版本、镜像可能都没法互相传，或者说有些环境互相可以连通，但不可能一连串都连通。容器云是怎么样很好的来支持DevOps、 CICD的？

张立 某银行资深工程师：
首先，这种情况就是不同环境之间介质的流转，特别是从开发测试往生产流转的时候，以前是有一套类似门禁或者审批等等机制，其实现在也是有的，要走一个相当大的准入审批。

另外，CICD的整个流程可能涉及到从开发端到整个部署，这是一个比较长的链条。我们开发端有一套相应的工具体系，我们叫APaaS（ Application PaaS），这里面集成了前端后端的标准化的开发框架，还有标准的基于容器的流水线，我们现在针对容器的微服务架构是前后端分离的。每个工程只能形成一个镜像，还有微服务的方式去做这种流水线。改动都是自动化的，根据定义的生产部署模型自动去适配，然后去做相应的一些替换。

（三）容器运行时安全

典型问题1：企业应用的稳定运行离不开运行时刻的安全防护手段。采用什么手段可以较好的进行实时监控和告警诸如面向容器内部入侵，容器逃逸，病毒和恶意程序，异常网络连接等常见的运行时刻攻击行为？同时针对告警事件的溯源和攻击分析提供有效能力？

Liyuanlong 中原银行 资深工程师

容器运行时目前有多种办法：
1、通过宿主机agent的形式来监控容器行为，包括入侵，反弹shell等行为
2、通过平行容器的方式来监控容器，效果类似，与上一个的区别在于无法监控宿主机的行为
3、通过进程白名单的形式，建议采用这种形式。容器与主机不同，就在于其足够单一，一个容器的进程通常不会太复杂，因此，可以通过白名单的形式来进行安全监控，实现方式平行容器和宿主机agent都可
4、流量监测的形式发现异常行为，这种目前不太好做，因为容器内部流量较大，尤其时集群内东西向流量，因此流量监测能做，但是不好做。现在的建议是采用进程白名单的形式来做。

王洪涛 红帽资深解决方案架构师
RHACS是Kubernetes 原生安全管理平台，能够提供异构K8S下多集群的统一容器安全管理。包括进行实时监控和告警诸如面向容器内部入侵，容器逃逸，病毒和恶意程序，异常网络连接等常见的运行时刻攻击行为，同时针对告警事件的溯源和攻击分析提供有效能力。

典型问题2：容器在安全领域有没有比较推荐的整治与加固措施？

Steven 某券商资深云架构师
容器安全措施跟传统的安全措施没有本质的区别，只不过需要根据容器自身的特点选择合适的方法和机制。比如静态安全测试、动态安全测试、入侵检测、病毒防护、网络流量监控、漏洞检测等。但容器自身的特点是轻量、弹性、无状态、生命周期短等。采用容器通常容器的量是很大的，往往无法实现人工对每个容器管理，需要实现自动化。采用容器通常要尽可能安全左移，将安全风险消灭在部署之前。但运行时安全措施同样一点不可少。

采用容器，尽可能实现基础设施自服务能力，安全能力也是一样，比如发现漏洞后可能成败数千个容器都需要更新升级。而且不适合用传统网络防火墙的管理方式

目前容器安全方案还在发展中，简单的可以按照应用生命周期分设计时和运行时进行安全检测和防护。不过没有100%安全，有时需要根据实际有所取舍。基本上需要考虑代码的安全检测、镜像安全检测、运行时防护、入侵检测、病毒防护、节点安全、接口安全等。

典型问题3：容器逃逸问题主要是dockerrunc等基础软件的漏洞引起，虽然发生概率低，但破坏性大，一旦逃逸，可能会使得黑客拿到宿主机权限，从而对基础设施造成破坏性攻击。直接影响到了承载容器的底层基础设施的保密性、完整性和可用性。容器的逃逸问题如何解决？

击歌吟 某保险集团资深工程师
在运行容器的时候，如何容器的使用不合理会造成容器逃逸等安全问题，所以启动容器就要给容器赋予最小权限，可以从如下两个方面考虑：一、赋予容器合理的capabilities；二、在容器中以非root用户运行程序。
首先：Linux capabilities是把root用户的所有的特权做了分化，当我们启动不同功能的进程就要给容器赋予不同的权限，例如进程运行iptables命令，就要给容器赋予CAP_NET_ADMIN这个capability。
其次：是尽量不用特权用户启动容器，一般是用root用户，系统默认会带有15个capabilities,当发现容器进程权限不够的时候，需要根据使用情况整理capabilities集合，而不是直接赋予privileged权限。另外当我们在K8s运行容器需要特权用户权限挂载块存储并创建目录时，尽量通过InitContainer赋予较高权限来完成改操作。

三、针对容器云安全防护难点的解决办法共识总结

相比于传统应用而言，容器天然是弱安全的，这些不足随着容器一起跑在企业内网中，如果不能很好地识别并修复，分分钟就会成为“马奇诺防线”上的缺口，发生数据泄露、安全漏洞等，给企业带来不可估量的损失。很多早期建设容器云的企业已经深深感知到，面对容器技术的全新架构，“高筑城墙以御外敌”的传统安全方案已经不合时宜，更多的攻击面、监控和防护难度大、安全管控难度高，企业必须重新审视容器云环境的安全策略。
1) 在多个网络分区的情况下，应搭建多个容器云集群，而不是搭建一个大的集群覆盖多个网络分区，可以减少单个集群出现问题对全部网络分区的影响。

2) 对多个集群进行管理，可以单独搭建一个小型的管理集群，在管理集群上使用RHACM对全部集群进行统一管理，使用ArgoCD对应用进行多集群发布。

3) 在传统的安全基础上，配合使用Network Policy 等多种手段，对容器的南北向和东西向网络流量进行管控，可以对容器进行微隔离。

4) 在容器云中运行的容器镜像，必须是使用使用Redhat提供或者其他通过安全检测的镜像，不得随意使用互联网提供的镜像。

5) 镜像仓库对接镜像扫描工具，可以扫描在镜像仓库中的镜像，可以通过在容器云平台安装RHACS或者其他商业软件扫描运行中的容器是否包含漏洞和异常程序。

6) 生产与测试环境之间的容器镜像，通过镜像仓库的同步功能进行同步，可在同步前加入审核或者版本号限制等控制措施。

7) 可以使用Service Mesh服务网格等技术，对Pod 之间的流量进行加密和链路追踪。