docker 安全性_使用最新的安全性增强来调整Docker

docker 安全性

自从我写了有关Docker安全性的系列文章的前两篇 文章以来已经有一段时间了。 本文将提供自那时以来已添加到Docker的最新信息，并涵盖与上游Docker合并过程中正在经历的新功能。

调整能力

在之前的文章中，我介绍了基于Linux功能的容器分离。

Linux功能使您可以将root的权限分解为较小的特权组。 当前，默认情况下，docker容器仅具有以下功能。

CHOWN, DAC_OVERRIDE, FSETID, FOWNER, MKNOD, NET_RAW, SETGID, SETUID, SETFCAP, SETPCAP, NET_BIND_SERVICE, SYS_CHROOT, KILL, AUDIT_WRITE

在某些情况下，您可能需要调整此列表，例如，如果要构建一个运行ntpd或crony的容器，则该容器需要能够修改主机系统时间。 该容器无法运行，因为它需要CAP_SYS_TIME。 在旧版本的docker中，容器必须以--privileged模式运行，这将关闭所有安全性。

在docker-1.3 --cap-add中，添加了--cap-drop。 现在，为了运行一个ntpd容器，您可以运行：

docker run -d --cap-add SYS_TIME ntpd

这只会将SYS_TIME功能添加到您的容器中。

另一个示例是，如果您的容器未更改任何进程的UID / GID，则可以从容器中删除这些功能，从而使其更加安全。

docker run --cap-drop SETUID --cap-drop SETGID --cap-drop FOWNER fedora /bin/sh

# pscap | grep 2912
5417 2912 root sh chown, dac_override, fsetid, kill, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap

或者，您可以放弃所有功能，然后再添加一项。

docker run --cap-drop ALL --cap-add SYS_TIME ntpd /bin/sh

# pscap | grep 2382
5417 2382 root sh sys_time

调整SELinux标签

与功能相似，我们增加了即时调整SELinux标签的功能。

如果您看过SELinux图画书 ，您就会知道我们可以按类型和按MCS / MLS级别将过程分开。 我们使用类型来保护主机免受容器侵害。 但是我们也可以调整类型以控制允许哪些网络端口进出容器。 当前，我们使用svirt_net_lxc_t运行所有容器。 允许在所有网络端口上侦听此类型，并允许在所有网络端口上进行连接。 我们可以通过调整SELinux类型标签来加强容器的安全性。

使用常规SELinux和Apache httpd，默认情况下，我们仅允许apache进程监听Apache端口（http_port_t）。

# sudo sepolicy network -t http_port_t

http_port_t: tcp: 80,81,443,488,8008,8009,8443,9000

我们还将阻止所有传出端口连接。 这可以帮助我们锁定Apache进程，即使黑客要用ShellShock这样的安全漏洞破坏应用程序，我们也可以阻止该应用程序成为垃圾邮件机器人，或者阻止该进程发起对其他系统的攻击。 就像加利福尼亚酒店一样，“您可以随时登记入住，但永远都不能离开。”

但是，如果使用容器，则如果您正在容器中运行Apache服务器应用程序，并且该应用程序已被破坏，则Apache进程将能够连接到任何网络端口并成为垃圾邮件机器人，或通过网络攻击其他主机/容器。

使用SELinux创建新的策略类型以与您的容器一起运行非常简单。 首先，您可以创建SELinux TE（类型强制）文件。

# cat > docker_apache.te << _EOF

policy_module(docker_apache,1.0)

# This template interface creates the docker_apache_t type as a
# type which can be run as a docker container. The template
# gives the domain the least privileges required to run.
virt_sandbox_domain_template(docker_apache)

＃我知道容器中的apache守护程序将需要
＃运行一些功能。 幸运的是我已经有政策
＃Apache和我可以查询SELinux的功能。
＃sesearch -AC -s ​​httpd_t -c功能
允许docker_apache_t self：功能{chown dac_override kill setgid setuid net_bind_service sys_chroot sys_nice sys_tty_config};

＃这些是允许容器侦听的规则
＃到网络上的Apache端口。

allow docker_apache_t self:tcp_socket create_stream_socket_perms;
allow docker_apache_t self:udp_socket create_socket_perms;
corenet_tcp_bind_all_nodes(docker_apache_t)
corenet_tcp_bind_http_port(docker_apache_t)
corenet_udp_bind_all_nodes(docker_apache_t)
corenet_udp_bind_http_port(docker_apache_t)

＃Apache需要根据DNS服务器解析名称
sysnet_dns_name_resolve（docker_apache_t）

＃允许域允许进程不被SELinux阻止
＃在制定和测试策略时，您可能想要
＃以允许模式运行容器。
＃如果您对
＃政策。
允许的docker_apache_t;
_EOF

＃make -f / usr / share / selinux / devel / Makefile docker_apache.pp
＃semodule -i docker_apache.pp

现在使用新类型运行容器：

# docker run -d --security-opt type:docker_apache_t httpd

现在，此容器将以比普通容器更严格的SELinux安全性运行。 请注意，您可能需要查看审核日志，以查看您的应用是否需要其他SELinux允许规则。

您可以使用audit2allow命令添加这些规则，并将这些规则附加到现有的.te文件中，然后重新编译并安装。

# grep docker_apache_t /var/log/audit/audit.log | audit2allow >> docker_apache.te
# make -f /usr/share/selinux/devel/Makefile docker_apache.pp
# semodule -i docker_apache.pp

多级安全模式

当前，我们使用MCS分离来确保不允许容器干扰其他容器或与其他容器进行交互，除非它是通过网络进行的。 某些政府系统需要不同类型的策略MLS（多级安全性）。 使用MLS，您可以根据进程将看到的数据级别来标记进程。 MLS说，如果您的容器将要处理TopSecret数据，则应在TopSecret上运行。 我们在docker中添加了选项，以允许管理员将容器设置为在特定级别运行，这应满足MLS系统的需求。

docker run -d --security-opt label:level:TopSecret --security-opt label:type:docker_apache_t httpd

这将使docker容器可以同时使用替代类型和级别运行，并且可以防止容器使用不在同一标签上的数据。 目前，这还没有通过认证，但是我们愿意帮助第三方为MLS用户建立解决方案。

调整名称空间

在其他安全性讨论中，我讨论了如何将命名空间视为一种安全机制，因为从查看系统上的其他进程（PID命名空间）中消除了一个进程的能力。 网络名称空间可以消除从您的名称空间查看其他网络的能力。 IPC（进程间通信）名称空间具有阻止容器使用其他容器IPC的功能。

Docker现在可以放松这些限制。 您可以与容器共享主机名称空间：

--pid = host让容器共享主机的pid名称空间
--net = host让容器共享主机的网络名称空间
--ipc = host允许容器共享主机ipc名称空间

请注意，由于要与主机共享PID或IPC名称空间，因此我们必须禁用SELinux分隔，才能使它们起作用。

docker run -ti --pid=host --net=host --ipc=host rhel7 /bin/sh

您可能需要阅读《 Super Privileged Containers 》一文中的其他信息。

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

docker 安全性