容器相关安全加固建议

容器服务安全

容器的管理和编排服务的安全直接影响了容器控制平面的安全，以 Docker 为例，Docker 守护进程（Docker Daemon）的配置合理与否，将在一定程度上影响 Docker 的安全性
。建议在守护进程启动时进行以下配置：（1）**限制容器间网络流量
**默认情况下，同一主机上的容器之间是允许所有通信的，即黑名单机制，可根据业务需求添加访问控制规则。 为了进一步
限制容器间通信，可以采用白名单机制（给 Docker 守护进程传递命令行参数 --icc = false ），即默认 容器间的通信是禁止的，只有显示添加规则才可以访问。此外，也可将容器加入自定义的网络，也可以限制与其它网络的容器间通信。
（2）设置集中和远程日志管理
容器的生命周期
很短，且业务变化很快，为了完成该场景下的安全分析和取证，需要将日志存放在远程集中 的平台中，可以通过 docker --log-driver=syslog --log-opt syslog-address=tcp://192.xxx.xxx.xxx 进行设置。
（3）允许 Docker 更改 Iptables 规则
Docker 守护进程会根据用户的网络设置，自动对 Iptables 进行必要的更改，建议允许 Docker 守护进程自动 更新 Iptables 配置，可以通过 docker --iptables = true 启动 Docker。
（4）不使用 AUFS作为存储驱动程序
AUFS是 Linux 较旧的存储驱动程序，可能会引发一些严重的内核崩溃等问题，在许多最新的 Linux 内核 发行版中，不再对 AUFS进行支持。可以通过 docker --storage-driver devicemapp
er 将存储驱动设置为 Device Mapper。默认情况下，Docker 在大多数的平台采用 Device Mapper 作为存储驱动，这可能会因不同的操作系统 而不同，应首选操作系统支持最佳的存储驱动。（5）使用默认 CGroups
Docker 通过 CGroups 对容器的资源进行限制，可以通过 docker --cgroup-parent = /foobar 进行设置。
对于守护进程的配置，除了上述命令行的方式，一般操作是修改“docker.service”文件，文件路径通常为 / lib/systemd/system/docker.service，不同 Linux发型版本可能路径不同，修改完成后重启 Docker 守护进程就有 以上命令属性了。
（6）应遵循在 Docker 守护进程级别设置 ulimit
ulimit 是一种 Linux系统的内建功能，它具有一套参数集，用于为由它生成的 Shell 进程及其子进程的资源使 用设置限制。其支持限制的资源包括：所创建的内核文件的大小、进程数据块的大小、Shell 进程创建文件的大小、 内存锁住的大小、常驻内存集的大小、打开文件描述符的数量、分配堆栈的最大值、CPU 时间、单个用户的最大 线程数、Shell 进程所能使用的最大虚拟内存。同时，它也支持硬资源和软资源的限制。
设置系统资源控制可以防止资源耗尽带来的问题，比如 Fork 炸弹，有时候合法的用户和进程也可能造成过 度的使用系统资源，导致系统资源耗尽。因此在 Docker 服务需要设置默认的 ulimit 值，实现相应的资源控制。
（7）使用可信仓库
默认情况下，Docker 进程只允许 push 和 pull 配置了可信证书的镜像仓库的镜像，除非是自己内部的不可信 的仓库否则不建议开启此配置项。

主机安全

主机基本安全加固建议

容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机中安装 有漏洞的软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问风险，防火墙未正确配置 会降低主机的安全性，sudo 的访问权限没有按照密钥的认证方式登录可能会导致暴力破解宿主机。
从安全性考虑，容器主机应遵循如最小安装化，不应当安装额外的服务和软件以免增大安全风险；配置交互 用户登陆超时时间；关闭不必要的数据包转发功能；禁止 ICMP重定向；配置可远程访问地址范围；删除或锁定 与设备运行、维护等工作无关的账号、重要文件和目录的权限设置；关闭不必要的进程和服务等安全加固原则。

容器相关安全加固建议

（1）为容器的存储分配单独的分区
默认情况下，所有 Docker 相关文件存储在 /var/lib/docker 目录下，需要尽可能地为容器创建独立的分区以 保证其安全性。对于新安装的 Docker，可以通过以下命令实现审计：grep /var/lib/docker /etc/fstab。
（2）宿主机安全加固 保证宿主机符合相应的安全规范，对其进行有效的漏洞管理和配置管理。
（3）更新 Docker 到最新版本
由于 Docker 软件会不断地发布更新，旧的版本可能存在安全漏洞。因此需要保证已发现的 Docker 软件漏洞 尽可能得到修复并且定期对 Docker 版本进行风险评估。
（4）守护进程的控制权限
Docker 的守护进程需要 root 权限，对于添加到“docker”用户组的用户提供了完整的 root 访问权限。因此 在容器主机上，要严格限制“docker”用户组内的用户，删除一切不受信任的用户。
（5）对 Docker 守护进程进行审计
在容器上，除了需要对常规的 Linux文件系统和系统调用进行审计之外，还需要对 Docker 守护进程的活动 和使用情况进行审计。默认情况下，是不会对其进行审计的，可以通过 auditctl -w /usr/bin/docker -k docker 添 加审计规则，也可以通过修改 /etc/audit/audit.rules 文件进行规则更新。
在进行 Docker 守护进程审计时，会产生大量的日志文件，要确保定期的进行日志归档，建议创建一个单独 的审计分区进行日志存储，以避免日志文件写满根系统影响正常业务。
（6）对 Docker 相关的文件和目录进行审计
除了对 Docker 守护进程进行审计，还需要对 Docker 相关的文件和目录进行审计，例如 /var/lib/docker（包 含有关容器的所有信息）、/etc/docker（包含 Docker 守护进程和 Docker 客户端之间 TLS通信的所有密钥和证 书）、docker.service（Docker 守护进程运行参数配置文件）、docker.socket（守护进程运行 socket）、/etc/ default/docker（支持 Docker 守护进程各种参数）、/etc/default/daemon.json（支持 Docker 守护进程各种参数）、 /usr/bin/docker-containerd、/usr/bin/docker-runc（Docker 依赖于 containerd 和 runC 来生成容器）。
具体审计方式与守护进程的审计一致，可以通过配置文件或命令行的方式添加审计规则。

镜像安全

作为容器运行的基础，容器镜像的安全在整个容器安全生态中占据着重要位置。容器镜像是由若干层镜像叠 加而成的，通过镜像仓库分发和更新的。因此，可以从镜像构建安全、仓库安全以及镜像分发安全三方面介绍镜 像安全。

镜像构建安全

镜像构建的方式通常有两种：基于容器直接构建或基于 Dockerfile 构建。但建议所有的镜像文件应该由 Dockerfile 来创建，因为基于 Dockerfile 构建的镜像是完全透明的，所有的操作指令都是可控和可追溯的。
镜像构建存在的风险项通常包括：

1. pull 的基础镜像并不是由可信的组织和人员发布，镜像本身存在后门或者其它风险项。
2. 在 Dockerfile 中存储敏感信息。例如配置服务时中使用明文固定密码或凭证等。
3. 安装不必要的软件扩大了攻击面。 针对以上问题可以从下面几方面来加固镜像构建安全：
   （1）验证镜像来源
   为了保证镜像内容的可信，建议开启 Docker 的内容信任机制。内容信任机制为向远程镜像仓库发送和接收 的数据提供了数字签名功能，这些签名允许客户端验证镜像标签的完整性和发布者。默认情况内容信任机制是被 禁用的，可以通过执行下面指令完成或者在 Docker 的配置文件中配置。
   export DOCKER_CONTENT_TRUST=1
   （2）镜像轻量化 只安装必要的软件包，不仅在提高容器性能方面有很大帮助，更重要的是减少了攻击面。
   （3）正确使用镜像指令
   在构建镜像时要选择恰当的指令，若需引入外部文件，在 Dockerfile 中能用COPY指令就不要使用ADD指令， 因为 COPY 指令只是将文件从本地主机复制到容器文件系统，ADD指令却可以从远程 URL下载文件并执行诸如 解压缩等操作，这可能会带来从 URL添加恶意文件的风险。
   （4）敏感信息处理
   尽管 Docker 为用户分配了只读权限，但有时用户仍需要小心容器中存储的数据，例如 Dockerfile 中不能存 储密码，令牌，密钥和用户机密信息等，即使在创建好容器后再删除这些数据也会造成风险，因为镜像的历史记 录中仍能检索到这些数据。
   推荐使用 Kubernetes 和 Docker Swarm 的加密管理功能，可以有效的对信息进行加密，以加密格式存储， 并且在查找时只能由授权的用户去解密。

参考资料

绿盟 容器安全技术报告

友情链接

GA 1277.2-2020 互联网交互式服务安全管理要求 第2部分：微博客服务