技术洞见：公有云容器市场发展及安全问题

因为操作的简单性和可扩展性，云容器服务得到越来越多企业的重视。通过容器技术可显著提高开发人员和运营人员的效率。

虽然容器技术可加快应用程序的部署，但想要实现容器的底层技术对于许多企业来说仍然非常困难。为此，许多云服务提供商（CSP）提供容器即服务（CaaS）产品。这些产品可以减轻安全和运维团队构建容器基础设施的工作负担。因为CaaS产品具有IaaS的所有基本功能，包括自助服务、可扩展性、计算、存储和网络资源以及抽象层。容器运行的底层软件包括容器运行时、容器编排、作业调度、资源管理和其他容器管理功能。

公有云容器的服务架构

1、公有云容器市场发展

据权威机构分析，到 2022 年企业使用公有云容器服务比例将从 2018 年的 50％ 增长到 70％ 以上。当下主流的公有云厂商都已经提供了容器服务（CaaS），许多规模较小的公有云和私有云IaaS提供商也瞄准了此类产品。当然，公有云CaaS市场的增长将受到IaaS市场整体增长以及容器技术采用率的影响。Gartner预测，在接下来的几年中，容器的使用将继续快速增长。

未来几年容器使用情况

当然，容器采纳大部分是由开发者所驱动的，他们将容器视为快速生成高质量代码的主要工具。不管是新应用程序的开发，还是老程序的封装部署，容器都可以发挥重要价值。例如，在开发期间使用容器可以确保跨开发、测试和生产环境的一致配置，大大简化了对接所需时间。此外，容器还是云原生应用、微服务应用程序最佳的运行平台。归根结底，容器已经成为现代应用程序平台基础设施的一个关键组成部分。

未来，随着越来越多企业将工作负载转移到公有云上，可以预见公有云容器服务市场会继续保持增长。随着很多企业逐步开始采用多云服务，为解决多个公有云容器服务兼容性问题，有的供应商已经开始提供跨不同云环境部署管理的能力，例如OpenShift， Kubernetes引擎都可提供相对应服务。

虽然老旧应用程序不是容器使用的主要目标，但是在接下来的几年里，更多的企业将重新构建它们的历史应用程序，将从单一的应用程序转换为自治的、分解的服务或微服务，这些服务被打包部署在容器中。当然，企业在将应用程序迁移到云上时，有几种不同情况，如下图所示。

将应用程序移植上云的计划

从上图可知，“云迁移”可分为Rehost、Refactor、Rearchitect、Rebuilt和Replace5个层次。每个层次对于业务迁移和部署难度也完全不同。

（1）在Rehost阶段

虽然改变了业务承载形态，但未改变任何运维流程，仅仅只是实现在云上部署。

（2）在Refactor阶段

基于业务场景的视角，用流程再造的方式，来匹配公有云，最大的好处就是节约资源。

（3）在Rearchitect阶段

通过改造应用架构，在节约成本的同时，也无需自建数据库，授权的费用也大大降低。

（4）在Rebuilt阶段

全部应用都按照云原生的方式进行开发部署，获得最大程度的弹性扩展能力。

（5）在Replace阶段

已不属于传统IT范畴，以服务的方式进行SaaS购买。

以rehost为例，虽然直接迁移（lift-and-shift）是可行的，但也只是实现了更快的加载、缩短了重新加载时间和恢复时间。显然，直接迁移并不能显著提高可扩展性、性能和弹性。为了实现这些目标就需要重构应用程序以满足云原生设计的要求。这就是容器将产生显著效果的地方。

虽然，当下许多企业仅仅是在主机场景中使用容器处理无状态实例。但是，未来在公有云上的许多应用程序将更多地关注有状态应用程序。因此，需要为应用程序开发人员提供更多的底层抽象技术，并提供额外抽象的服务。尽量使开发人员能够专注于业务逻辑，而不是底层基础设施。

2、公有云容器服务选择

众所周知，应用程序开发人员是容器技术的主要关注对象。他们希望使用容器技术来支持更高效的应用程序交付过程。因此，容器采用包括CaaS采用，通常由应用程序开发负责人、企业架构师或技术创新负责人处理。大量的公有云IaaS和PaaS支出都是由业务线付费买单，而不是CIO所负责的集团IT预算。因此，基础设施运营（I&O）领导者必须与相关业务人员合作，才能更好为后期容器管理提供服务。

随着公有云容器服务的快速发展，越来越多的厂商开始提供对应不同功能的服务。这些产品既可以本地部署，也可以在公有云环境中部署。当前，有三类提供公有云相关容器服务的供应商，分别是云服务提供商（CSPs）、管理服务提供商（MSPs）、主机服务提供商。

公有云容器服务相关提供商

不同供应商可能会提供不同功能和服务，企业在选择时候可以通过检查以下属性来比较和对比供应商的产品：

（1）镜像仓库

仓库负责存储和检索容器镜像。虽然公有云提供商支持使用 Docker Hub 等公共仓库，但许多公司还提供安全且可扩展的私有镜像仓库。以下是需要重点考虑因素：

· 是否支持应用程序开发工具

· 是否可以加载或修改应用程序基础设施镜像的管理功能

· 能否支持与身份识别与访问管理（IAM）系统接口

（2）API、命令行界面（CLI）和图形用户界面（GUI）

这些都是公有云提供商提供的典型服务。此外，开发人员经常使用 CLI 并将其作为工具链的自动化内容。这部分需要重点考虑因素是相对于不同用户类型的易用性。

（3）调度、编排和集群管理

使用这些功能，可以在多台主机上扩展服务，如 Kubernetes 或 Docker Swarm。这部分需要重点考虑因素包括工具的灵活性以及与云提供商提供服务的集成程度。

（4）主机管理

这部分主要考虑因素包括主机操作系统要求、所需的主机管理以及可用主机的配置灵活性及其对服务定价的影响。

（5）自动扩展

支持横向扩展，动态分配额外的基础设施为调度程序提供支持。有两种类型的自动扩展，分别是主机池自动扩展以及容器自动扩展。主要考虑因素包括基于计划和基于触发器的自动扩展功能、部署和取消部署的速度、以及配置和调优的简便性。

（6）网络和负载均衡

容器技术（尤其是容器编排）为网络和负载均衡带来了前所未有的挑战。大多数容器服务支持 4 层负载均衡，但越来越多的组织机构正在使用 7 层负载均衡器（网关）、Kubernetes 入口服务等来实现负载均衡。这部分重点考虑因素是网络集成的深度、配置灵活性和实施的简易性。

（7）支持有状态的应用程序

支持无状态应用程序是容器相关技术的固有特性。由于镜像格式设计为不可变，流程短暂，以及将容器体积映射为存储空间的技术发展尚不成熟，因此，容器对有状态的应用程序提出了独特的挑战。一个关键考虑因素是服务是否支持数据持久性以及与第三方容器存储解决方案集成的能力。另一个考虑因素是数据库服务的集成和支持。

（8）监控和日志管理

必须监控和管理在服务上运行的应用程序。Telemetry 服务包括监控、报警、日志和诊断。除了功能的广度和深度之外，关键考虑因素是定义和使用的简便性。另一个关键考虑因素是兼容性、与现有使用的工具的集成度等。

（9）安全与治理

除了一般的 IaaS 安全功能，如资源级安全性和 IAM 之外，还应该有容器特有的安全功能。例如，通过扫描私有仓库来查找漏洞、安全加密等。

（10）DevOps 工作流程

DevOps 工具、CI/CD 工具链、应用程序发布编排（ARO）工具和容器镜像生成器等工具都是与容器管理系统集成在一起。需要重点考虑因素是这些工具与容器服务集成的深度和广度。

（11）容器运行时

容器运行时，可以让集群节点在仓库中获取容器镜像，还可生成正确的文件结构在主机上运行容器，也可与网络和存储插件交互，也能创建、启停容器。因此，功能的深度和广度也是一个关键考虑因素。

3、容器的安全防护

正如上文所说，越来越多的企业利用容器来快速构建和维护新服务和新应用。但是，容器本身也存在重大的安全风险，例如不安全的容器镜像、运行环境的安全问题、架构缺陷与安全机制等，这都意味着保护容器安全将是一项持续的挑战。

容器的安全防护应该覆盖整个容器的生命周期，即容器的构建、分发、运行三个阶段，这样才能确保持续的安全性。

（1）容器构建安全性

由于开源软件在容器中广泛使用，增加了将漏洞引入企业应用程序的风险。作为构建阶段的一部分，应该扫描软件和Docker容器镜像，以发现漏洞，并在生产之前解决问题。因此需要定期扫描镜像注册中心，以检测生产就绪的容器镜像中是否存在新发现的漏洞。

此外，容器构建通常都是单一功能，因此应该删除任何不必要的包、库和其他组件，对镜像进行精简、加固，以容器减少攻击面。

（2）容器分发安全性

DevOps团队需要确保没有在生产中使用未经授权的镜像。为了保护管道的这一阶段，需要经过安全认证，比如镜像签名和访问控制。对Registry、编排工具等其他开发工具的应设置统一的访问控制策略，集成到类似LDAP这类的平台中。

编排和容器管理工具，如Kubernetes、Docker Enterprise Edition、Rancher和Red Hat OpenShift容器平台，提供了此阶段所需的许多安全特性。

（3）容器运行安全性

运行时安全性是最重要的方面，因为应用的整个生命周期内将不断受到扫描和攻击。即使容器不断地启动、停止和更新，它们所运行的主机也很容易受到新的攻击和零日攻击。

生产环境中运行容器的安全性分为运行时准备阶段和生产环境阶段两个步骤。

运行时准备阶段

当容器正式运行在生产环境中之前，应确保容器的运行时环境是安全的。这包括容器运行时的配置、宿主机的安全、容器应用本身的安全配置、负载均衡等等其他网络或系统服务。

例如，容器运行时，需配置容器的运行用户，若不配置容器的运行用户，容器将会以ROOT权限运行。黑客一旦入侵到以ROOT权限运行的容器中，则拥有了主机内核的所有功能，黑客几乎可以做主机可以做的一切。

生产环境阶段

容器的引入带来了新的入侵方式，同时使东西向流量的安全问题更加突出，因此，对生产环境进行持续性的安全防护和检测必不可少。例如检测容器内的隐藏的WebShell、监控容器内的恶意进程、提权行为等等。

虽然在容器使用镜像运行之前，会对镜像进行一次全方位的漏洞扫描。但一方面，容器运行起来后，可能会被黑客安装上有漏洞的应用加以利用；同时随着时间的推移，软件应用中更多的漏洞被发现了，这些有可能在正在运行的容器中被使用。因此需定期扫描运行中的容器，以确保运行态的容器中不存在新的漏洞。

此外，容器的使用带来更频繁的东西向流量，因此，企业需重视容器带来的网络安全问题。首先可视化容器之间的访问关系，然后监控网络行为，检测基于网络的攻击事件如DDoS攻击、DNS攻击等。同时，需注意对容器之间的网络连接进行加密。

（4）容器安全解决方案

目前，国际市场上涌现了一批容器安全产品安全厂商，如Neuvector、Twistlock、StackRox、Aqua等等，国内自研容器安全产品的则有青藤云安全。从容器安全产品的技术方案上来看，目前大部分的容器安全厂商均使用了平行容器的方式对宿主机上的容器进行安全防护，而青藤云安全则采取了基于宿主机Agent的方式。这两种技术方式有何不同，会产生怎样不同的安全防护效果呢？

平行容器技术方案：利用容器的隔离性和良好的资源控制能力，在容器的宿主机中启动一个容器，该容器通过挂载宿主机的所有文件系统，而后在容器内部对这些文件系统进行实时监控和处理响应，以实现对容器进行防护的作用。

基于宿主机Agent的技术方案：即基于Agent的主机防护能力，监控宿主机上容器相关的文件、进程、系统调用等等信息，增加其Agent中对于容器的清点、监控、防护能力，通过一个Agent，实现宿主机安全、容器安全两种防护的效果。国内新一代主机安全厂商青藤云安全是此类方案的践行者。

以上两种方案示意图如下：

两种技术方案对比如下：

写在最后

以容器、微服务、Serverless 为代表的云原生技术，带来一种全新的方式来构建应用。企业 IT 架构也随之发生巨大变化，而业务又深度依赖 IT 能力。这带来了一定程度的复杂性和挑战性，尤其是其安全挑战不可忽视。企业在享受新技术带来便捷与利益的同时，其安全性也需要引起足够的重视。