“裸奔”的容器，安全问题迫在眉睫

最近测容器安全，才发现部署的容器云平台和容器应用几乎在裸奔，每个镜像和容器都有各种各样的漏洞，平台本身也不少问题，真是不测不知道，一测吓一跳。容器本身就是弱安全的，容易带来越权逃逸等问题，同时容器应用研发人员对容器技术又缺乏了解，缺乏相应的安全意识和安全知识，这就带来了比较严重的潜在的安全问题。 容器安全问题涉及内容很多，比如说镜像安全、容器运行时安全(入侵检测监控、入侵拦截和隔离)、容器平台自身的安全、容器网络安全、微隔离等，任何一项内容做好都不容易，而且又可能涉及多个部门和团队，需要协作，所以我们也在讨论容器安全应该由安全团队来负责还是容器云平台团队来负责，在安全左移的趋势下，是否应该更多关注pre-runtime安全等等。安全问题无处不在，有很多的事项迫在眉睫。

一、 容器安全的核心在哪?

最近的测试让我一直在思考容器安全的核心到底应该在哪里。是镜像安全?还是容器运行时安全?还是主机安全?网络安全?虽然都在鼓吹安全左移，但我觉得容器运行时安全依然是核心，要能及时的检测到安全威胁并自动实现入侵拦截，网络微隔离或者网络阻断可能是最后的手段了。不过为了减少安全漏洞，降低安全威胁程度，前期的安全准备及安全措施也是至关重要，比如镜像安全扫描和补丁修复，平台和网络自身的安全能力等等，都是密切相关。任何环节有漏洞，都可能会带来严重的问题。

二、 安全左移

安全左移目的就是要提前采取措施修复潜在的漏洞，尽可能在后期的运行过程中增强抗攻击能力。对于容器云平台来说，基础镜像的维护就非常重要。虽然目前说可以很方便的从网络上下载各种各样的镜像文件，但很多镜像文件都存在这样那样的众多漏洞，如果不加区分的部署在自己的容器云环境，势必会带来很多潜在的问题。所以这就需要在容器云平台提供企业业务应用开发所需的基础镜像，比如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等等，这些镜像需要容器团队来维护并及时的更新，在发现新的漏洞之后先更新基础镜像，然后在合适时间合适的方式用新镜像更新存量运行时的容器。 基础镜像的安全维护可能是一个不小的工作量。但是这是一个值得做的事情。很多容器云厂商也提供像制品库、应用商店一样的功能来管理镜像，但缺乏对镜像的深度维护和安全举措。这些镜像往往存在着很多漏洞，在公司内网可能还好，一旦运行在互联网环境，就面临着极大的威胁。按照安全左移的思想，最好的办法就是所有部署的镜像都是安全的镜像，在部署之前解决掉安全问题。在测试中我们震惊于一个镜像竟然存在数百个高危漏洞，如果让业务应用团队去修复，基本上是不可能的。所有的业务应用镜像最好来自于平台所提供的安全的基础镜像。这样，至少统一的安全的基础镜像会减少安全漏洞，也减少业务团队自己下载、生成镜像所带来的安全隐患。

三、 Pre-Runtime镜像扫描

提供安全的基础镜像应该是容器云平台的基本职责之一。不过业务团队还需要加载业务应用及相应的工具库等到基础镜像，然后生成业务镜像。这就可能引入新的安全威胁。在镜像部署之前或者在镜像进入镜像仓库之前需要进行必要的安全扫描，以检测镜像文件可能存在的漏洞和问题，在部署之前修复镜像存在的漏洞。 我们在建设容器云平台时，“以镜像仓库为媒介”，隔离开发和部署，我们不向终端用户提供Docker和Kubernetes CLI命令，所有的操作通过平台UI完成。也就是说要部署镜像，需上传镜像到镜像仓库，上传镜像仓库里的镜像可以自动被安全扫描。如果存在高危漏洞，则可以通过设置的规则禁止部署。 我们测试的容器安全厂商提供Jenkins插件来实现高危漏洞镜像阻断部署，用于CD持续部署流程。由于思路的不同，实现方式有差别。不过我个人觉得可以再安全左移一点，把部署阻断放在镜像仓库。高危漏洞的镜像禁止出镜像仓库或者甚至禁止进镜像仓库，在upload时实现镜像的安全扫描和高危阻断。

四、 运行时安全检测和监控

镜像不被运行，即便有漏洞、有病毒也不会带来危害，但一旦被运行生成容器，那么漏洞就是实实在在的，病毒就可能开始发作。所以容器启动时的检测是运行时检测的第一步。这和操作系统自身的漏洞检测、病毒检测等是一样的。所以我们测试的厂商所使用的安全引擎也几乎一摸一样，能力基本相同。目前检测结果相对来说误报的几率还是很大的，对于一些高危的威胁定义也有差别。其实我们觉得高危应该是指某一个漏洞或病毒等的威胁危害程度，而不是指这个镜像或容器的综合威胁评判得分。用得分综合评判容易导致误解。个人觉得更应关注个体危害，当然也要关注综合威胁。 容器运行起来，如果有漏洞就可能被攻击，所以这就需要对容器网络流量和网络异常请求进行监控，对容器的整个运行时进行监测。这和传统的网络安全主机检测是一样，所以一家以传统主机安全扩展到容器安全的厂商在这方面是占优势的，至少理论上是占优势的。不过容器网络又区别于传统网络，容器网络安全和容器网络隔离措施也稍有别于传统网络安全。

五、 容器网络安全和微隔离

容器网络是一种虚拟化网络SDN(软件定义网络)，可以自成一体。容器网络安全隔离有几种实现方式：零信任网络微隔离、ServiceMesh、Kubernetes网络策略等。零信任网络就是通过软件定义网络来实现，所以如果要构建零信任体系，可以采用零信任网络微隔离技术。不过由于当前实际的网络环境，离零信任网络还是有不小的距离，虽然希望引入零信任网络微隔离能力，不过由于其要求有些高，难以落地而作罢。Kubernetes网络策略隔离是最简单的方式，各家厂商基本上也是采用这种方式，不过用网络策略配置规则是非常的繁琐，在容器量小的情况下还可以接受，大量时就非常复杂化。可能要分类、分域等，对于跨应用、跨域访问的请求，众多的规则很容易带来混乱。在容器网络安全提上日程的当前，ServiceMesh可能是一个比较好的选项。基于ServiceMesh实现流量链路拓扑，流量安全管控，访问控制和容器网络隔离等，配合网络安全引擎，从而实现容器网络的运行时安全和微隔离管控等。

六、 容器安全回归容器平台

不经过这次测试，对于容器安全厂商的本质差别其实是难以认知的。对于市面上的反馈，参加测试的两家半斤八两、功能大同小异，甚至厂商自身的人员也没说明白有什么实质差别。 前面我们提到过，一家是从传统主机安全扩展到容器安全，一家是云原生安全。首先从其产品理念和产品架构来说，就有很大的区别。主机安全厂商的容器安全产品是一个附属组件，紧耦合于主机安全产品，至少目前是无法分离的，这就使其从容器云平台视角看起来显得笨重。不过从传统网络安全的视角来看则是完美的。云原生的容器安全产品架构则和容器云的轻量、敏捷很匹配，这是我比较喜欢的。关注点是不一样的。所以一千个人眼里有一个前哈姆雷特，也是正常的。 不过容器安全最终还是要回归容器云平台的，容器安全运维核心在于容器云平台，而不是网络，这是有些区别的。特别如果不能很好的区分容器主机和非容器主机，会带来额外的维护工作量。容器云平台的容器安全我觉得可以看作是应用安全的一部分，虽然也涉及网络安全，但核心不在网络，所以容器安全回归容器云平台会更合适点。 当然，容器安全离不开网络安全团队的支持，毕竟很多问题都需要专业的网络安全的协助和支持。 容器安全的市场取决于容器平台的市场，所以最终容器安全的前景依赖于和容器云平台的应用前景。如果把容器安全能力直接融合于容器云平台，使容器安全能力融合成或至少集成容器平台或容器云平台的一部分，那就更完美了。