如何在Ubuntu16.04上使用DockerBench审计Docker主机安全性以确保安全性

来自菜鸟教程
跳转至:导航、​搜索

介绍

使用 Docker 容器化您的应用程序和服务可以为您带来一些开箱即用的安全优势,但默认的 Docker 安装仍有一些与安全相关的配置改进的空间。 互联网安全中心 是一个非营利组织,其使命是促进互联网安全最佳实践,它创建了 用于保护 Docker 的分步清单。 随后,Docker 团队发布了一个安全审计工具——Docker Bench for Security——在 Docker 主机上运行这个清单并标记它发现的任何问题。

在本教程中,我们将安装 Docker Bench for Security,然后使用它来评估 Ubuntu 16.04 主机上默认 Docker 安装(来自官方 Docker 存储库)的安全状况。 然后,我们将修复它警告我们的一些问题。

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

  • 安装 auditd 并为 Docker 守护进程及其关联文件设置审计规则
  • 更新 Docker 的 daemon.json 配置文件

我们不会详细介绍有关创建安全容器的任何细节,我们只会在本教程中关注对 Docker 主机安全性的更新。

先决条件

为了完成本教程,您将需要以下内容:

第 1 步 — 安装 Docker Bench 安全性

首先,以非 root 用户身份通过 SSH 连接到 Docker 主机。

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

导航到您的用户可以写入的目录。 在本例中,我们将脚本下载到用户的主目录:

cd ~

然后克隆 docker-bench-security Git 存储库:

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
Output# ------------------------------------------------------------------------------
# Docker Bench for Security v1.3.4
#
# Docker, Inc. (c) 2015-
#
# Checks for dozens of common best-practices around deploying Docker containers in production.
# Inspired by the CIS Docker Community Edition Benchmark v1.1.0.
# ------------------------------------------------------------------------------

Initializing Tue Jun  5 18:59:11 UTC 2018


[INFO] 1 - Host Configuration
[WARN] 1.1  - Ensure a separate partition for containers has been created
[NOTE] 1.2  - Ensure the container host has been Hardened
[INFO] 1.3  - Ensure Docker is up to date
[INFO]      * Using 18.03.1, verify is it up to date as deemed necessary
. . .

该脚本运行各种测试,并为每个测试提供 INFONOTEPASSWARN 结果。 Ubuntu 16.04 上的默认 Docker 安装将通过其中许多测试,但会在第 1、2 和 4 节中显示一些警告。

在本教程的其余部分,我们将通过保护 Docker 安装来解决这些警告。

第 2 步 — 更正主机配置警告

审计的第一部分测试主机操作系统的配置,包括其加固、包版本和审计配置。 让我们看一下本节中的测试:

1.1 确保为容器创建了单独的分区

为了确保适当的隔离,最好将 Docker 容器和所有 /var/lib/docker 保存在它们自己的文件系统分区上。 在您可能无法对驱动器进行分区的某些云托管情况下,这可能会很困难。 在这些情况下,您可以通过将 Docker 的数据目录移动到外部网络连接的块设备来满足此测试。

1.2 确保容器主机已经加固

此测试只是提醒您考虑强化主机的说明。 加固通常包括设置防火墙、锁定各种服务、设置审计和日志记录,以及实施其他安全措施。 您可以通过阅读 7 保护您的服务器的安全措施 开始使用此功能。

1.3 确保 Docker 是最新的

这个测试打印出你的 Docker 版本。 您可以通过访问 Docker CE 发行说明 来查看当前的稳定版本。 如果您不是最新的,并且您使用 apt-get install 安装了 Docker,您可以再次使用 apt-get 来升级 Docker 包:

sudo apt-get update
sudo apt-get upgrade

1.4 确保只允许受信任的用户控制 Docker 守护进程

先决条件 Docker 设置教程 中,我们将我们的非 root 用户添加到 docker 组,以使其能够访问 Docker 守护进程。 此测试从 /etc/group 文件中输出 docker 组的行:

Outputdocker:x:999:sammy

此行显示 docker 组中包含的所有用户。 查看该行并确保只有适当的用户有权控制 Docker 守护程序。 在上面的示例中,我们的授权用户 sammy 被突出显示。 要从该组中删除用户,您可以使用 gpasswd

gpasswd -d username docker

1.5–1.13 确保为各种 Docker 文件配置了审计

我们需要安装和配置 auditd 以启用对 Docker 的一些文件、目录和套接字的审计。 Auditd 是一个 Linux 访问监控和记帐子系统,它在内核级别记录值得注意的系统操作。

auditdapt-get 一起安装:

sudo apt-get install auditd

这将安装并启动 auditd 守护进程。 我们现在将配置 auditd 来监控 Docker 文件和目录。 在文本编辑器中,打开审计规则文件:

sudo nano /etc/audit/audit.rules

您应该看到以下文本:

/etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

将以下代码段粘贴到文件底部,然后保存并退出编辑器:

/etc/audit/audit.rules

-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa

这些规则指示 auditd 监视 (-w) 指定的文件或目录,并将任何写入或属性更改 (-p wa) 记录到这些文件。

重新启动 auditd 以使更改生效:

sudo systemctl restart auditd

至此,您已成功配置 auditd 以监视 Docker 文件和目录中的可疑更改。 您可以重新运行 Docker Bench for Security 脚本以确认第 1 节中的测试现在已通过。

有关 auditd 的更多信息,您可以阅读我们的教程 如何在 CentOS 7 上使用 Linux 审计系统。 尽管是为 CentOS 编写的,但配置和使用审计系统的部分同样适用于 Ubuntu。

现在我们已经验证了我们的主机配置,我们将继续进行 Docker 安全审计的第 2 部分,即 Docker 守护程序配置。

第 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 解决。 此配置创建的容器只有在使用 Docker 命令行上的 --link=container_name 或 Docker Compose 配置文件中的 links: 参数显式链接时才能相互通信。 这样做的一个好处是,如果攻击者破坏了一个容器,他们将更难找到和攻击同一主机上的其他容器。

2.8 启用用户命名空间支持

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

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

sudo id dockremap

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

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

如果将容器用户重新映射到不同的主机用户对您的用例更有意义,请在配置文件中指定用户或 user:group 组合代替 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" }`

请务必将 IP 地址替换为您自己的系统日志服务器的地址。

或者,您可以指定像 splunkfluentd 之类的日志驱动程序,以使用其他日志聚合服务发送 Docker 守护程序日志。 有关 Docker 日志驱动程序及其配置的更多信息,请参阅官方 Docker 日志记录驱动程序文档

2.13 确保旧注册表 (v1) 上的操作已禁用

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

2.14 确保启用实时恢复

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

2.15 确保禁用 Userland 代理

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

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

守护进程配置中的 "no-new-privileges": true 行可防止从容器内部进行权限升级。 这确保容器无法使用 setuidsetgid 二进制文件获得新的权限。

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

第 4 步 — 启用内容信任

我们审计标记的最终测试是 4.5 Ensure Content trust for Docker is Enabled。 内容信任是一个用于签署 Docker 映像并在运行它们之前验证其签名的系统。 我们可以使用 DOCKER_CONTENT_TRUST 环境变量启用内容信任。

要为当前的 shell 会话设置此变量,请在 shell 中键入以下内容:

export DOCKER_CONTENT_TRUST=1

在此 export 命令之后运行审核应显示已启用内容信任并清除此警告。 要为所有用户和所有会话自动启用它,请将 DOCKER_CONTENT_TRUST 变量添加到 /etc/environment 文件中,该文件是用于分配系统范围环境变量的文件:

echo "DOCKER_CONTENT_TRUST=1" | sudo tee -a /etc/environment

有关 Docker 内容信任的更多信息可以在 官方 Docker 内容信任文档 中找到。

至此,我们已经解决了 Docker Bench for Security 脚本标记的所有警告。 我们现在有一个更安全的 Docker 主机来运行容器。

结论

在本教程中,我们安装了 Docker Bench for Security 脚本,使用它来审核 Docker 安装的安全性,并通过安装和配置 auditd 和 Docker 守护程序的配置文件来解决警告。

完成本教程后,运行审计脚本应该会导致很少的错误或警告。您还应该理解并有充分的理由忽略那些持续存在的错误或警告。

有关 Docker 安全配置选项的更多信息,请参阅 Docker 文档 并查看文档特定小节的链接,这些小节已包含在本教程中。