容器因其轻量且可重用的代码，功能更灵活、开发成本更低而被得到越来越广泛的应用。Docker作为应用容器中最引人瞩目的实现方式，其优点很多，其诞生的目的就是便于持续集成和快速部署尽量减少中间环节，这也为其安全控制带来难度。

容器安全面临很多挑战：容器使用共享操作系统（OS）模型，对主机操作系统中的漏洞的攻击可能导致所有容器被攻击，且容器本身可能并不安全。基于此，金山云安全的vampire师傅整合业界思考与实践经验，形成该容器安全风险解决方案，主要阐述了常规安全基线、历史漏洞防护、防护工具推荐三个方面的内容。

目录

一、常规安全基线

1. 主机安全配置

1.1 为容器创建一个单独的分区

1.2 加固容器宿主机

1.3 更新docker到最新版本

2. 守护进程配置

2.1 不使用不安全的镜像仓库

2.2 docker守护进程配置TLS身份认证

2.3 启用docker客户端命令的授权

2.4 禁用就仓库版本V1上的操作

3. 容器镜像和构建文件

3.1 创建容器的用户

3.2 扫描镜像漏洞并且构建包含安全补丁的镜像

3.3 镜像中删除setid和setgit权限

3.4 在dockerfile中使用copy而不是add

3.5 涉密信息不存储在dockerfile中

4. 容器运行时保护

4.1 不使用特权容器

4.2 SSH不在容器中运行

4.3 特权端口禁止映射到容器内

4.4 docker exec命令不能使用特权选项

4.5 docker exec命令不能与user选项一起使用

4.6任何容器内不能安装docker套接字

二、历史漏洞防护

三、防护工具推荐

由于内容过多篇幅较长，将分为2篇推送，本篇为上篇主要介绍容器的常规安全基线。

常规安全基线

1. 主机安全配置

1.1 为容器创建一个单独的分区

描述：
所有 Docker 容器及数据和元数据都存储在/var/lib/docker 目录下。默认情况下，/var/lib/docker 将根据可用性挂载在/或/var 分区下。

安全考虑：

Docker 依赖于/var/lib/docker 作为默认目录，其存储所有Docker相关文件，包括镜像文件。该目录可能会被恶意的写满，导致 Docker、甚至主机可能无法使用。因此，建议为存储 Docker 文件创建一个单独的分区（逻辑卷）。

审计方法：

grep /var/lib/docker /etc/fstab

结果判定：

应该返回/var/lib/docker 挂载点的分区详细信息

修复建议：

新安装docker 时，为/var/lib/docker 挂载点创建一个单独的分区。对于先前安装的系统，请使用逻辑卷管理器（LVM）创建分区。

默认值：

默认情况下，/var/lib/docker 将根据可用性挂载在/或/var 分区下

影响：

None

参考链接：

http://www.projectatomic.io/docs/docker-storage-recommendation

1.2 加固容器宿主机

描述：

容器在 Linux 主机上运行。容器主机可以运行一个或多个容器。加强主机以缓解主机安全配置错误是非常重要的。

安全考虑：

应遵循基础架构安全最佳实践并加强宿主机操作系统，保证主机系统的安全确保主机漏洞得到控制。若不加固主机系统可能导致各类安全问题。

审计方法：

确保遵守主机的安全规范。询问系统管理员当前主机系统符合哪个安全标准。确保主机系统实际符合主机制定的安全规范。

结果判定：

查看主机加固记录。

修复建议：

请参照主机安全标准加固主机。

默认值：

默认情况下，主机只有默认配置，并未进行安全加固。

影响：

None

参考资料：

https://docs.docker.com/engine/security/security/

https://learn.cisecurity.org/benchmarks

https://docs.docker.com/engine/security/security/#other-kernel-security-features

https://grsecurity.net/

https://en.wikibooks.org/wiki/Grsecurity

https://pax.grsecurity.net/

http://en.wikipedia.org/wiki/PaX

1.3 更新docker 到最新版本

描述：

Docker 软件频繁发布更新，旧版本可能存在安全漏洞。

安全考虑：

通过及时了解 Docker 更新，Docker 软件中的漏洞可以得到修复。如果不及时对Docker 进行更新可能会让现有的Docker 软件受到攻击。风险包括不限于权限提升、未授权访问或其他安全漏洞。所以需要跟踪新版本并根据需要进行更新。

审计方法：

执行以下命令验证Docker 版本是否为必要的最新版本。

docker version

结果判定：

和最新版本进行对比，查看是否为最新

修复建议：

跟踪 Docker 发布并根据需要进行更新。

影响：

对Docker版本更新进行风险评估，了解它们可能会如何影响Docker操作。请注意，有些使用Docker的第三方产品可能需要支持较老版本的Dokcer。

默认值：

没有默认设置

参考资料：

https://docs.docker.com/engine/installation/ https://github.com/moby/moby/releases/latest

https://github.com/docker/docker-ce/releases/latest

2. 守护进程配置

2.1 不使用不安全的镜像仓库

描述:

Docker在默认情况下，私有仓库被认为是安全的。

安全考虑:

一个安全的镜像仓库建议使用TLS。在/etc/docker/certs.d//目录下，将镜像仓库的CA证书副本放置在Docker主机上。

没有有效的镜像仓库证书或不使用TLS的镜像仓库是不安全的，不应该在生产环境中使用任何不安全的镜像仓库。不安全的镜像仓库中的镜像可能会被篡改，从而导致生产系统可能受到损害。此外，如果镜像仓库被标记为不安全，则”docker pull”，“docker push”和“docker search”命令并不能发现，那样用户可能无限期地使用不安全的镜像仓库而不会发现。

审计方法:

执行以下命令，了解是否使用不安全的仓库

ps -ef | grep   dockerd

结果判定:

确保“--insecure-registry”参数不存在。

修复建议：

不要使用任何不安全的镜像仓库。

例如，不要像下面那样启动   Docker 守护进程：

dockerd --insecure-registry   10.1.0.0/16

影响：

None

默认值：

默认情况下，Docker 假定所有的本地镜像仓库都是安全的。

参考资料：

https://docs.docker.com/registry/insecure/

2.2 Docker守护进程配置TLS身份认证

描述：

可以让Docker守护进程监听特定的IP和端口以及除默认Unix套接字以外的任何其他Unix套接字。配置TLS身份验证以限制通过IP和端口访问Docker守护进程。

安全考虑：

默认情况下，Docker守护程序绑定到非联网的Unix套接字，并以root权限运行。如果将默认的docker守护程序更改为绑定到TCP端口或任何其他Unix套接字，那么任何有权访问该端口或套接字的人都可以完全访问Docker守护程序，进而可以访问主机系统。因此，不应该将Docker守护程序绑定到另一个IP/端口或Unix套接字。如果必须通过网络套接字暴露Docker守护程序，请为守护程序和DockerSwarmAPI配置TLS身份验证。

审计方法：

ps -ef | grep dockerd

结果判定：

确保存在以下参数：

'--tlsverify'  '--tlscacert'  '--tlscert'   '--tlskey'

修复措施：

按照Docker文档或其他参考中提到的步骤进行操作。

影响：

需要管理和保护 Docker 守护程序和 Docker 客户端的证书和密钥。

默认值：

默认情况下，未配置TLS认证。

参考资料：

https://docs.docker.com/engine/security/https/

2.3 启用Docker客户端命令的授权

描述：

使用本机Docker授权插件或第三方授权机制与Docker守护程序来管理对Docker客户端命令的访问。

安全考虑：

Docker默认是没有对客户端命令进行授权管理的功能。任何有权访问Docker守护程序的用户都可以运行任何Docker客户端命令。对于使用Docker远程API来调用守护进程的调用者也是如此。如果需要细粒度的访问控制，可以使用授权插件并将其添加到Docker守护程序配置中。使用授权插件，Docker管理员可以配置更细粒度访问策略来管理对Docker守护进程的访问。Docker的第三方集成可以实现他们自己的授权模型，以要求Docker的本地授权插件（即Kubernetes，Cloud Foundry，Openshift）之外的Docker守护进程的授权。

审计方法：

ps -ef | grep dockerd

结果判定：

如果使用 docker 本地授权，可使用--authorization-plugin 参数加载授权插件。

修复建议：

1.安装/创建授权插件。

2.根据需要配置授权策略。

3.重启 docker 守护进程，如下所示：

dockerd   --authorization-plugin =

影响：

使用授权插件可能会导致性能下降。

默认值：

默认情况下，未设置授权插件。

参考资料：

https://docs.docker.com/engine/reference/commandline/dockerd/#access-authorization

https://docs.docker.com/engine/extend/plugins_authorization/

https://github.com/twistlock/authz

2.4 禁用就仓库版本（V1）上的操作

描述：

最新的docker镜像仓库是v2。遗留镜像仓库版本（v1）上的所有操作都应受到限制。

安全考虑：

docker镜像仓库 v2 在 v1 中引入了许多性能和安全性改进。它支持容器镜像来源验证和其他安全功能。因此，对docker v1 仓库的操作应该受到限制。

审计方法：

ps -ef | grep   dockerd

结果判定：

上面的命令应该列出--disable-legacy-registry   作为传递给 docker 守护进程的选项。

修复建议：

启动 docker 守护进程如下

dockerd   --disable-legacy-registry

影响：

旧版镜像仓库操作将受到限制。

默认值：

默认情况下，允许旧版镜像仓库操作。

参考资料

https://docs.docker.com/edge/engine/reference/commandline/dockerd/#legacy-registries

https://docs.docker.com/registry/spec/api/

https://the.binbashtheory.com/creating-private-docker-registry-2-0-with-token-authentication-service/

https://blog.docker.com/2015/07/new-tool-v1-registry-docker-trusted-registry-v2-open-source/

http://www.slideshare.net/Docker/docker-registry-v2

3. 容器镜像和构建文件

3.1 创建容器的用户

描述：

为容器镜像Dockerfile中的容器创建非root用户。

安全考虑：

如果可能，指定非 root 用户身份运行容器是一个很好的做法。虽然用户命名空间映射可用，但是如果用户在容器镜像中指定了用户，则默认情况下容器将作为该用户运行，并且不需要特定的用户命名空间重新映射。

审计方法：

docker ps   --quiet | xargs docker inspect --format '{{ .id }}:

user={{.config.user}}'

结果判定：

上述命令应该返回容器用户名或用户ID。

如果为空，则表示容器以root身份运行。

修复建议：

确保容器镜像的Dockerfile包含以下指令：USER <用户名或 ID>

其中用户名或 ID 是指可以在容器基础镜像中找到的用户。如果在容器基础镜像中没有创建特定用户，则在USER指令之前添加useradd命令以添加特定用户。

例如，在Dockerfile中创建用户：

RUN useradd -d/home/username -m -s/ bin/bash username USER

username

注意：如果镜像中有容器不需要的用户，请考虑删除它们。删除这些用户后，提交镜像，然后生成新的容器实例以供使用。

影响:

None

默认值:

默认情况下，容器以root权限运行，并以容器中的用户root身份运行。

参考资料：

https://github.com/docker/docker/issues/2918

https://github.com/docker/docker/pull/4572

https://github.com/docker/docker/issues/7906

3.2 扫描镜像漏洞并构建包含安全补丁的镜像

描述：

应该经常扫描镜像以查找漏洞。重建镜像安装最新的补丁。

安全考虑：

安全补丁可以解决软件的安全问题。可以使用镜像漏洞扫描工具来查找镜像中的任何类型的漏洞，然后检查可用的补丁以减轻这些漏洞。修补程序将系统更新到最新的代码库。此外，如果镜像漏洞扫描工具可以执行二进制级别分析，而不仅仅是版本字符串匹配，会更好。

审计方法：

1.通过执行以下命令列出所有运行的容器实例：docker ps --quiet

2.对于每个容器实例，执行下面的或等效的命令来查找容器中安装的包的列表。确保安装各种受影响软件包的安全更新。docker exec $ INSTANCE_ID   rpm –qa

或者，可以运行镜像漏洞扫描工具，它可以扫描生态系统中的所有镜像，然后修复。

结果判定：

上述命令将列出安装在容器上的包。查看列表并确保它是否存在已知安全漏洞。

修复措施：

如果可能的话，考虑使用最小基本镜像而不是标准的 Redhat / Centos /Debian 镜像。可以选择 BusyBox 和 Alpine。

这不仅可以将您的镜像大小从>150Mb 修剪至 20 Mb 左右，还可以使用更少的工具和路径来提升权限。

影响：

None

默认值：

默认情况下，容器和镜像不会自动更新。

参考资料：

https://docs.docker.com/userguide/dockerimages/

https://docs.docker.com/docker-cloud/builds/image-scan/

https://blog.docker.com/2016/05/docker-security-scanning/

https://docs.docker.com/engine/reference/builder/#/onbuild

3.3 镜像中删除setuid和setgit权限

描述：

删除镜像中的setuid和setgid权限防止容器中的提权攻击。

安全考虑：

setuid和setgid可用于提升权限。虽然这些权限有时是必需的，但应该为镜像中一些不需要的软件包删除这些权限。

审计方法：

在镜像上运行以下命令以列出具有setuid和setgid权限的可执行文件：

docker runfind/-perm+6000-type f -exec ls -ld {}\;2> /

dev / null

结果判定:

仔细检查列表，确保合法性。

修复建议：

只在需要可执行的文件上允许setuid和setgid权限。在构建时，通过在Dockerfile中添加以下命令来删除这些权限，最好添加在Dockerfile的末尾：RUN find / -perm +6000-type f -exec chmod a-s {} \;|| true

影响：

以上命令会导致依赖 setuid或setgid权限（包括合法权限）的可执行文件无法执行。需要小心处理。

默认值：不适用

参考资料：

http://www.oreilly.com/webops-perf/free/files/docker-security.pdf

http://container-solutions.com/content/uploads/2015/ 06/5.06.15_DockerCheatSheet_A2.pdf

http://man7.org/linux/man-pages/man2/setuid.2.html

http://man7.org/linux/man-pages/man2/setgid.2.html

3.4 在dockerfile中使用copy而不是add

描述：

在dockerfile中使用copy指令而不是add指令。

安全考虑：

copy指令只是将文件从本地主机复制到容器文件系统。add指令可能会从远程URL下载文件并执行解包等操作，增加了从URL添加恶意文件的风险。

审计方法：

1.运行以下命令获取镜像列表：docker images

2.对上述列表中的每个镜像执行以下命令，并查找任何 add指令：docker history

如果可以访问镜像的Dockerfile，需验证是否有add指令

结果判定：

不允许存在add指令。

修复建议：

在dockerfile中使用copy指令。

影响：

可能需要add指令提供的功能，例如从远程URL获取文件。

默认值：

不适用

参考资料：

https://docs.docker.com/engine/userguide/eng-image/doc kerfile _best-practices/#/add-or-copy

3.5 涉密信息不存储在dockerfile中

描述：

不要在dockerfile中存储任何涉密信息

安全考虑：

通过使用 Docker 历史命令，可以查看各种工具和实用程序。

通常情况，镜像发布者提供Dockerfiles来构建镜像。所以，Dockerfiles 中的涉密信息可能会被暴露并被恶意利用。

审计方法：

1.运行以下命令以获取镜像列表：docker images

2.对上面列表中的每个镜像运行以下命令，并查找是否有涉密信息：docker history

如果有权访问镜像的Dockerfile，请确认没有涉密信息。

结果判定：

不应该有涉密的信息。如用户账号，私钥证书等。

修复建议：

不要在Dockerfiles中存储任何类型的涉密信息。

影响：

若必须使用，需要指定相应的防护措施。

默认值：

默认情况下，在dockerfiles中存储配置密码没有任何限制。

参考资料：

https://github.com/docker/docker/issues/13490

http://12factor.net/config

https://avicoder.me/2016/07/22/Twitter-Vine-Source-c ode-dump/

4. 容器运行时保护

4.1 不使用特权容器

描述：

必须使用--privileged 标志将所有Linux内核功能提供给容器，从而覆盖-cap-add 和-cap-drop标志。

安全考虑：

--privileged标志给容器提供所有功能,并且提升了cgroup控制器执行的所有限制。换句话说，容器几乎可以做主机可以做的一切。这个标志存在允许特殊用例，就像在Docker中运行Docker一样。

审计方法：

docker ps   --quiet --all | xargs docker inspect --format '{{ .id }}:

privileged={{ .hostconfig.privileged   }}'

结果判定：

上述命令应为每个容器实例返回Privileged=false

修复建议：

不要运行带有--privileged标志的容器。

例如，不要启动如下容器：

docker   run --interactive --tty --privileged centos /bin/bash

影响：

除默认值之外的 Linux 内核功能将无法在容器内使用。

默认值：

false

参考资料：

https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

4.2 SSH不在容器中运行

描述：

SSH服务不应该在容器内运行。

安全考虑：

在容器内运行SSH会增加安全管理的复杂性：难以管理SSH服务器的访问策略和安全合规性、各种容器的密钥和密码、SSH服务器的安全升级等；可以在不使用SSH的情况下对容器进行shell访问，避免安全管理复杂性增加。

审计方法：

1.通过执行以下命令列出所有运行的容器实例：docker ps --quiet

2.对于每个容器实例，执行以下命令：docker exec $ INSTANCE_ID ps  -el

结果判定：

确保没有SSH服务

修复措施：

从容器中卸载SSH服务器，并使用nsenter或其他任何命令与容器实例进行交互（如 docker exec 或 docker attach）。

docker exec --interactive --tty $ INSTANCE_ID sh或 docker attach $INSTANCE_ID

影响：

None

默认值：

默认情况下，SSH服务不在容器内运行。每个容器只允许一个进程。

参考资料：

http://blog.docker.com/2014/06/why-you-dont-need-to-run -sshd-in-docker/

4.3 特权端口禁止映射到容器内

描述：

低于1024的TCP/IP端口号被认为是特权端口。由于各种安全原因，普通用户和进程不允许使用它们。

安全考虑：

默认情况下，如果用户没有明确声明容器端口进行主机端口映射，Docker 会自动地将容器端口映射到主机上的49153-65535中。但是，如果用户明确声明它，Docker可以将容器端口映射到主机上的特权端口。这是因为容器使用不限制特权端口映射的NET_BIND_SERVICE Linux 内核功能来执行。特权端口接收和发送各种敏感和特权的数据。如果docker使用它们可能会带来严重的影响。

审计方法：

通过执行以下命令列出容器的所有运行实例及其端口映射：

docker ps   --quiet | xargs docker inspect --format'{{.id}}：ports   =

{{.networksettings.ports}}'

结果判定：

查看列表，并确保容器端口未映射到低于1024的主机端口号。

修复措施：

启动容器时，不要将容器端口映射到特权主机端口。另外，确保没有容器在 Docker 文件中特权端口映射声明。

影响：

None

默认值：

默认情况下，允许将容器端口映射到主机上的特权端口。

注意：有些端口是必须使用的，例如：HTTP和HTTPS必须绑定80/TCP和443/TCP。

参考资料：

https://docs.docker.com/engine/userguide/networking/

4.4 docker exec命令不能使用特权选项

描述：

不要使用--privileged 选项来执行 docker exec。

安全考虑：

在docker exec中使用--privileged 选项可为命令提供扩展的Linux功能。这可能会造成不安全的情况。

审计方法：

如果按照前述的规定启用了审计，则可以使用以下命令过滤掉使用--privileged选项的docker exec命令。

ausearch -k docker | grep   exec | grep 特权。

结果判定：

无--privileged 选项

修复措施：

在docker exec命令中不要使用--privileged 选项

影响：

如果您需要容器内的增强功能，则只运行具有所需功能的容器。

默认值：

默认情况下，docker exec命令不使用--privileged 选项运行。

参考资料：

https://docs.docker.com/engine/reference/commandline/exec/

4.5 docker exec命令不能与user选项一起使用

描述：

不要使用--user 选项执行 docker exec。

安全考虑：

在docker exec中使用--user选项以该用户身份在容器内执行该命令可能会造成不安全的情况。

例如，假设你的容器是以tomcat用户（或任何其他非 root 用户）身份运行的，那么可以使用--user = root选项以root用户身份运行命令。这是非常危险的。

审计方法：

如果您按照前述规定启用了审计，则可以使用以下命令过滤掉使用了--user选项的docker exec命令。

ausearch -k docker | grep   exec | grep user

结果判定：

无--user选项

修复建议：

在 docker exec命令中不要使用--user选项

影响：

None

默认值：

默认情况下，docker exec命令不使用--user选项运行。

参考资料：

https://docs.docker.com/engine/reference/commandline/exec/

4.6 任何容器内不能安装docker套接字

描述：

docker socket（docker.sock）不应该安装在容器内。

安全考虑：

如果docker套接字安装在容器内，它将允许在容器内运行的进程执行docker命令，这有效地允许完全控制主机。

审计方法：

docker ps   --quiet --all | xargs docker inspect --format '{{ .id }}:

volumes={{ .mounts   }}' | grep docker.sock

结果判定：

上述命令将返回docker.sock作为卷映射到容器的任何实例。

修复措施：

确保没有容器将docker.sock作为卷。

影响：

None

默认值：

默认情况下，docker.sock未装入容器内。

参考资料：

https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/

https://forums.docker.com/t/docker-in-docker-vs-mounting-var-run-docker-sock/9450/2

https://github.com/docker/docker/issues/21109

优惠活动推荐：

阿里云/腾讯云/免费云服务器/云主机/数据库/短信/对象存储/CDN网站加速/DDOS高防ip/web应用防火墙/SSL证书/短视频直播/域名注册/优惠价格/折扣报价/最新活动/代金券/优惠券

【阿里云】云服务器优惠活动

【腾讯云】云服务器优惠活动