最近，在测量容器安全性时，我发现部署的容器云平台和容器应用程序几乎是裸体的。每个镜像和容器都有各种各样的漏洞，平台本身也有很多问题。我真的不知道。我很震惊。容器本身安全性弱，容易带来越权逃逸等问题。同时，容器应用研发人员对容器技术缺乏了解，缺乏相应的安全意识和安全知识，带来了严重的潜在安全问题。
容器安全问题涉及很多内容，如镜像安全、容器运行安全（入侵检测监控、入侵拦截隔离）、容器平台本身安全、容器网络安全、微隔离等，任何内容都不容易，可能涉及多个部门和团队，需要合作，所以我们也讨论容器安全应该由安全团队或容器云平台团队负责，在安全左移的趋势下，应该更加关注pre-runtime安全等等。安全问题无处不在，很多事情迫在眉睫。
容器安全的核心在哪里？
最近的测试让我一直在思考容器安全的核心应该在哪里。是镜像安全吗？还是容器运行安全？还是主机安全？网络安全？虽然它们都提倡安全向左移动，但我认为安全仍然是容器运行的核心。为了及时检测安全威胁，自动实现入侵和拦截，网络微隔离或网络阻断可能是最终手段。然而，为了减少安全漏洞和安全威胁，早期的安全准备和安全措施也非常重要，如镜像安全扫描和补丁修复、平台和网络本身的安全能力等。任何链接都有漏洞，这可能会带来严重的问题。
二、 安全左移
安全向左移动的目的是提前采取措施修复潜在漏洞，并在以后的操作过程中尽可能提高抗攻击能力。对于容器云平台，基本镜像的维护非常重要。虽然从互联网上下载各种镜像文件非常方便，但许多镜像文件都有许多漏洞。如果不在自己的容器云环境中部署，它必然会带来许多潜在的问题。因此，这需要在容器云平台上提供企业业务应用开发所需的基本镜像，如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等等，这些镜像需要容器团队及时维护和更新。发现新漏洞后，先更新基本镜像，然后在适当的时间和方式更新库存运行时的容器。
基本镜像的安全维护可能是一个很大的工作量。但这是一件值得做的事情。许多容器云制造商也提供与产品库和应用商店相同的功能来管理镜像，但缺乏对镜像的深度维护和安全措施。这些镜像往往有很多漏洞，在公司的内部网络中可能很好，一旦在互联网环境中运行，它们就面临着巨大的威胁。根据安全向左移动的想法，最好的方法是所有部署的镜像都是安全的镜像，并在部署前解决安全问题。在测试中，我们对一个镜像有数百个高风险的漏洞感到震惊基本上不可能让业务应用团队进行修复。所有的业务应用程序镜像最好来自平台提供的安全基本镜像。这样，至少统一的安全基本镜像将减少安全漏洞，并减少业务团队自己下载和生成镜像带来的安全风险。
三、 Pre-Runtime镜像扫描
提供安全的基本镜像应该是容器云平台的基本职责之一。然而，业务团队还需要将业务应用程序和相应的工具库加载到基本镜像中，然后生成业务镜像。这可能会引起新的安全威胁。在镜像部署或进入镜像仓库之前，需要进行必要的安全扫描，以检测镜像文件中可能存在的漏洞和问题，并在部署前修复镜像中存在的漏洞。
在构建容器云平台时，我们将以镜像仓库为媒介隔离开发和部署Docker和Kubernetes CLI通过平台命令和所有操作UI完成。也就是说，要部署镜像，需要将镜像上传到镜像仓库，上传到镜像仓库的镜像可以自动安全扫描。如有高风险漏洞，可禁止通过设置规则部署。
我们测试的容器安全制造商提供Jenkins插件用于阻断高危漏洞镜像的部署CD持续部署流程。由于思维方式不同，实现方式也不同。但我个人认为，我可以安全地左移，并将部署阻塞放在镜像仓库中。禁止在镜像仓库外出或甚至进入高风险漏洞的镜像upload实现镜像的安全扫描和高风险阻断。
四、 运行时的安全检测和监控
镜像不运行，即使有漏洞和病毒，也不会造成伤害，但一旦运行生成容器，漏洞就是真实的，病毒就可能开始发作。因此，容器启动时的检测是运行时检测的第一步。这与操作系统本身的漏洞检测和病毒检测相同。因此，我们测试的制造商使用的安全引擎几乎相同，能力基本相同。目前，误报的概率相对较大，一些高风险威胁的定义也不同。事实上，我们认为高风险应该是指某个漏洞或病毒的威胁程度，而不是镜像或容器的综合威胁评价得分。综合评分容易导致误解。就我个人而言，我认为我们应该更加关注个人危害，当然，我们也应该关注综合威胁。
当容器运行时，如果有漏洞，可能会受到攻击，因此需要监控容器网络流量和网络异常要求，并监控容器的整个运行。这与传统的网络安全主机检测是一样的，因此一家将传统主机安全扩展到容器安全的制造商在这方面具有优势，至少在理论上具有优势。然而，容器网络不同于传统网络，容器网络安全和容器网络隔离措施也略不同于传统网络安全。
五、 容器网络安全和微隔离
容器网络是一种虚拟网络SDN(软件定义网络)，可以自成一体。实现容器网络安全隔离的方法有几种:零信任网络微隔离、ServiceMesh、Kubernetes网络策略等。零信任网络是通过软件定义网络实现的，因此如果要构建零信任系统，可以采用零信任网络微隔离技术。但由于目前的实际网络环境，离零信任网络还有很长的路要走。虽然希望引入零信任网络的微隔离能力，但由于要求高，很难放弃。Kubernetes网络战略隔离是最简单的方式，每个制造商基本上都采用这种方式，但网络战略配置规则非常繁琐，容器量小也可以接受，大量非常复杂。可能需要分类、分区等，对于跨应用程序、跨域访问的要求，许多规则很容易带来混乱。当容器网络安全被列入议程时，ServiceMesh基于ServiceMesh实现流量链路拓扑、流量安全控制、访问控制和容器网络隔离，配合网络安全引擎，实现容器网络运行中的安全和微隔离控制。
六、 容器安全回归容器平台
没有这次测试，容器安全制造商的本质差异实际上很难理解。对于市场上的反馈，参加测试的两家公司的功能相似，甚至制造商自己的人员也不明白有什么实质性的差异。
正如我们前面提到的，一个是从传统的主机安全扩展到容器安全，另一个是云本地安全。首先，从其产品概念和产品结构来看，它有很大的不同。主机安全制造商的容器安全产品是一个附属组件，与主机安全产品紧密耦合，至少目前无法分离，使其从容器云平台的角度看起来笨重。但从传统网络安全的角度来看，它是完美的。云本地容器安全产品结构与容器云的轻量级和敏捷性非常匹配，这是我最喜欢的。注意力是不同的。所以在一千个人眼中有一个前哈姆雷特是很正常的。
然而，容器安全最终将回归到容器云平台。容器安全运行和维护的核心在于容器云平台，而不是网络，这是一些差异。特别是，如果容器主机和非容器主机不能很好地区分，它将带来额外的维护工作量。我认为容器云平台的容器安全可以被视为应用安全的一部分。虽然它也涉及到网络安全，但核心不在网络中，因此容器安全回归到容器云平台将更加合适。
当然，容器安全离不开网络安全团队的支持。毕竟，许多问题需要专业网络安全的帮助和支持。
容器安全市场取决于容器平台的市场，因此容器安全的最终前景取决于容器云平台的应用前景。将容器安全能力直接集成到容器云平台中，将容器安全能力集成到或至少集成到容器平台或容器云平台的一部分，更为完美。