我们需要关注Docker中的安全问题吗？这个得具体分析。Docker拥有相当强大的安全保障能力，因此如果大家只使用官方Docker镜像而且不需要进行机器间通信，就完全没必要为安全而担心。

但是，如果大家使用的是非官方镜像、提供文件或者运行应用程序，情况就完全不同了。在这类场景中，我们必须对Docker安全性建立起充分的了解。

我们的主要安全目标，在于防止恶意用户获取有价值信息或者造成严重破坏。为此，我们将立足多个关键领域分享Docker安全最佳实践。通过本文，大家将掌握超过20项重要的Docker安全心得！

在第一节中，我们主要关注以下三个方面：

Access management（访问管理）
Image safety（镜像安全）
Management of secrets（保密信息管理）

首字母相连，就是AIM。

首先，我们来聊聊容器访问限制问题。

访问管理——限制权限

在启动一套容器后，Docker会创建一个命名空间组。命名空间的作用是防止容器中的进程被主机上的其他用户/容器看到或者影响。换言之，命名空间正是Docker实现不同容器间隔离的主要方式。

Docker还提供私有容器网络，用于防止同一主机上其它容器的网络接口错误获得访问权限。

由此，Docker容器建立起了自己的隔离体系——但是，您的用例仍然算不得高枕无忧。

良好的安全性，意味着必须遵循最低权限原则。您的容器应该具备完成任务的必要功能，但除此之外再无其它功能。不过麻烦在于，一旦对能够在容器中运行的进程加以限制，容器很可能无法完成正常任务所需要的各项操作。

目前，我们可以通过多种方式调整容器权限。首先，避免以root身份运行（或者在必须使用root身份时，避免re-map）。第二，利用—cap-drop以及—cap-add进行功能调整。

避免root并调整功能，已经基本可以满足大家对于权限限制的需求。但也有一部分高级用户可能希望调整默认的AppArmor以及seccomp配置文件。受本文篇幅所限，这里就不深入讨论这种情况啦。

避免以root身份运行

Docker的默认设置认为用户在镜像中以root身份进行操作。但大多数人并没有意识到这种情况的危险性。这意味着攻击者能够轻松访问敏感信息甚至是系统内核。

作为一项通行的最佳实践，请千万不要以root身份运行容器。

“防止容器内权限提升攻击的最佳方法，就是将容器应用配置为以非高权限用户身份运行。”——Docker说明文档

大家可以在build时通过以下命令指定一个非root用户ID：

docker run -u 1000 my_image

其中的—user或者-u标记，用于指定用户名或者用户ID。只要用户ID还不存在，这条命令就能顺利起效。

继续看这段命令，其中的1000是任意取值的非高权限用户标识。在Linux中，用户标识的一般取值在0到499之间。这里之所以选择超过500的标识，是为了避免其被选定为默认系统用户。

相较于通过命令行设置用户，更好的办法是通过root对镜像中的用户进行变更。如此一来，大家就不必在build时重复设置。在执行完要求使用需要root权限功能的Dockerfile指令后，我们接下来只需要在镜像里烧录USER Dockerfile指令即可。

换言之，首先安装必要的软件包，而后切换用户。例如：

FROM alpine:latest
RUN apk update && apk add --no-cache git
USER 1000
…

如果大家必须以root用户身份在容器内运行某些进程，则可以在Docker主机上将root身份re-map至某个权限相对较低的用户。具体请参阅Docker说明文档。

您可以通过变更功能的方式为用户授权必要的权限。

功能

功能，是指一组获准进程的集合。

我们可以通过命令行利用—cap-drop以及—cap-add进行功能调整。最佳策略是利用—cap-drop all清空容器的所有权限，再利用—cap-add逐一添加必要功能。

大家可以在运行时中调整容器的功能。例如，要删除使用kill命令停止容器运行的功能，大家可以通过以下命令移除该默认功能：

docker run --cap-drop=Kill my_image

请避免为进程提供SYS_ADMIN及SETUID权限，因为这两种权限会带来巨大的影响。有这两种功能在，用户几乎相当于拥有了root权限（移除这些功能的意义与避免使用root权限相同）。

另外，请禁止容器使用1到1023之间的端口，因为大多数网络服务都运行在这一范围之内。未授权用户可以监听登录等内容，并运行未经授权的服务器应用程序。此外，编号较低的端口在运行中还需要获取root身份，或者被明确赋予CAP_NET_BIND_SERVICE功能。

要查找容器中是否存在高权限端口访问，大家可以使用inspect。只需要运行docker container inspect my_container_name命令，我们就能看到关于已分配资源与容器安全配置文件的大量细节信息。

点击此处可了解更多关于Docker权限的参考资料。

与Docker中的大多数设置一样，我们最好是以自动以及自我记录的方式通过文件进行容器配置。利用Docker Compose，大家可以在服务配置当中指定某项功能，例如：

cap_drop: ALL

或者，大家也可以在Kubernetes文件中进行调整，详见此处的说明信息。

若需了解完整的Linux功能清单，请点击此处。

访问管理——资源限制

另外，我们也可以限制容器对系统资源（例如内存以及CPU）的访问。如果没有资源限制，容器会很快耗尽一切可用的内存。万一发生这种情况，Linux主机内核将提示内存意外耗尽，并终止内核进程。这可能导致系统整体崩溃。大家可以想象，不少攻击者都利用这种方式尝试关闭目标应用程序。

如果我们在同一台计算机上运行多套容器，则应精心限制各个容器所能使用的内存与CPU资源。如果容器内存不足，其将关闭；容器关闭可能导致应用程序崩溃，并直接影响到用户的体验。因此，我们有必要采取隔离机制，防止主机内存不足引发的容器环境崩溃。

Docker Desktop CE for Mac v2.1.0提供默认资源限制功能。您可以在Docker图标->首选项下访问该功能。接下来，您可以点击“资源”选项卡，并通过滑块调整资源限制水平。

Mac上的资源设置界面

或者，大家也可以通过指定—memory标识或者-m通过命令行进行资源限制，命令后面跟上数字加度量单位即可。

4m代表着4 MiB，这是容器所能设置的最低分配内存量。MiB要比MB略大一点。目前说明文档的内容有误，希望维护人员在读到本文时已经接受我的修复补丁。

To see what resources your containers are using, enter the command docker stats in a new terminal window. You’ll see running container statistics regularly refreshed.

状态界面

在引擎盖下面，Docker正使用Linux控制组（cgroups）实现资源限制。这项技术已经得到了无数实践场景的验证，相当可靠。
感兴趣的朋友可以点击此处了解Docker中的资源限制机制。

镜像安全

从Docker Hub当中提取镜像，就像是邀请外人到自家作客。虽然不太安全，但有时候却非常必要。

使用可信镜像

镜像安全的第一原则，就是只使用您信任的镜像。那么，我们如何判断哪些镜像值得信赖？

官方镜像无疑是个理想的安全保障选项。这类镜像包括alpine、ubuntu、python、golang、redis、busybox以及node。这些镜像都已经拥有上千万的下载量，而且无数双眼睛在密切关注它们的动向。

Docker解释称：

Docker赞助了支专门的团队，负责审查并发布官方镜像中的所有内容。该团队与上游软件维护人员、安全专家以及更广泛的Docker社区开展合作，以确保这些镜像安全可靠。

减少你的攻击面

类似于使用官方镜像，大家也可以选择使用最小基础镜像。

由于代码量更少，因此存在安全漏洞的可能性就更低。较小、复杂度较低的基础镜像，其透明度也更高。

了解Alpine镜像里有些什么，要比了解您朋友的镜像里有什么更简单，而这又比弄清朋友的朋友使用的镜像里有什么更简单。总之，关系越单纯，解决起来越容易。

同样的，只安装您真正需要的软件包。这样能够减少攻击面，并加快镜像的下载与构建速度。

要求使用签名镜像

您也可以使用Docker内容信任功能对镜像进行签名。

Docker内容信任功能强制要求用户使用包含签名的镜像，无签名镜像将无法使用。可信的来源包括由Docker Hub提供的官方Docker镜像，以及来自用户的可信来源签名图像。

Docker在默认情况下会禁用内容信任功能。要启用这项功能，请将DOCKER_CONTENT_TRUST环境变量设置为1。在命令行中运行以下命令：

export DOCKER_CONTENT_TRUST=1

现在，我尝试从Docker Hub下载自己未签名的镜像时，系统即会阻止这项操作。

Error: remote trust data does not exist for docker.io/discdiver/frames: notary.docker.io does not have trust data for docker.io/discdiver/frames

这是一种保护自己的有效方式。感兴趣的朋友可以点击此处了解内容信任功能。

Docker通过对内容进行加密校验的方式存储及访问镜像。这项超酷的内置安全功能，可以防止攻击者创建冲突镜像。

管理保密信息

您的访问受到限制，您的镜像也安全可靠，接下来就是照顾好保密信息了。

管理敏感信息的头号原则：不要将其纳入镜像。恶意人士能够比较轻松地从代码库、日志以及其它位置找到这些未经加密的敏感信息。

原则二：不要在敏感信息中使用环境变量。任何可以通过docker inspect或者exec进入容器的家伙，都将能够窥探你的秘密。任何人也都可以通过root身份运行这些命令。虽然之前提到了应该严格控制root身份的分发，但我们得留点冗余空间，这也是实现良好安全性的必要一步。一般来讲，日志会转储环境变量值，大家肯定不希望自己的敏感信息被到处传播。

Docke存储卷在这方面表现出色。Docker说明文档也推荐利用它访问敏感信息。存储卷能够去除docker inspect与日志记录带来的风险。但是，root用户仍然能够窥探到你的秘密。总体来说，存储卷是个相当不错的解决方案。

但比存储卷更好的，是使用Docker secrets。这里的保密信息都将接受加密。

某些Docker说明文档中提到，我们只能在Docker Swarm中使用secrets功能。但实际情况并非如此，没有Swarm，我们也能享受Docker中的secrets功能。

如果大家只需要把保密信息存放在镜像里，则可以使用BUildKit。BuildKit是一款远超现有Docker镜像构建工具的出色后端。它能够显著缩短构建时长，并提供其它一系列出色的功能——包括build-time secrets支持。

BuildKit是一款相对较新的工具——直到Docker Engine 18.09版本才第一次出现。我们可以通过三种方式将BuildKit指定为后端。未来，BuildKit将成为Docker的默认后端选项。

利用 export DOCKER_BUILDKIT=1命令将其设置为环境变量。
在使用build或者run命令时加上DOCKER_BUILDKIT=1。
默认启用BuildKit。将/etc/docker/daemon.json中的配置设置为true：{ “features”: { “buildkit”: true } }。而后重启Docker。
接下来，您就可以在构建时通过—secret标识使用secrets功能了：

docker build --secret my_key=my_value ,src=path/to/my_secret_file .

您的文件将把保密信息指定为键值对的形式。

这些保密信息并不会被保存在最终镜像中，同时也不会出现在图像构建缓存当中。安全第一嘛！

如果大家需要将保密信息引入运行中的容器（而不只是镜像构建过程），则可使用Docker Compose或者Kubernetes。

利用Docker Compose，我们可以将保密信息的键值对添加至某项服务中，并指定对应的secret文件。以下示例来自Stack Exchange上关于Docker Compose secrets提示的相关素材。
例如将保密信息放置在docker-compose.yml当中：

version: "3.7"

services:

  my_service:
    image: centos:7
    entrypoint: "cat /run/secrets/my_secret"
    secrets:
      - my_secret

secrets:
  my_secret:
    file: ./my_secret_file.txt

之后即可利用 docker-compose up --build my_service正常启动Compose。

如果大家使用Kubernetes，它也支持secrets管理功能。Helm-Secrets能够帮助我们更轻松地在K8s当中实现保密信息管理。此外，K8s还提供基于角色的访问控制（RBAC）功能，这一点与Docker Enterprise相同。RBAC使得Secrets访问流程更具可管理性，同时也为团队提供了更强的安全保障。

保密信息的另一项最佳管理实践是利用Vault等secret管理服务。Vault是一项由HashiCorp推出的服务，专门用于管理保密信息。其还能为保密信息设置时间限定。感兴趣的朋友可以点击此处了解更多关于Vault Docker镜像的细节信息。

AWS Secrets Manager 以及其他云服务供应商提供的类似产品，也能帮助大家在云端保护自己的保密信息。

请记住，管理保密信息的要诀，在于保持其保密性质。绝对不要将其烧录至镜像当中，或者转换为环境变量。

更新

与其它代码一样，我们应当保证镜像中的语言与库的及时更新，从而享受最新安全修复补丁带来的保障。

如果大家在镜像当中引用基础镜像版本，请确保该基础版本始终保持更新。

同样的，大家还应及时更新自己的Docker版本，以便修复并增强功能，进而实现新的安全功能。

最后，保证您的主机服务器软件及时更新。如果在托管服务上运行容器系统，服务商应该会替您完成更新工作。

更高的安全性，源自更及时的更新维护。

考虑使用Docker Enterprise

如果您的组织当中有很多员工和一大堆Docker容器，那么Docker Enterprise可能更适合您。管理员可以借此为所有用户设置策略限制。Docker Enterprise提供的RBAC、监控与日志记录功能也将使您的团队更轻松地实现安全管理。

在Enterprise的帮助下，您还可以在Docker Trusted Registry中行托管您的镜像。Docker提供内置安全扫描，可确保您的镜像中不存在已知漏洞。

Kubernetes虽然也免费提供一系列类似的功能，但Docker Enterprise还具有其它与容器及镜像相关的附加安全功能。最重要的是，Docker Enterprise 3.0发布于2019年7月，其中包含“具有合理安全默认设置”的Docker Kubernetes服务。

其它提示

不要以-- privileged的方式运行容器，除非您需要在Docker容器之内运行Docker，而且很清楚自己到底在干什么。

在Dockerfile中，使用COPY而非ADD。ADD会自动提取压缩文件，并可以从URL处复制文件。COPY没有这些功能。尽量避免使用ADD，这能帮助您免受远程URL与Zip文件攻击的影响。
如果您在同一服务器上运行有其它进程，务必将其运行在Docker容器当中。
如果您使用Web服务器与API来创建容器，请认真检查各项参数，以确保不会意外创建不需要的容器。
如果您公开REST API，请使用HTTPS或者SSH保护API端点。
考虑使用Docker Bench for Security进行检查，以了解您的容器是否遵循安全准则以及具体遵循程度。
仅在存储卷中保存敏感数据，绝不要将其保存在容器中。
如果使用具有网络功能的单主机应用程序，请不要使用默认桥接网络。其存在技术缺陷，不适用用于生产。一旦公布端口，则桥接网络上的所有容器都将可供外部人士访问。
使用Lets Encrypt for HTTPS进行证书交付。点击此处查看NGINX示例。
如果只需要读取存储卷，注意将其挂载为只读状态。点击此处查看具体操作方式。

总结

大家可以了解到多种能够提升Docker容器安全水平的方法。安全性不是那种一次部署、无需再管的机制。我们需要时刻保持警惕，方可实现镜像与容器的长治久安。

考虑安全性时，别忘了AIM Access management（访问管理）

避免以root身份运行。如果必须使用root，请配合re-map。
先删除所有功能，再添加必要功能。
如果需要细粒度权限调节，请深入了解AppArmor。
资源限制。

2. Image safety（镜像安全）

使用官方、高人气以及最小基础镜像。
不要安装任何您不需要的东西。
要求对镜像进行签名。
保持Docker、Docker镜像以及其它软件及时更新。

3. Management of secrets（保密信息管理）

使用secrets或者存储卷。
考虑使用Vault等secrets管理器。

保证Docker容器安全的实质，就是利用AIM建立安全体系。

别忘了更新Docker、语言与库、镜像以及主机软件。最后，如果您需要在团队当中使用Docker，可以考虑选择Docker Enterprise。

原文链接：

https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57

创作场景

Docker 容器安全的“终极武器”——AIM