虽然越来越多的企业开始采用容器化的云原生应用，但传统的安全措施却无力应对新技术发展带来的挑战。当下云原生虽说异常火热，却没有一个清晰的路线图，能够指明在容器化过程中，各个阶段该如何做好安全。由于容器化的每个阶段都会带来新的安全挑战，企业必须在做好基础架构的同时，确保每个阶段的安全。可以预见，从第一个容器化应用开发到管理数千个容器过程中，安全需求也在不断变化。
为此，青藤发布国内首个“容器安全成熟度模型”，旨在帮助企业在采用容器和容器扩容过程中能够更好理解并成功应对所产生的各类安全挑战。
一、引言
无论应用是在容器中运行，还是在虚拟机、主机上运行，发生安全事件的后果都是相同的。此外，在安全事件发生后，无论打多少补丁，也无法挽回已泄露的敏感数据。据调查报告《2020年容器与Kubernetes安全状况》显示，94%的受访者表示，在过去12个月中发生了容器安全事件。
在过去12个月中遭遇过容器安全问题类型和比例
在很多情况下，企业并不完全了解容器化架构所面临的安全挑战，更不用说如何主动应对这些挑战。这时，常见的做法就是将之前的安全策略应用到容器中来，但这并不一定适合新的应用体系架构和开发工作流程。总得来说，就是容器使用率不断提高，但安全总是落后一步。
下文将针对容器安全成熟度模型进行详细解释，旨在帮助企业更好了解需要部署哪些重要工具，采取哪些措施，来满足当前和未来容器安全需求。
二、容器安全成熟度模型
第1阶段：实验学习
在这个阶段，主要是开发人员自己学习如何在机器上使用容器。例如，通过一些不进入生产系统的项目做练习。在这一阶段，所涉及的应用大多是一些基本应用。
这阶段可能持续数月之久。由于只有个别开发人员在学习和测试容器，因此只要项目不是用于生产，就不需要专用的安全工具，也不需要改变以往安全策略。与往常一样，开发人员只需确保安全编码。但是，这个阶段安全也是声明式的和自动化的，是开发工作流程的一部分，而不是在完成应用构建后才解决安全问题。
虽说，在该阶段安全并不太重要，也不会犯什么错误。但是，如果组织机构打算扩展容器化项目，则需要确保让每个人都了解，安全风险和复杂性会在扩展后迅速增加。在第1阶段和第2阶段之间的安全挑战存在巨大差异的，这会让许多组织机构措手不及。
第2阶段：正式启动
在这个阶段，容器化已不再是个别开发人员的业余项目，而是由团队或业务部门开展一部分正式项目。这时，开发团队会用容器创建一个用于生产的新应用或将现有应用容器化。
大多数组织机构在开发其第一个容器化应用时，可能会使用下列其中一种方法：
将现有应用容器化
将现有应用的一部分内容容器化
从头开始在容器中开发新应用
无论开发团队采取哪种方式，这一阶段属于概念验证阶段，主要了解云原生技术会带来效益，以及应用是如何在容器中运行的。
开展一个正式项目，就需要多人合作，这时就有必要建立一个镜像仓库了。组织机构可以创建私有镜像仓库，通过策略规定谁可以访问镜像或镜像仓库，确保镜像来源可信。毕竟攻击者通常会通过镜像仓库中的受损镜像，获得对某个应用的初始访问。
这个阶段的第一个核心问题是认知偏差。从开发人员到习惯使用传统工具的安全专家，几乎没有人完全了解容器中可能出现潜在安全问题。这种知识或技能上差距会导致公司“所采取的安全”措施与“应该采取的安全措施”之间会出现差距。
这一阶段的第二个核心问题是没有做好未来规划。只考虑当前阶段所需的工具和安全需求，而没考虑容器化项目扩大使用范围之后所需的安全能力。公司在此阶段必须考虑以下注意事项：
合规策略。容器安全不只是使用安全工具就可以彻底解决，还必须制定一些策略，这样才能够确保在整个容器生命周期中落实合规要求。虽说大多数公司早已经制定了一套安全策略来管理应用开发，但也需要根据容器化应用的特定环境，修改安全策略，满足容器安全需求。
漏洞管理。在开发过程中，漏洞管理最重要的环节就是镜像扫描。不同的扫描工具，其扫描的粒度也不同。有些扫描工具能够发现操作系统漏洞和某些特定语言才会有的漏洞，而有些却无法扫描每个镜像层或某些开源软件包。
配置管理。在该阶段，DevOps和安全团队可以采用CIS基准中针对Docker和Kubernetes的配置指南。在该阶段，团队可能仍会手动进行配置管理，但是自动执行配置检查的工具将改善安全状况并减少运营工作量。
第3阶段：生产部署
到这个阶段，组织的第一个应用已投入生产运行。编排工具开始成为容器化应用生产部署的一个关键部分。使用Kubernetes、MESOS、Swarm等工具可以自动执行与容器运行相关的大多数操作任务。以Kubernetes为例，当容器在Kubernetes中运行时，它们被打包在Pod单元中。Pod可以包含一个或多个容器，但是同一Pod中的所有容器将共享相同的资源和本地网络。
虽然编排工具可以让容器应用更具弹性并易于扩展，但编排工具的使用也带来了其自身的威胁向量。编排工具本身就会引入漏洞，而且其配置也会对组织机构的整体安全状况产生很大影响。此外，编排工具的默认配置并不安全，如果忽略这些默认配置会带来巨大的安全风险。例如，Kubernetes的Kubeconfig文件是攻击者获得对应用的初始访问的一种常用方法。
在此阶段，要实现容器和编排工具的安全性，团队必须注意事项：
扩展配置管理，在此阶段，还需要加强容器和编排工具的配置管理。对于容器，需要做到以下几点：
•确保实现正确的容器配置，不会产生计划之外的特权用户
•以非root用户身份运行容器
•在容器中使用只读根文件系统
•使用秘钥管理工具，而不要将秘钥存储在镜像中
•调整容器的权限，确保访问限制尽可能严格
•设置容器的内存和CPU限制，让其能够满足功能需要求，但不能再执行其他操作
对于编排工具(以Kubernetes为例)：
•使用命名空间隔离资源
•限制Pod之间的通信
•使用Pod安全策略限制Pod可以实现的功能
设置运行时安全。应用投入生产后，必须能够检测到应用中出现异常行为，这可能是发生安全事件的前兆，包括：
•容器中运行了哪些进程
•是否有足够的信息来评估每个容器的风险并相应地确定修复的优先级
•是否存在异常网络流量，是否存在策略太宽松，导致发生安全事件后影响范围过大
设置网络分段。如何管理网络分段将取决于具体应用，但是网络分段的原理没有变化。应允许每个Pod仅与执行其功能所需的内部或外部资源进行通信。
满足合规需求。合规要求取决于应用的功能以及所在的行业。
第4阶段：快速扩容
在第一个应用投入生产取得成功后，组织机构就会将更多的应用容器化，然后投入生产。这时，容器化所涉及的工程师和团队的数量增加了。
在这一阶段，复杂性成为主要问题。复杂性不仅会给安全带来挑战，还会给事件响应和合规带来挑战。在该阶段，组织机构的治理策略对于确保开发、测试、部署和运行应用的标准工作流程至关重要。这些策略包括安全防护，确保在整个组织机构中统一安全处理，并最大程度地降低个人错误的风险。
在这一阶段，应主要注意以下方面：
自动化至关重要。随着公司处理的集群越来越多，手动进行配置管理或手动筛选原始事件数据来分析运行时行为，已不太可行。自动化变得尤其重要，通过自动化工具实现统一行安全策略是唯一可行方法。
更复杂的合规要求。在此阶段，重要的是要追踪，哪些应用或微服务要满足哪些合规要求，并通过合规检查来查看它们是否满足合规要求。
服务隔离和分段。随着服务数量的增加以及合规和安全生态系统变得越来越复杂，在服务之间进行适当的流量隔离和分段至关重要。
第5阶段：在全组织机构范围内采用容器
这个阶段，所有新应用都在容器中开发，并且还可能将现有应用移入容器。组织机构将在基础结构和安全方面遇到新问题。在该阶段，大多数组织机构将考虑不只是使用编排工具来进行编排。他们将使用服务网格之类的技术来管理服务之间的交互方式，并了解各个服务的行为以及服务之间的通信。
随着将更多层(例如Kubernetes和服务网格)添加到堆栈中，有太多的按钮需要控制，已无法再用手动控制，因此自动化变得至关重要。在该阶段，优化和自动化至关重要。组织机构应不断寻找简化开发和运营的流程，简化与编排工具的交互界面，并实现重复性工作的自动化运行。
例如，容器和编排工具的默认配置一般不太安全，因此公司需要依靠自动化来确保，在公司范围内统一实行符合其标准和配置的安全规定。在第5阶段新加入的其他技术层也有一套针对他们自身的配置、隔离和漏洞管理的最佳实践办法。
在容器化进程中，这一阶段成熟度最高，所有新开发都是在容器中完成的，因此，每个人都会步入一个未知的世界，出现第二次技能差距。每次将新的层或技术添加到堆栈中时，都会产生新的学习曲线。同时，随着应用变得越来越复杂，新的威胁向量可能会出现。组织机构需要确保他们拥有的安全工具能够随着它们添加这些新技术，增强容器安全。因为随着应用控件的复杂性增加，可见性和自动配置管理的重要性成倍增加。
三、做好容器化进程中每一步的安全
任何组织机构都无法实现绝对的安全，但是需要在容器化进程中，最大限度地确保容器安全。很多时候，做好容器安全的关键不在于技术，而在于各团队之间协作，以及对安全是否足够重视。
在早期阶段就重视安全。组织机构需要采用“安全左移”的方法，将安全从一开始就集成到开发过程中来，这在容器化过程的任何阶段都是很有用的。在开发过程中尽早关注安全不仅有助于提高安全性，而且，还可以减少在部署过程中在最后一刻出现意外情况。
加强与安全团队的协作。安全团队应该与DevOps团队合作，这种协作在开发过程的每个阶段都很重要。安全团队不应该只专注于发现问题所在，更应该成为内部培训师，加强DevOps团队对安全的理解。
预测未来的需求。组织机构不应该等到应用投入生产，才去关注容器安全。总是在发生安全事件后，才去打补丁，这样会让组织机构总会暴露在一些风险之中。
明确安全的最终负责人。为提高安全效率，安全要采用一种灵活的责任制。不同类型的应用可能需要不同的结构，但是在每种情况下，都必须指定一个人作为安全主管。共同承担安全责任可能会导致所有人觉得自己不负责安全问题。
准确评估不同应用和基础架构的安全需求。每个应用的安全需求不尽相同。面向公众的应用比内部应用遭受的风险更大;受到严格监管的行业比其他行业的组织机构更需要增强安全性。因此，要确定组织机构要规避风险，需要实现什么级别的安全性。
四、总结
容器作为一种轻量化、可移植的虚拟技术，使用非常便捷，越来越多的企业选择使用容器技术。但在组织机构内不同的容器化阶段，该采取怎样的安全措施，很多企业并没有一个明确的路线图。本文介绍的容器安全成熟度模型，将容器安全分为五个阶段，介绍了每个阶段面临的安全挑战，以及应该采取的安全措施，希望能够让正在进行容器化的各个企业，加强对容器安全的了解，有效应对安全挑战。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
