保护Docker和容器基础设施安全需要打组合拳，综合运用策略、工具和审慎的应用检查。
Gartner将容器安全列为其本年度十大安全顾虑之一，或许是时候进一步审视并找出切实的容器安全实现方案了。虽然容器已面世十年，但其轻量且可重用的代码、灵活的功能和更低的开发成本，令容器的流行程度有增无减。但没有什么工具是万能的。我们不妨再仔细考察一下保护开发环境所需的各种工具、容器自身所用工具和出于监视/审计/合规目的的工具吧。
从以下几个基本步骤开始：
1. 熟悉云提供商交付的工具
第一步就是熟悉云提供商的内置安全措施，比如 Azure Security Center、谷歌Kubernetes Engine、谷歌 Cloud Security Command Center和亚马逊Inspector。其中有些是通用安全工具而非容器专用，比如 Azure Security Center。
2. 熟悉原生Docker相关安全功能
包括运用策略防止资源滥用、设置访问控制组和确保清除不必要的root权限。
3. 考虑GitHub开源项目
某些情况下，Bench Security之类检查代码中最佳安全实践的项目，以及类似seccomp的其他Linux原生工具，是节省开支的不错选择。
总有很多软件有待学习和理解，但应重点查看几个常用功能，包括为用户及最终生成的应用所设的身份及身份验证措施，以及控制这些访问权限的机制。另外，还需要能够检查并审计日志文件，要能浏览并过滤日志文件以提供有益安全态势的可操作信息。最后，还要有用于保护API密钥和SSL凭证之类秘密的底层基础设施。这些秘密必须以加密形式存储。
是不是有点头晕目眩了?这还才刚刚开始呢。想要保护公司环境中的容器，下面三个领域是你不得不仔细考虑的。
1. 保护开发环境
由于容器对开发人员而言非常有用，所以推进到DevSecOps非常有必要，但要记得在创建容器时即添加安全措施，而不是在项目匆忙上马留下诸多漏洞之后。保证应用安全从来都是最佳实践。在选择正确的安全工具之前，你需要回答以下几个重要问题：
(1) 能够自动化哪些工作流以保持应用安全?
有些工具有助于实现该操作，尤其是在编排方面。然而，很多编排工具专注于容器管理和扩展问题，未必考虑到安全细节。找到功能和防护之间的恰当平衡或许没那么容易。
(2) 应用和用户访问控制的粒度该设成多细?
这里有必要了解这些控制的实现机制及其局限。比如说，哪些代码段和容器具备root/内核访问权限，是否需要这么高的权限来完成任务。
(3) 应该使用运行时应用自防护(RASP)技术吗?
必须的。就像专注应用的RASP常规工具，有些工具专注于容器运行时应用保护，要么有静态扫描，要么利用开发环境持续集成。因为容器代码不停在变，持续集成的形式相当有用;而且拥有持续代码审计也可以在不得不修复或更新时节省大量时间。一款好RASP容器工具应能标记异常行为，缓解潜在威胁，并能够隔离特定事件以供后续进一步取证分析。
2. 防护托管着容器的底层主机
大多数情况下，这意味着运行精简版LInux，只留下必要的服务以减小潜在攻击界面。有些工具就是设计来强化主机自身的。另一个办法是采用上面提到过的Docker控制组，以及隔离名字空间以反映你的安全策略和防止容器间相互感染。有些商店使用来自云提供商的虚拟专用连接来实现该隔离操作。该过程包含应用访问级别和其他机制来隔离工作负载，以及限制每台主机上运行的容器数量。出于这个原因，有些商店甚至一台主机只运行一个容器。
3. 保护容器内容安全
这里讨论的是镜像的软件供应链。这是构建容器的基石，所以一项重要的基本功能就是要能够保证镜像源完整性防护，也就是当员工或提供原始容器镜像的开源项目对镜像做了修改时，你得清楚到底改动了哪些东西。
鉴于很多容器都在互联网上共享的事实，能够扫描容器镜像以确保不受感染是一项很有用的功能。那么，你的扫描频率如何，能不能自动化扫描呢?能从可信源获取镜像固然很好，但每个人都会犯错，意外引入安全问题是不可避免的。
不过，对有些商店，你却不用担心容器里有哪些漏洞。这听起来令人惊讶，但确实有意义——只除了一点：除非你能保证容器边界足够安全，或者你应用程序的实际代码不触及容器代码有漏洞的部分。你对自家安全工具的自信程度，可能是决定漏洞容忍度的最终因素。 |
