当我大约五年前看到集装箱的出现，有一点是明确的：如果-这是一个很大的，如果那时-如果容器成为一个事情，他们会改变企业如何将生产经营他们的应用程序。

快进到今天，这个观察并不是惊天动地。容器的早期采用者已经发现了这种情况（有时很难）。更有趣的是容器和微服务架构从根本上改变了运营方式。我甚至可以说容器正在实现安全性和监控功能的融合，从而加速向DevSecOps的迁移。

但让我们退后一步。

组织正在转向容器，以简化开发并加快创新步伐。2017年Forrester的一项研究发现，在接受调查的组织中，66％的公司实现了加速的开发人员效率，而75％的公司实现了应用程序部署速度的中等至显着增长。

话虽如此，容器对企业来说相对较新。在2018年6月的DockerCon旧金山活动中，Docker指出，在接受调查的参与者中，有50％的人在去年开始使用容器，这表明大多数IT专业人员和DevOps人群仍在学习。当这些新手用容器生产时，我怀疑他们的预生产计划将包括重新考虑监控和安全流程。

我们来讨论一下原因。

容器更易于创建和快速旋转，因为它们通常比虚拟机更小，重量更轻。

95％的容器不到一周就能存活，11％的容器可以存活不到10秒。

但是，创建它们的难易程度，通过持续开发/持续集成（CI / CD）管道快速启动容器的能力，以及使用编排工具来扩展和移动它们意味着容器会被淘汰，经常重生。事实上，去年的一项研究发现，95％的容器不到一周就能存活，11％的容器可以存活不到10秒。这对开发人员来说非常棒 – 更频繁地推动代码，更快地创新，并在竞争中保持领先地位。一切都好，对吗？

没那么快。可以想象，这使跟踪小虫子的工作变得复杂。虽然容器（如果使用得当）可以改善您的安全状况，它们的绝对数量，分布以及容器的黑盒性质会迫使您重新考虑风险和合规性配置文件。将容器设置为机器或虚拟机是不明智的：由于开销，您无法在每个容器中放置代理，并且使用代码注入技术类似于在每个容器中注入病毒。这两种方法都违反了容器的软件设计原则。

在过去，您可以采用以网络为中心的方法，观察进出机器或虚拟机的所有内容，以获得正在发生的事情的“真相”。但考虑到容器的动态特性以及容器跨云移动的能力，旧的以网络为中心的方法不像以前那样工作，既不用于安全也不用于监控。

但什么可以取代网络作为真相的来源？就像容器本身是从嵌入在操作系统中的功能创建的一样，事实证明，监视和保护容器的最佳方法是利用底层系统中的一些原语。

操作系统内核可以是这样的事实：内核从不关于系统上运行的内容或这些应用程序正在做什么。这使您可以查看主机上运行的每个容器内部，让您查看所有应用程序，网络，文件和系统级活动。

因此，当然，除了您可能想要跟踪的通常混合的监控细节之外，如果您有这种类型的仪器，您还可以观察异常的安全行为并观察入侵。容器的性质简单地导致监视和安全功能的自然集成。

当然，你不必这样做，但它变得如此容易，以至于大多数集装箱商店最终会到达那里。

另一方面，全面使用微服务架构的组织别无选择，只能实现这一飞跃。

这就是原因。

微服务架构和支持平台更加复杂，因为它们隔离了功能以增加组件的分离并加速开发。开发人员和服务团队可以更自由地更快，更频繁地启动功能。并且，功能越孤立，通过将微服务组件拼接在一起就可以创建更多的排列。

然而，最终结果是运动部件数量的大量增加，以及这些应用的攻击面的巨大增加。

这是攻击者的梦想成真，也是安全专业人员的噩梦。这就是为什么微服务商店发现必须将监控和安全任务集成到他们的平台中，如果他们还没有这样做的话。

这也是DevSecOps运动如此迅速地获得蒸汽的原因。好消息是，容器环境提供了在开发周期的多个点构建自动安全扫描的机会，这应该意味着容器最终在安全意义上比甚至虚拟机更加强大。

一组强大的开源安全构建块似乎有助于解决这些容器安全问题。像Anchore这样的工具解决了扫描和已知漏洞的问题; Falco解决了运行时安全违规和活动审计，并且Inspect解决了取证和事件响应问题。容器安全产品就在那里，而Sysdig等一些产品提供统一的安全性，监控，取证和故障排除，为快速发展的容器环境提供单点控制。

这简化了部署并简化了容器的管理，使组织能够从风险，安全性和合规性角度更快地移动并提高他们提供的服务质量。

根据Gartner的说法：

“在应用层，不需要两个单独的工具（一个用于安全，一个用于操作）执行服务的详细监控。至少，数据将在各个团队之间共享，但理想情况下，应用程序性能监视和安全监视将合并到支持单个DevSecOps团队的应用程序监视和性能中。

容器的引入颠覆了许多惯例，并要求IT组织重新思考一切。虽然所有采用容器的组织似乎最终都会在这些环境中集成监控和安全功能，但采用微服务架构的商店别无选择，只能走今天的道路。