现代计算的发展可以分为四次浪潮，每次浪潮的到来都促进了IT技术的快速发展。伴随效率的提升，也引发了新的安全挑战。

• 第一次浪潮：发生在1990年代之前，最明显的特征是在裸机服务器上运行C/S架构。通常，服务器上只有一个操作系统，也只运行一个应用。

  
  

• 第二次浪潮：始于2000年左右，功能完整的操作系统虚拟化技术的出现。虚拟化的发展改变了服务器市场，迎来了虚拟计算的时代。

  
  

• 第三次浪潮：以云和容器技术为主要特征。容器能够得到广泛采用，主要是有两个推动因素：在DevOps的推动下，需要加快产品的上市时间；以及各类应用要实现在不同云端之间的可移植性。

  
  

• 第四次浪潮：功能即服务（FaaS），现在也正在快速发展，但是尚未得到企业的广泛应用。功能即服务（FaaS）不受硬件和操作系统影响，对计算能力进行了更高层次的抽象。

目前，我们处于第三次浪潮的快速发展时期，以容器为代表的云原生得到了市场的高度认可，目前正在成为新一代主流IT基础设施。多年来，开发人员已经对处理操作系统和应用依赖问题不胜其烦。容器具有很好的可移植性，通过将所有文件打包在一起，实现了“一次打包，随处运行”，有效解决了操作系统和应用依赖的打包问题。虽然容器使用率越来越高，但是相关安全建设却处于落后阶段。

一、容器安全成为云安全第一战场

云和容器之间有着本质的联系，云安全离不开容器安全，不可能脱离容器安全而单独去讲云安全。

虽然现在市场上有各类开源和商业容器安全产品，但很多点状产品只是解决了容器某一特定方面的安全挑战，完全没有把握容器安全的整体状况。例如，在容器上开发的大多数应用都是在使用各类开源和商业的IaaS和PaaS服务。但是由于缺乏对IaaS和PaaS环境的可见性，导致企业在云端面临一些风险。如果没有完整的可见性，并采取控制措施限制横向移动，则很难检测到攻击者在容器中的横向移动。

了解容器的整体堆栈可以有效缓解风险，而只注重于解决容器安全某一特定方面的点状产品则可能会因为没有全局观而捕捉不到这一风险。例如，当CVE最新公告公布了容器最新漏洞，了解整个容器的堆栈情况则可以解决这一漏洞所有信息，包括受影响的资产范围、镜像补丁的修复状态等。

二、DevSecOps：构建全生命周期的容器安全解决方案

鉴于容器和云的运行速度非常快，DevSecOps是安全团队唯一可行的途径。DevSecOps将DevOps团队和安全团队整合在一起，尽早在容器生命周期中引入安全。这种方法将安全嵌入到整个容器生命周期中：构建、部署和运行。

构建安全

在容器构建阶段集成安全是指，在构建阶段的早期引入安全检查，而不是在运行时被动地引入安全。构建阶段的安全应侧重于消除漏洞、恶意软件和不安全的代码。由于容器是由库、二进制文件和应用代码组成，因此，为组织机构建立正式的容器镜像仓库至关重要。安全团队的工作是找到镜像仓库，并迅速设置相关访问策略等安全标准。例如创建受信镜像，在DevSecOps团队之间达成一个共识流程并自动执行，确保不会从任何不受信的镜像仓库中部署任何容器。

部署安全

数据研究表明，46％的组织机构接受来自任何来源的Kubernetes Pod的流量。这一数据表明，大家对于容器部署安全认知远不如物理服务器安全部署认知，毕竟在本地部署服务器之后，极少有组织机构会将其完全开放给互联网。

在部署阶段，重点是确保团队能够将各项相关内容正确的整合在一起。容器镜像可能是没有漏洞，但是如果将镜像部署到配置不安全的Kubernetes pod中，还是会面临安全风险。只有编排工具和容器引擎都需要制定一个安全标准，方可实现部署的安全配置。此外，需要采用必要的流程和工具来实现自动化和持续监控。例如，从CIS在Docker和Kubernetes方面的安全基准入手，制定相应的部署安全策略，限制只有安全的镜像才能进入运行时。

运行时安全

运行时安全要确定运行中的容器有哪些新漏洞并了解正常情况应该是什么样子。这还包括调查0day漏洞等异常和可疑活动。有调查发现，在运维阶段修复bug的成本是在设计阶段修复成本的100倍。

如果安全团队从一开始（在构建阶段）就参与进来，那么确保运行时安全可能就没有那么复杂了。如果安全开展得晚了，现在只是被动地重点关注运行时安全，那么，依然建议从头开始检查一遍容器安全风险。确保最终的安全状态当然至关重要，但是如果只关注运行时，则可能无法从根源上解决安全问题，导致很多类似问题反复发生。

三、写在最后

在云原生环境下，容器安全必须作为整体企业云安全策略的一部分来解决。使用点状安全产品可以有效解决容器某一特定方面的安全问题，但单独解决容器和云安全问题将让组织机构忽略掉某些风险，更有效的方法是将容器安全视为云安全的一部分，通过容器安全加强云安全态势。