最近测试容器安全，发现部署的容器云平台和容器应用几乎都在裸奔，每个镜像和容器都有各种漏洞，平台本身也有很多问题真的出乎意料，我不知道。当我测试它时，我感到震惊。容器本身安全性较弱，容易造成越权逃逸等问题。同时，容器应用开发者缺乏对容器技术的了解，缺乏相应的安全意识和安全知识，带来了严重的安全隐患。容器安全问题涉及的内容非常多，比如镜像安全、容器运行时安全（入侵检测监控、入侵拦截与隔离）、容器平台安全、容器网络安全、微隔离等，要做好其中任何一项都不是一件容易的事这些东西很好，而且可能涉及到多个部门和团队，需要协作，所以我们也在讨论容器安全到底应该由安全团队负责，还是由容器云平台团队负责。在安全左移的趋势下，应该更加关注运行前安全等。安全问题无处不在，急事多。1、容器安全的核心在哪里？最近的测试让我思考容器安全的核心应该在哪里。是图像安全吗？是容器运行时安全吗？还是主机安全？网络微隔离或网络阻塞可能是最后的手段。但是，为了减少安全漏洞，降低安全威胁等级，早期的安全准备和安全措施也很重要，比如镜像安全扫描和补丁修复，以及平台和网络本身的安全能力等。密切相关。任何环节的漏洞都可能导致严重的问题。2.安全左移安全左移的目的是提前采取措施修复可能存在的漏洞，并在后期的运行过程中尽可能增强抗攻击能力。对于容器云平台来说，基础镜像的维护非常重要。虽然说从网上下载各种镜像文件很方便，但是很多镜像文件都有各种漏洞。如果胡乱的部署在自己的容器云环境中，势必会带来很多潜在的问题。因此，需要提供容器云平台上企业业务应用开发所需的基础镜像，如jdk、tomcat、nginx、mysql、kafka、nodejs、CentOs等，这些镜像需要由容器云平台维护和更新容器团队。出现新漏洞后，首先更新基础镜像，然后在正确的时间以正确的方式使用新镜像更新库存运行时容器。基础镜像的安全维护可能是一个很大的工作量。但这是一件值得去做的事情。很多容器云厂商也提供产品库、应用商店等功能来管理镜像，但缺乏对镜像的深度维护和安全措施。这些镜像往往存在很多漏洞，在公司内网可能还好，但一旦跑到互联网环境中，就面临着很大的威胁。按照安全左移的思路，最好的办法是所有部署的镜像都是安全的镜像，安全问题应该在部署前解决。在测试过程中，我们震惊的是，一张镜像竟然有上百个高危漏洞，业务应用团队基本无法修复。所有业务应用镜像最好来自平台提供的安全基础镜像。这样至少一个统一安全的基础镜像会减少安全漏洞，降低业务团队自行下载生成镜像带来的安全风险。3.Pre-Runtime镜像扫描提供安全的基础镜像应该是容器云平台的基本职责之一。但是，业务团队还是需要加载业务应用和相应的工具库等到基础镜像，再生成业务镜像。这可能会引入新的安全威胁。在部署镜像之前或镜像进入镜像仓库之前，需要进行必要的安全扫描，检测镜像文件中可能存在的漏洞和问题，并在部署前修复镜像中已经存在的漏洞。我们在构建容器云平台时，“以镜像仓库为媒介”，将开发和部署隔离开来。我们不向终端用户提供Docker和KubernetesCLI命令，所有操作都是通过平台UI完成的。也就是说，要部署镜像，需要将镜像上传到镜像仓库，上传的镜像仓库中的镜像会自动进行安全扫描。如果存在高危漏洞，可以通过设置规则禁止部署。我们测试的容器安全厂商提供Jenkins插件实现高危漏洞镜像拦截部署，用于CD持续部署过程。由于思路不同，实现方法也不同。不过我个人认为向左移动，将部署块放在镜像仓库中是安全的。存在高危漏洞的镜像禁止离开镜像仓库，甚至进入镜像仓库。上传时对镜像进行安全扫描和高危屏蔽。4、运行时安全检测和监控如果镜像不运行，即使有漏洞和病毒也不会造成危害。但是一旦运行生成容器，那么漏洞就真的存在了，病毒就可能开始攻击了。因此，容器启动时的检测是运行时检测的第一步。这与操作系统本身的漏洞检测和病毒检测是一样的。所以，我们测试的厂商使用的安全引擎几乎是一模一样的，能力也基本一致。目前检测结果误报的概率比较高，对一些高危威胁的定义也不尽相同。其实我们认为高风险应该是指某个漏洞或病毒的威胁程度，而不是镜像或容器的综合威胁评估得分。以分数综合评价，容易造成误解。我个人觉得更应该关注个体危害，当然也要关注综合威胁。容器在运行过程中，如果存在漏洞，可能会被攻击。因此需要监控容器的网络流量和网络异常请求，监控容器的整个运行过程。这与传统的网络安全主机检测是一样的，因此将传统主机安全扩展到容器安全的供应商在这方面具有优势，至少在理论上是这样。但容器网络不同于传统网络，容器网络安全和容器网络隔离措施也与传统网络安全略有不同。5、容器网络安全和微隔离容器网络是一个虚拟化的网络SDN（软件定义网络），可以自包含。容器网络安全隔离的实现方式有几种：零信任网络微隔离、ServiceMesh、Kubernetes网络策略等。零信任网络是通过软件定义网络实现的，所以如果要构建零信任系统，可以使用零信任网络微隔离技术。但是，由于目前的实际网络环境，离零信任网络还有很长的距离。虽然希望引入零信任网络的微隔离能力，但因其要求高而难以实现。Kubernetes网络策略隔离是最简单的一种方式，基本被各个厂商采用。但是，用网络策略来配置规则是非常麻烦的。容器数量少的时候还可以，但是容器数量多的时候就很复杂了。可能是分类、分域等。对于跨应用、跨域的访问请求，繁多的规则很容易造成混乱。目前，当容器网络安全被提上议事日程时，ServiceMesh可能是一个更好的选择。基于ServiceMesh实现流量链路拓扑、流量安全管控、访问控制和容器网络隔离等，并利用网络安全引擎实现容器网络的运行时安全和微隔离管控。6.容器安全回归容器平台没有这个考验，其实很难认清容器安全厂商之间的本质区别。至于市场上的反馈，参与测试的两家公司非常相似，功能相似，甚至厂商自己的人员也没有说明有什么实质性的差异。前面我们提到，一个是从传统的主机安全向容器安全延伸，一个是云原生安全。首先，在其产品理念和产品架构方面存在较大差异。宿主安全厂商的容器安全产品是附属组件，与宿主安全产品紧密耦合。至少目前来说，还不能分开，从容器云平台的角度来看，显得比较笨重。但从传统网络安全的角度来看，它是完美的。云原生的容器安全产品架构和轻量敏捷的容器云很匹配，我比较喜欢。侧重点不同。所以一千个人看到一个以前的哈姆雷特很正常。然而，容器安全最终还是要回归容器云平台。容器安全运维的核心在于容器云平台，而不是网络。这有点不同。尤其是容器主机和非容器主机不能很好区分的话，会带来额外的维护工作量。我觉得容器云平台的容器安全可以看作是应用安全的一部分。虽然也涉及网络安全，但核心不在网络，容器安全回归容器云平台更合适。当然，容器安全离不开网络安全团队的支持。毕竟，很多问题都需要专业的网络安全协助和支持。容器安全的市场取决于容器平台的市场，因此容器安全的前景最终取决于容器云平台的应用前景。如果将容器安全能力直接集成到容器云平台中，则更加完美，使得容器安全能力可以集成到容器平台或容器云平台中，或者至少是容器平台或容器云平台的一部分。
