Docker 安全最佳实践和备忘单 | IDCF docker

容器不是安全设备。这就是为什么我们策划了一组易于操作的建议来提高您的Docker 容器安全性。

文章图片

多年来，Docker 容器一直是开发人员工具箱的重要组成部分，使他们能够以标准化的方式构建、分发和部署他们的应用程序。
毫无疑问，这种吸引力的增加伴随着与容器化技术相关的安全问题的激增。事实上，容器也代表了攻击者的标准化攻击对象。他们可以很容易地利用错误配置并从容器内逃逸到主机。
此外，“容器”这个词经常被误解，因为许多开发人员倾向于将隔离的概念与错误的安全感联系起来，认为这项技术本质上是安全的。
这里的关键是容器默认没有任何安全维度。它们的安全性完全取决于：

支持基础设施（操作系统和平台）
容器本身包含的软件组件
运行时配置

容器安全是一个广泛的话题，但好消息是，许多最佳实践都是唾手可得的成果，可以快速减少其部署的攻击面。

这就是为什么我们在构建和运行时策划了一组关于 Docker 容器配置的最佳建议。

文章图片

注意：在像 Kubernetes 这样的托管环境中，这些设置都可以被安全上下文或其他更高级别的安全规则覆盖。

一、构建配置 1.1 检查镜像
谨慎选择您的基础镜像docker pull image:tag
您应该始终更喜欢使用受信任的镜像，最好来自Docker 官方镜像，以减轻供应链攻击。如果您需要选择基础发行版，建议使用 Alpine Linux，因为它是可用的最轻量级发行版之一，可确保减少攻击范围。

我需要使用最新的还是固定的发行版本？

首先，您应该了解 Docker tag的工作方式从少到多，这就是为什么：python:3.9.6-alpine3.14

python:3.9.6-alpinepython:3.9-alpinepython:alpine

如上所示，基础镜像都是一样的（在撰写本文时）。
通过非常具体并确定一个版本，您可以保护自己免受未来任何重大更改的影响。另一方面，使用最新版本可确保修补更多漏洞。这是一种权衡，但通常建议固定到稳定版本。
考虑到这一点，我们会选择python:3.9-alpine这里。

注意：这同样适用于在镜像构建过程中安装包。

1.2 始终使用非特权用户
默认情况下，容器内的进程以 root (id=0)身份运行。
为了执行最小权限原则，您应该设置一个默认用户。为此，您有两个选择：

使用以下选项指定运行容器中不存在的任意用户 ID：docker run -u 4000

注意：如果您以后需要挂载文件系统，您应该将您使用的用户 ID 与主机用户相匹配，以便访问文件。

或者通过在 Dockerfile 中创建默认用户来。

FROM RUN addgroup -S appgroup \ && adduser -S appuser -G appgroup USER appuser... ...

一定要注意检查在基础镜像中创建组和用户的工具

1.3 使用单独的用户 ID 命名空间
默认情况下，Docker 守护程序使用主机的用户 ID 命名空间。因此，容器内权限提升的任何成功也意味着对主机和其他容器的 root 访问。为了降低这种风险，您应该将主机和 Docker 守护程序配置为使用带有该--userns-remap选项的单独命名空间。
1.4 小心处理环境变量
你永远不应该在 ENV 指令中以明文形式包含敏感信息：它们根本不是一个安全的地方来存储你不想出现在最后一层的任何信息。例如，如果您认为像这样取消设置环境变量：

ENV $VAR RUN unset $VAR

这不是安全的！$VAR仍然会存在于容器中，并且可以随时被获取！
为了防止运行时读取访问，请使用单个 RUN 命令在单个层中设置和取消设置变量（不要忘记变量仍然可以从镜像中提取）。

RUN export ADMIN_USER="admin" \ && ... \ && unset ADMIN_USER

不幸的是，密码经常被硬编码到 docker 镜像中，不过开发可以利用密码扫描引擎来查找Dockerfile 是否存在密码
1.5 不要暴露 Docker 守护进程套接字
除非你对自己正在做的事情非常有信心，否则永远不要暴露 Docker 正在侦听的 UNIX 套接字：/var/run/docker.sock
这是 Docker API 的主要入口点。授予某人访问权限等同于授予对您的主机的无限制 root 访问权限。你永远不应该将它暴露给其他容器：
-v /var/run/docker.sock://var/run/docker.sock
二、特权、能力和共享资源首先，您的容器不应该以特权身份运行，否则，它将被允许在主机上拥有所有 root 权限。为了更安全，建议明确禁止在使用选项创建容器后添加新权限的可能性--security-opt=no-new-privileges。
其次，功能是 Docker 使用的一种 Linux 机制，用于将二进制root/non-root二分法转变为细粒度的访问控制系统：您的容器使用一组默认的已启用功能运行，而您很可能不这样做都需要。
建议删除所有默认功能并单独添加它们：
例如，请参阅默认功能列表，Web 服务器可能只需要 NET_BIND_SERVICE 来绑定到 1024 下的端口（如端口 80）。
第三，不要共享主机文件系统的敏感部分：

root (/),
device (/dev)
process (/proc)
virtual (/sys)挂载点

如果您需要访问主机设备，请小心使用[r|w|m]标志（读、写和使用 mknod）有选择地启用访问选项。
2.1 使用控制组限制对资源的访问
控制组是用于控制每个容器对 CPU、内存、磁盘 I/O 的访问的机制。默认情况下，容器与专用关联cgroup，但如果--cgroup-parent存在该选项，则会将主机资源置于DoS 攻击的风险中，因为您允许主机和容器之间共享资源。
同样的想法，建议使用以下选项指定内存和 CPU 使用率

--memory=”400m” --memory-swap=”1g”--cpus=0.5 --restart=on-failure:5 --ulimit nofile=5 --ulimit nproc=5

参考： https://docs.docker.com/confi...

三、文件系统 3.1 只允许读访问根文件系统
容器应该是短暂的，因此大多是无状态的。这就是为什么您通常可以将挂载的文件系统限制为只读的原因。docker run --read-only
3.2 对非持久性数据使用临时文件系统
如果您只需要临时存储，请使用适当的选项docker run --read-only --tmpfs /tmp:rw ,noexec,nosuid
3.3 将文件系统用于持久数据
如果您需要与主机文件系统或其他容器共享数据，您有两个选择：

创建具有有限可用磁盘空间的绑定安装 ( --mount type=bind,o=size)为专用分区创建绑定卷 ( --mount type=volume)
在任何一种情况下，如果容器不需要修改共享数据，请使用只读选项。

docker run -v :/path/in/container:ro

docker run --mount source=,destination=/path/in/container,readonly

四、联网 4.1 不要使用 Docker 的默认网桥 docker0
docker0是在启动时创建的网桥，用于将主机网络与容器网络分开。
创建容器时，Dockerdocker0默认将其连接到网络。因此，所有容器都相互连接docker0并能够相互通信。
您应该通过指定选项禁用所有容器的默认连接，--bridge=none而是使用以下命令为每个连接创建一个专用网络：

docker network create

然后用它来访问主机网络接口

docker run --network=

文章图片

（Docker联网简单例子）
例如，要创建一个与数据库通信的 Web 服务器（在另一个容器中启动），最佳实践是创建一个桥接网络WEB以路由来自主机网络接口的传入流量，并使用另一个DB仅用于连接数据库的桥接器和网络容器。
4.2 不要共享主机的网络命名空间
同样的想法，隔离主机的网络接口：--network理论上不应使用主机选项。
4.3 日志记录
默认日志级别为 INFO，但您可以使用以下选项指定另一个级别：--log-level="debug"|"info"|"warn"|"error"|"fatal"
鲜为人知的是 Docker 的日志导出能力：如果您的容器化应用程序生成事件日志，您可以使用选项重定向STDERR和STDOUT流到外部日志服务以进行解耦--log-driver=
您还可以启用双日志记录以在使用外部服务时保留 docker 对日志的访问。如果您的应用程序使用专用文件（通常写在 /var/log），您仍然可以重定向这些流：请