蜂巢之声：青藤首发“容器安全成熟度模型”( 二 ) 为此

在这个阶段，容器化已不再是个别开发人员的业余项目，而是由团队或业务部门开展一部分正式项目。这时，开发团队会用容器创建一个用于生产的新应用或将现有应用容器化。

大多数组织机构在开发其第一个容器化应用时，可能会使用下列其中一种方法：

将现有应用容器化

将现有应用的一部分内容容器化

从头开始在容器中开发新应用

无论开发团队采取哪种方式，这一阶段属于概念验证阶段，主要了解云原生技术会带来效益，以及应用是如何在容器中运行的。

开展一个正式项目，就需要多人合作，这时就有必要建立一个镜像仓库了。组织机构可以创建私有镜像仓库，通过策略规定谁可以访问镜像或镜像仓库，确保镜像来源可信。毕竟攻击者通常会通过镜像仓库中的受损镜像，获得对某个应用的初始访问。

这个阶段的第一个核心问题是认知偏差。从开发人员到习惯使用传统工具的安全专家，几乎没有人完全了解容器中可能出现潜在安全问题。这种知识或技能上差距会导致公司“所采取的安全”措施与“应该采取的安全措施”之间会出现差距。

这一阶段的第二个核心问题是没有做好未来规划。只考虑当前阶段所需的工具和安全需求，而没考虑容器化项目扩大使用范围之后所需的安全能力。公司在此阶段必须考虑以下注意事项：

合规策略。容器安全不只是使用安全工具就可以彻底解决，还必须制定一些策略，这样才能够确保在整个容器生命周期中落实合规要求。虽说大多数公司早已经制定了一套安全策略来管理应用开发，但也需要根据容器化应用的特定环境，修改安全策略，满足容器安全需求。

漏洞管理。在开发过程中，漏洞管理最重要的环节就是镜像扫描。不同的扫描工具，其扫描的粒度也不同。有些扫描工具能够发现操作系统漏洞和某些特定语言才会有的漏洞，而有些却无法扫描每个镜像层或某些开源软件包。

配置管理。在该阶段， DevOps和安全团队可以采用CIS基准中针对Docker和Kubernetes的配置指南。在该阶段，团队可能仍会手动进行配置管理，但是自动执行配置检查的工具将改善安全状况并减少运营工作量。

第3阶段：生产部署

到这个阶段，组织的第一个应用已投入生产运行。编排工具开始成为容器化应用生产部署的一个关键部分。使用Kubernetes、MESOS、Swarm等工具可以自动执行与容器运行相关的大多数操作任务。以Kubernetes为例，当容器在Kubernetes中运行时，它们被打包在Pod单元中。 Pod可以包含一个或多个容器，但是同一Pod中的所有容器将共享相同的资源和本地网络。

虽然编排工具可以让容器应用更具弹性并易于扩展，但编排工具的使用也带来了其自身的威胁向量。编排工具本身就会引入漏洞，而且其配置也会对组织机构的整体安全状况产生很大影响。此外，编排工具的默认配置并不安全，如果忽略这些默认配置会带来巨大的安全风险。例如， Kubernetes的Kubeconfig文件是攻击者获得对应用的初始访问的一种常用方法。