Docker-bench-security安全CIS基准测试工具

Docker-bench-security安全CIS基准测试工具

介绍

使用Docker来容纳您的应用程序和服务可以为您提供开始即用的一些安全优势，但默认的Docker安装仍然有一些空间可用于一些与安全相关的配置改进。在互联网安全中心为了促进互联网安全创造了一个按步骤确保docker安全的清单。随后，Docker团队发布了一个安全审计工具- Docker Bench for Security，在Docker主机上运行此清单并记录它发现的任何问题。

在本教程中，我们将安装Docker Bench for Security，然后使用它来评估Ubuntu 16.04主机上默认Docker安装（来自官方Docker存储库）的安全性。然后我们将解决它发出的警告。

我们的修复程序主要包括以下两个配置更新：

• 安装auditd和设置Docker守护程序及其关联文件的审核规则
• 更新Docker的daemon.json配置文件

我们不会详细介绍有关创建安全容器的任何细节，我们将只关注本教程中Docker主机安全性的更新。有关容器Docker的相关知识可以访问腾讯云社区开发者手册Docker中文手册以及腾讯云专属在线实验平台基于CentOS 搭建Docker环境。

第1步，安装Docker Bench Security

我们将首先使用Docker Bench for Security脚本克隆到服务器git，然后直接从克隆的存储库运行脚本。

导航到用户可以写入的目录。在此示例中，我们将脚本下载到用户的主目录：

$ cd ~

然后克隆docker-bench-securityGit存储库：

$ git clone https://github.com/docker/docker-bench-security.git

这将从repo中提取所有文件并将它们放在本地docker-bench-security目录中。接下来，进入此结果目录：

$ cd docker-bench-security

最后，要执行安全审核，请运行docker-bench-security.sh脚本：

$ ./docker-bench-security.sh

docker run 命令安装 Docker Bench Security：

## docker run 命令安装 Docker Bench Security
docker run --rm --net host --pid host --userns host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /etc:/etc:ro \
    -v /usr/bin/containerd:/usr/bin/containerd:ro \
    -v /usr/bin/runc:/usr/bin/runc:ro \
    -v /usr/lib/systemd:/usr/lib/systemd:ro \
    -v /var/lib:/var/lib:ro \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    --label docker_bench_security \
    docker/docker-bench-security

检查结果：

第2步， 确保为各种Docker文件配置了审核

inux auditd 工具可以将审计记录写入日志文件。包括记录系统调用和文件访问。管理员可以检查这些日志，确定是否存在安全漏洞,指定docker文件到linux的审计规则中

• 1.1、确保Docker daemon要将审计的能力进行配置
• 1.2、确保对docker文件和目录进行审计
• 1.3、同样是对Docker文件和目录进行审计的检查
• 1.4、确保启动systemd文件进行审计检查
• 1.5、确保docker client和docker守护进程之间与localhost的通信
• 1.6、确保docker.service文件进行审计
• 1.7、确保docker.socket文件进行审计
• 1.8、确保/usr/sbin/runc容器命令行工具进行审计

    cat > /etc/audit/rules.d/docker-audit.rules <<'EOF'
-w /usr/bin/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker
-w /etc/docker -k docker
-w /etc/docker/daemon.json -k docker
EOF

第3步， 更正Docker守护程序配置警告

审计的这一部分涉及Docker守护程序的配置。这些警告都可以通过为被调用的守护进程daemon.json创建配置文件来解决，我们将向其添加一些与安全相关的配置参数。我们将首先创建并保存此配置文件，然后逐个查看配置中的测试和相应行。

首先，在您喜欢的编辑器中打开配置文件：

$ sudo nano /etc/docker/daemon.json

这将显示一个空白文本文件。粘贴如下：

/etc/docker/daemon.json
{
    "icc": false,
    "userns-remap": "default",
    "log-driver": "syslog",
    "disable-legacy-registry": true,
    "live-restore": true,
    "userland-proxy": false,
    "no-new-privileges": true
}

保存并关闭该文件，然后重新启动Docker守护程序，以便它获取此新配置：

$ sudo systemctl restart docker

您现在可以重新运行审核以确认已解决所有第2节警告。

我们插入到此文件中的配置变量的排列顺序与审计警告的顺序相同。让我们来逐个查看：

2.1确保默认网桥上的容器之间的网络流量受限

此警告在配置文件"icc": false中解决。此配置创建的容器只能在使用--link=container_name Docker命令行或Docker Compose配置文件中的links:参数显式链接时才能相互通信。这样做的一个好处是，如果攻击者攻击一个容器，他们将很难找到并攻击同一主机上的其他容器。

2.8启用用户命名空间支持

Linux命名空间为容器中运行的进程提供了额外的隔离。用户命名空间重新映射允许进程在容器中以root用户身份运行，同时重新映射到主机上权限较低的用户。我们使用"userns-remap":"default"配置文件中的行启用用户命名空间重新映射。

我们将参数设置为default，这意味着Docker将创建一个dockremap用户，容器用户将被重新映射到该用户。您可以使用以下命令验证dockremap用户是否已创建id：

$ sudo id dockremap

您应该看到类似于以下内容的输出：

uid=112(dockremap) gid=116(dockremap) groups=116(dockremap)

如果将容器用户重新映射到其他主机用户对您的用例更有帮助，请在配置文件default中指定用户或用户组。

警告：用户重新映射功能强大，如果配置不当可能会导致中断和破坏，因此强烈建议您阅读官方文档并了解在生产环境中实施此更改之前的含义。

2.11确保已启用Docker客户端命令的授权

如果您需要允许网络访问Docker套接字，您应该查阅官方Docker文档，以了解如何安全地设置必要的证书和密钥。

我们不会在这里讨论这个过程，因为具体细节在很大程度上取决于个别情况。审计将继续将此测试标记为WARN，访问默认的仅限本地的Docker套接字是通过要求docker组中的成员资格来保护的，因此可以放心地忽略它。

2.12确保配置了集中式和远程日志记录

在Docker守护程序配置文件中，我们已使用"log-driver":"syslog"行启用标准syslog日志记录。然后，您应该配置syslog以将日志转发到集中式syslog服务器。这会从Docker主机上获取日志，并远离可能更改或删除它们的攻击者。

如果您只想转发Docker日志并且不想发送syslog，则可以通过将以下参数附加到文件来在Docker配置文件中指定远程syslog服务器：

/etc/docker/daemon.json `"log-opts": { "syslog-address": "udp://198.51.100.33:514" }`

请务必使用您自己的syslog服务器地址替换IP地址。

或者，您可以使用splunk或者fluentd日志聚合服务指定日志驱动程序，也可以使用其他日志聚合服务来发送Docker守护程序日志。有关Docker日志驱动程序及其配置的更多信息，请参阅Docker日志驱动程序官方文档。

2.13确保遗留注册表（v1）上的操作已禁用

此警告由守护程序配置文件中的"disable-legacy-registry": true行修复。这会禁用不安全的旧映像注册表协议。由于已从Docker守护程序中删除了对此协议的支持，因此该标志正在被弃用。

2.14确保已启用实时还原

通过"live-restore": true在守护进程配置中指定，我们允许容器在Docker守护进程未运行时继续运行。这改善了主机系统更新期间的容器正常运行时间和其他稳定性问题。

2.15确保禁用Userland代理

"userland-proxy": false行修复了此警告。这将禁用docker-proxyuserland进程，该进程默认处理将主机端口转发到容器，并用iptables规则替换它。如果hairpin NAT可用，则不需要userland代理，应禁用该代理以减少主机的攻击面。

2.18确保限制容器获取新权限

守护程序配置中的"no-new-privileges": true行可防止容器内的权限升级。这保证了使用的容器不能获得新的特权setuid或setgid二进制文件。

现在我们已经更新了Docker守护程序配置，让我们在第四部分的审计中修复剩下的一个警告。