生产环境中安全运行Docker容器

Docker  /  管理员 发布于 7年前   147

在生产环境中，强化Docker容器的一种方法就是使它们不可变，也就是只读。安全地运行容器的其他方法还包括最小化受攻击面和应用Linux安全过程，标准Linux安全过程和针对容器环境的特定过程都要应用。

在启动容器时传入--read-only标记就可以 在只读模式下运行 它。这可以防止任何进程写入文件系统。任何试图写入的动作都会导致错误。 运行这种不可变的基础设施 也与其他软件部署流水线的最佳实践相吻合。

尽管不可变性可以阻止任何恶意脚本的执行，可以禁止通过在容器里运行的其他软件暴露出来的漏洞而引起的改动。但是在现实生产环境中，这种模式又是不是适用于应用程序呢？比如，要产生的日志文件和要使用数据库的应用程序就需要可写性。

写日志的一个可能的解决方案可以是使用一个集中的日志系统，比如Elasticsearch/Logstash/Kibana（ELK），这样所有的日志都被收集在一个中心节点，可能是在另一个容器中，就不是用户可以直接访问的了。另一种替代的方案是在启动容器时，通过使用--log-driver标记将日志导出到容器之外。对于那些需要对/tmp之类的临时目录有写入权限的应用程序，一种解决办法是在容器里为这些目录 加载一个临时的文件系统 。

终端用户不能直接访问数据库，所以风险较低。然而，这并不排除受到攻击的可能，除非面对用户的应用程序得到了强化。

在不可避免地要有一个可写的文件系统的情况下，Docker提供了审计和变化的回滚功能。在Docker容器里的文件系统是作为一系列层的堆叠。当创建一个新容器时，将在顶部添加一个新层，该层可以写入。Docker存储驱动程序隐藏了这些细节，并将它作为一个普通的文件系统交付给用户。对正在运行的容器的写入将写入此新层。这通常被称为写时拷贝（Copy-On-Write，COW）。

在Docker容器里很容易检测到配置漂移或预期的配置变更。“docker diff”命令可以显示对文件系统的更改――无论更改操作是文件添加、删除还是修改。

除了在可能的情况下运行一个只读容器，我们 还 提出以下 建议 ，以确保在生产环境中容器的安全：

• 运行一个 Alpine Linux 之类的最小的镜像，Alpine Linux是基于安全思想而设计的。它的内核上打了一个grsecurity的非官方移植的补丁。 Grsecurity 是一套对Linux内核的安全增强方法，它包括权限控制以及消除基于漏洞的内存崩溃的可能，具体方法是将那些使系统可能被攻击的方法减少到最少。
• 限制对CPU、RAM等资源的使用，以防止DoS攻击。
• 在操作系统中配置线程和进程限制。
• 采用sysctl之类标准的Linux内核强化程序。
• 每个容器中只运行一个应用程序。建议这么做，是因为它减小了受攻击面，即对于一个给定的容器，可能的漏洞数量就只取决于在该容器上运行的应用程序了。