docker 安全性_未来的Docker安全性

docker 安全性

当我开始在Opensource.com上撰写有关Docker安全性的系列文章时，我说“ 容器不包含” 。

Red Hat和Docker的主要目标之一就是使这一说法不那么真实。 我在Red Hat的团队正在继续尝试利用其他安全机制来提高容器的安全性。 这些是我们正在努力实现的一些安全功能，以及它们将来如何影响Docker和容器。

用户名称空间

用户名称空间是一个内核名称空间，应使我们能够更好地分离主机和容器。

基本思路是，您可以创建一系列UID（例如60,000-61,000），您可以将其映射为0-1000的用户名称空间。 您也可以使用GID执行此操作。 内核会将容器内部的UID 0视为容器外部的UID 60,000。 文件或进程中不在映射范围内的任何UID都将被视为UID = -1，并且无法在容器中访问。 这包括整个基本图像。 如果要使用具有用户名称空间的基本映像，则需要将基本映像中的所有UID更改为新的Root用户。 用户命名空间的其他问题是，在容器中无法访问带有UID 0拥有的文件的装入容器的卷。 您必须将容器中想要的所有内容都chown为UID范围所拥有的内容。

chown -R 60000:60000 /var/lib/content

用户名称空间的另一个问题是，如果要使用它们在容器之间进行分隔，则每个容器都需要具有不同范围的UID。 如果您有数百个容器，则需要数百个范围。 这也将成为容器主机之间共享存储的问题。

关于用户名称空间的很酷的事情之一是它们允许使用名称空间的功能。 如果将容器放在用户名称空间内，则它不再需要实际的系统功能。 这意味着当容器启动用户名称空间时，我们可以调整代码以删除所有系统功能。 它还使我们可以放弃SELinux标签中的所有功能。

用例

我看到用户命名空间至少存在三种不同的潜在用例。

1. 改进容器之间的常规分隔，以使我们可以关闭容器的所有Linux功能。 这样做将加强系统与容器之间的安全性，但不一定会改善容器之间的间隔。 在这种模式下，我可以设想我们将为DOCKERROOT选择一个UID，然后设置所有容器以使用此ID。 例如，如果DOCKERROOT为UID = 2，我将为UID0 = 2和GID0 = 2设置一个映射，然后将所有大于2的UIDS映射到它们自己。 例如，3-MAX_UID = 3-MAX_UID，我们将对GID进行类似的处理。 这样，我们消除了容器攻击根目录的能力。 对于批量安装，它也要简单得多。

   我建议，也许我们可以尝试默认情况下仅在用户名称空间中使用功能下降，例如，通过将UID 0-65,0000映射到UID 0-65,0000。 然后，如果您将根用户拥有的文件批量安装到容器中，则可以运行，但是容器外部的进程将没有任何功能。 通过这样做，我们可以尝试以合理的方式使用用户名称空间。

2. OpenShift方法：容器中的所有文件都映射到单个UID / GID对。 系统上的每个用户都有一个不同的UID。 这样做的主要原因是当用户容器要求进程以内核功能运行时。 否则，使用用户名称空间几乎没有效果。
3. 每个容器与其他每个容器都获得单独的UID范围映射。 这使您能够运行大量容器并使用UID分隔来使容器分开。 但是激增了复杂性。 卷装载变得非常头疼。 为了使此工作有效，我建议我们添加-v / SRC / DEST：U，它将在装入过程中将UID：GID / SRC插入容器的默认UID。

但是，我并不建议可以将这三个用例一起使用。 我已经看到了向内核提出的建议，允许在加入容器时允许在安装点内“重新映射UID”，甚至可能使用绑定安装，但是我将其留给内核人员，看是否可行，然后听一听。安全人员，这是否是个好主意。

此时，用户名称空间已合并到libcontainer中，并且正在准备修补程序以使其能够在Docker中运行。

赛康

这里和其他地方描述的所有容器分离模式的问题之一是它们都依赖于内核进行分离。 与气隙式计算机甚至虚拟机不同，容器内的进程可以直接与主机内核通信。 如果主机内核具有容器可以访问的内核漏洞，则它们可能能够禁用所有安全性并脱离容器。

x86_64 Linux内核有600多个系统调用，其中任何一个错误都可能导致特权提升。 一些系统调用很少被调用，应该从容器内的访问中删除。

Seccomp由Google开发，用于从流程中删除系统调用。 Google在Chrome浏览器中使用它来执行插件。 由于插件往往是从Internet下载的不受信任的内容，因此您真的想控制插件的安全性。

我的同事Paul Moore决定通过构建C库来简化syscall树的管理，使seccomp的使用更加容易。 Libseccomp现在用于qemu，systemd，lxc工具和其他一些工具中。

我们还为libseccomp编写了Go绑定，我们正在努力进入libcontainer来从容器中删除系统调用。

我们建议从容器中删除以下系统调用列表：kexec_load，open_by_handle_at，init_module，finit_module，delete_module，iopl，ioperm，swapon，swapoff，sysfs，sysctl，adjtimex，clock_adjtime，lookup_dcookie，perf_event_open和fanotifycopen。

我们想获得其他删除系统调用的建议。 我们还希望删除Linux允许的所有旧网络，包括：业余无线电X.25（3），IPX（4），Appletalk（5），Netrom（6），网桥（7），ATM VPC（8）， X.25（9），业余无线电X.25 PLP（11），DECNet（12），NetBEUI（13），安全性（14），PF_KEY密钥管理API（15）和所有大于AF_NETLINK的套接字调用（16） 。

放入系统调用筛选器的另一个效果是，默认情况下，它会丢弃其他体系结构的所有syscall。 例如，默认情况下，将不允许您使用启用了seccomp的容器调用i386 syscall。 合并后，我们希望将其设为默认值。

在消除上述系统调用和其他体系结构的系统调用之间，我们可以将内核的攻击面缩小一半以上。

调整Seccomp

与功能和SELinux标签类似，我们还在Docker中内置了消除命令行中其他系统调用的功能。

docker run -d --security-opt seccomp:allow:clock_adjtime ntpd

这将允许系统调用返回到容器中。

docker run -d --security-opt seccomp:deny:getcwd /bin/sh

同样，这将消除容器查看其当前工作目录的能力。 Red Hat的Matt Heon播放了一段简短的视频，显示seccomp的运行情况。 您也可以在此处下载视频文件。

我们从阻止系统调用的黑名单开始，但是对于真正冒险的用户，您可以先关闭所有系统调用，然后再添加一些。

docker run -d --security-opt seccomp:deny:all --security-opt seccomp:allow:getcwd /bin/sh

实际上，您将需要进行更多的系统调用才能完成此工作。 就像SELinux错误一样，拒绝系统调用将显示在/var/log/audit/audit.log中，如果未运行审核，则将显示在/ var / log / messages中。

未来的Docker

我们将继续研究可以添加的其他安全功能。 如果新的安全功能出现在Linux内核中或得到了改进，我们希望能够在容器中利用这些安全功能。

我们已经开始研究的另一个领域是容器的管理。 当前，如果您可以与网络上的Docker的套接字或端口进行通讯，则可以执行任何操作。 可悲的是，您可以轻松地破坏系统的安全性，这就是为什么我们关闭了非root用户对/run/docker.socket的访问的原因。 我们开始考虑添加授权，因此管理员可以证明他是特定用户。 我们还希望添加适当的日志记录，以便我们可以记录哪个管理员将具有特权的容器运行到syslog / journalctl中。 最后，我们要添加基于角色的访问控制（RBAC），以便管理员可以控制其他管理员可以执行的操作。 例如：

• 管理员1仅允许启动/停止以下容器。
• 管理员2可以在映像foobar上创建非特权容器。
• 管理员3可以运行超级特权容器。

结论

完全实现这些安全功能后，Docker容器将进一步免受主机系统上的安全风险的影响。 目标是始终提高容器的容纳能力。

翻译自: https://opensource.com/business/15/3/docker-security-future

docker 安全性