企业级容器安全最佳实践

由于容器虚拟化技术可以充分利用硬件资源，对于开发团队就像梦想照进了现实。尽管容器化没有推翻虚拟机在企业应用开发和部署上的地位，但是 Docker 等工具在实现开发、测试和部署大规模现代软件的速度和敏捷性方面大展身手。 Docker 容器具有诸多优点：无需复杂的 hypervisor 、可移植性、资源隔离性、轻量级、开放标准、完美适应微服务架构。众多的应用通过容器隔离起来，相互独立地运行在同一台宿主机上，哪家公司不喜欢呢？

容器的速度和易用性带来了无限的可能，开发团队很容易被吸引。迄今为止， Docker 容器的下载量已经超过 4 个亿。但是，对于容器化的担忧真真切切地存在。如果你被一时的热情冲昏了头脑，反而会适得其反，无法利用容器的潜力，阻碍开发的快速迭代和创新。如果你的公司决定要安全地拥抱 docker ，你需要谨慎地处理安全问题并避免牛仔编程文化。

需要澄清的是， Docker 声称自己是安全的，但关键在于你必须负责任地使用。当你开始使用 Docker ，你会在镜像仓库（ repos ）发现有很多可下载的模板(“ images ”)，它提供了一条编写微服务应用的捷径，从而大大加快开发速度。问题是你如何判断哪些 images 是安全的，是否包含漏洞。个人开发者可能不太关心 Image 的漏洞，但是对于企业，安全和数据审查是至关重要的，必须有人维护。那么问题就来了：如何将企业的安全策略应用于 Docker 呢？

Docker 最佳实践

非营利组织网络安全中心（ CIS ）针对 docker 的安全配置发布了一个详尽的、超过 100 页的基准测试结果，有一些特定的点需要关注一下。

1. 关注你使用的镜像（ images ）

所有容器都来源于镜像，比较典型的是操作系统及其附属项（ shell, default users, libraries, 依赖包）。正如 Docker 安全的一个页面上所描述： Docker 容器运行的一个主要风险是：默认设置提供的隔离可能是不完善的，一方面是因为配置参数时只能考虑单个因素，另一方面镜像可能包含操作系统漏洞。因此，这需要使用者去修改容器配置和验证镜像——这条规则适用于每一个容器。

2. 实现自动化部署的代理（ agent ）

Agent 可以协助你设置容器的安全参数，因为它能够自动获取镜像（ image ）的信息并将其展现给你。虽然 Docker Hub 上的镜像在不断检查、共享和更新，你不能依赖邮件列表和问题报告来发现和管理漏洞。单个容器的安全仍然需要用户自己去负责，所以你需要自己去检查依赖。你的镜像仓库里有哪些镜像，镜像是如何运作的，你都应该理解，并且拥有自己的扫描和检查机制。 Agent 很适合做这项工作，因为不管是运行在宿主机上，还是容器中， Agent 的系统开销都很小。

3. 以什么方式运行容器

运行容器最安全的方式之一是是在只读模式下运行，容器不能被修改，而对于其他人访问的权限都没有。如果你在只读模式下运行，就不需要给每个容器配置一个 agent 了，也可以重用你验证过的镜像。如果容器以读 /写模式运行，最好的做法是在每个容器一个代理。同时设定一些规则，不允许从公有仓库下载镜像，也不允许 root 下运行容器。

4. 管理容器与外部的交互

一个运行的容器可以暴露端口到宿主机的任何一个网卡(network interface)——这是极其危险的。一个解决办法是只暴露宿主机的一个网卡到外网，任何外部来的请求，比如入侵检测，入侵预防、防火墙、负载均衡等均通过这个网卡处理。容器端口也应该绑定到宿主机上一个授权的可信端口。

5. 需要熟练的 Linux 管理技巧

Docker 支持很多安全增强选项，但默认情况下是没有设置的。因此，你需要一个 Linux 专家来管理基础设施，以保证 Docker 容器正常运作，并防止宿主机被误配置。

总的来说，企业使用 Docker 的最佳策略是结合 CIS 基准安全测试与企业现有的安全策略，为企业内的 Docker 容器建立一套安全配置“姿势”，并给开发团队创造一个安全的实验环境。

本文由时速云工程师赵帅龙编译，原文链接： https://dzone.com/articles/docker-and-enterprise-security-establishing-best-p