为什么保护容器和微服务很难
容器环境的粒度、部署速度和数据流量规模都要求采用新安全方法。
容器是一种简单方便快速的跨计算环境软件部署及运行方式。通过将应用的整个运行时环境（库、可执行程序和配置文件）容纳进来，平台和基础设施被抽象了出来，让应用或多或少地可以在任何地点运行。所有主流云提供商和现场数据中心以及混合云环境都提供容器，而且，容器还能节省下很多开支。
开发人员可用容器创建微服务，也就是应用的可重用组件。因为可重用，微服务能帮开发人员免掉重新开发的时间。另外，微服务可跨不同平台部署。
因此，容器的采纳率高毫不令人意外。但不幸的是，安全界仍在摸索容器的运行机制和最佳锁定方法。迈克菲最近针对全球1500位IT人员的调查显示，雇员数超500人的公司企业中约有80%正在使用容器，但仅66%拥有容器安全策略。事实上，今年3月CyberEdge对1200名IT决策者的调查表明，容器如今与移动设备一起成为了公司企业最大的安全挑战。
有很多原因促成了安全成为容器世界中的一大挑战。原因之一，容器的部署速度。原因之二，容器通常要求应用被分割成微服务，造成数据流量和访问控制规则复杂度的增加。原因之三，容器通常运行在云环境中，比如AWS，适用新型的安全控制措施。
容器安全工具生态系统尚不成熟，类似虚拟机和云的早期时候。公司企业需构建专属工具和基础设施来让容器安全发挥作用，需要很多资源来实现容器安全。目前并没有太多已成型的解决方案可用，也没有足够的解决方案以覆盖所有用例。
容器的生命周期很短且缺乏良性管理
容器时代，构建-测试-部署的传统软件开发过程变得无关紧要。事实上，开发人员经常从公开代码库中直接拖来现成的镜像甩到云端。
但其中有些隐性的信任级是可能不被许可的。容器镜像是很便捷的现成代码包，但提供者可能没那个时间或兴趣监测安全问题或公开版本注释。
理想状况下公司企业应有版本检查的过程，但极少有企业真的这么做。公司应该持续检查自己所用容器是否是最新版本，所有的代码是否已打上补丁并做了更新。但目前，这些责任都落到了开发人员个体身上，而且大多是人工检查。这就出现了检查上的漏洞，往往落入拖来容器运行起来就再也不管的境地。公司企业真的应该引入更加自动化的过程了。
然而，开发人员自己构建容器也没好到哪儿去。开发速度意味着根本没时间保证质量或进行安全测试。到有人注意到容器上线的时候，他们基本也就等同完事儿撤漂了。
到安全团队可以入驻的时候，容器开发生命周期可能就完结了。这是个问题，需要另一套完全不同的安全思路。
需要在开发过程早期就引入安全意识，并尽可能地自动化。比如说，如果开发人员从外部源下载镜像，在容器上线之前应对镜像进行扫描，找出所有漏洞、未修复代码和其他潜在问题。而一旦容器上线，怎样维护并监视其安全状况，监控那些与其他组件互操作的瞬时动作呢？
举个例子，云安全提供商 Skyhigh Networks。这家公司部署最新的架构栈，有各种微服务，事实上，他们一天之中可以多次部署进生产环境。一般来讲，公司企业可以进行安全测试或渗透测试，但这两种测试不适用于开发运维环境。
必须找到自动化很多功能的方法，也就是说，得能够发现所有被部署的容器，确保这些容器的所有成分都是安全的，容器所处环境也是安全的——有应用控制和应用白名单，且施以持续的监测。
迈克菲在4月RSA大会上发布的云工作负载安全平台就是干这个的。该平台保护AWS、Azure和VMWare等公共云和私有云中的Docker容器及其中的工作负载，是能够将容器与被感染工作负载隔离的第一款云工作负载解决方案。
该产品还可通过检查非必要管理员权限或未满足的加密要求，以及核查AWS存储桶是否被设为公开可读，来减小配置风险。从客户反馈来看，该平台修复速度也有了提升——加快了90%。
目前为止，几乎所有的容器安全问题都是不当配置所致，容器的最大风险就在配置上。
服务漩涡
配置管理和补丁管理很难操作，攻击者却很方便利用这些漏洞，但至少，二者都是可以解决的问题。容器问题上另一块不散的阴云，在于应用被切分成大量内部互联的微服务时所产生的复杂性。
传统整体式应用的模型下，一个应用也就一个服务和两个端口。安全人员知道黑客将会攻击的地方，防护起来也颇为方便。
但微服务模式下，服务和端口数量暴涨，需要看好的门瞬间翻了几十倍不止。而且，每道门口的实时情况也更不容易掌握了，很难分辨出来敲门的是好人还是坏人。
于是，安全重任落到了确保每一道门都关得够紧上，也就是对每个微服务应用诸如最小权限、严格访问控制、隔离和审计等等安全原则。这些东西上世纪70年代就出现了，没想到现在还需要这么做。
真是说起来容易做起来难。公司企业持续将其整体的服务分解成越来越细小的微服务，应用的数据流因而变得越来越复杂，以致难以分辨每个微服务的状态。
只要众多微服务中混进了一个硬编码的访问凭证，或者泄露了某个身份验证令牌，那整个系统顿时对黑客不设防。这是个大问题，然而人们往往没意识到该问题的严重性。
而且，随着越来越多的关键系统迁移到软件即服务的交付模式，这个问题持续发酵。公司企业将大量数据集中进自身应用中，让这些非常敏感重要的数据在微服务间流转，几乎没有人拥有对这些数据流的良好视野。Equifax就是个很好的例子，Uber也是。
容器漏洞
容器面临的安全挑战还有一个：漏洞。容器运行在共享环境中，客户不知道自己的邻居都是谁，这种情况在公共云环境下更为突出。事实上，过去几年里Docker和Kubernets容器管理系统中都发现了漏洞。
在公共云上运行容器的公司刚开始意识到这个问题，直接询问有没有什么工具能够抵御容器逃逸攻击，能够将容器相互隔离。
Portworx 2017容器采用调查中，超过70%的受访者在Linux上运行容器。管理员可用于确保容器隔离的方法包括利用Linux名字空间，以及用 Security Enhanced Linux 作为强制访问控制的补充。另外，还有名为 Linux Capabilities 的东西可以用来限制Linux系统中进程的不同访问权限。
Linux安全专家对这些概念相对熟悉，但部署容器的团队未必掌握，刚刚从Windows迁移到Linux的公司企业就更不知道这些东西了。运营自己的容器环境的公司，无论是在公共还是私有云上，至少都对自身安全设置有全权控制。但使用现成容器时，就只有信任云提供商能够搞对底层安全基础设施了。
目前为止，能让进程逃出容器的那些漏洞尚未造成重大数据泄露。但容器领域被少数几个大平台把持的事实，意味着一旦攻击者能够快速利用，仅仅1个漏洞都能造成大面积的伤害。所以，容器漏洞问题真的应认真面对，多加准备了。
原文发布时间为：2018-05-18
本文作者：nana
