容器安全技术容器启动安全配置_计算环境安全容器服务未启动

运行时安全

容器启动安全配置

容器以进程的形式运行在主机上，运行的容器进程是隔离的，它拥有自己的文件系统、网络以及独立于主机 的进程树。下面将详细说明如何使用 docker run 1 来定义容器运行时的资源。
4.6.1.1 内核选项配置
（1）启用 AppArmor 安全配置
AppArmor 通过执行安全策略来保护 Linux系统和应用程序
免受各种威胁，这里的安全策略通过 AppArmor 配置文件体现（参考 4.1.4.2）。用户可以为容器创建自己的 AppArmor 配置文件，也可以使用 Docker 默认的 AppArmor 配置文件。- docker run --security-opt=”app
armor=$PROFILE” （2）设置 SELinux 安全选项
SELinux提供了一种有效的 Linux访问控制机
制，在 Docker 服务启动时，建议对 SELinux进行配置。那么在 启动容器的时候，同样建议使用该安全选项，通过为 Docker 容器创建或导入 SELinux策略模板，实现其安全防护。- docker run –security
-opt lable=level:TopSecret （3）内核功能受限使用
Linux内核的 Capabilities 机制，支持 Docker 容器内部仅授予其必要的内核功能，通过移除不必要功能，减 少攻击面来增强其安全性
。例如容器中通常是不需要 NET_ADMIN、SYS_ADMIN、SYS_MODULE等功能的。可以通过以下命令添加 / 删除所需的功能：

• docker run --cap-add={“NET_ADMIN”,“SYS_ADMIN”}
• docker run --cap-drop={“NET_ADMIN”,“SYS_ADMIN”}
  建议在使用过程中，先删除所有的功能，并且只添加自己所需的功能：
• docker run --cap-drop=all --cap-add={“NET_ADMIN”,“SYS_ADMIN”}
  另外，要格外注意 --privileged 选项，该选项可以将所有 Linux内核功能提供给容器，而且还提升了 CGroups 控制器执行的所有限制，也就是说，此时容器几乎可以做任何主机能做的事情，因此如果不是必须的情况下，容 器运行时不要使用 --privileged 选项。在 Linux中，进程可以在内核中设置 no_new_priv ，no_new_priv 确保进程 或其子进程不通过 suid 或 sgid 位获取任何其它权限。
• docker run --security-opt="no-new-privileges:true”
  （4）不要禁用默认的 seccomp 文件
  seccomp（全称 secure computing mode）是 Linux Kernel 从 2.6.23 版本开始所支持的一种安全机制。在 Linux系统里，大量的系统调用直接暴露给用户态程序。但是，并不是所有的系统调用都被需要，而且不安全的
  1　https://docs.docker.com/engine/reference/run/

代码滥用系统调用会对系统造成安全威胁。通过 seccomp，限制程序使用某些系统调用，这样可以减少系统的 暴露面，同时使程序进入一种“安全”的状态。
默认情况下，Docker 会启用 seccomp 配置文件。在 Docker 1.10 版本以后，默认的配置文件会阻止部分系 统调用，即使容器已经进行了 --cap-add 设置，用户可以自定义该文件，通过白名单的方式获取相应的内核系统 调用权限：

• docker run --security-opt=“seccomp=profile.json”
  （5）必要时进行 ulimit 设置
  通常情况下，在 Docker 守护进程的配置中，会对容器的资源分配进行默认的配置，如果某些容器在资源使 用上，需要定制化的配置需求，可以在启动时通过 --ulimit 选项对 Docker 服务的默认配置进行覆盖。
• docker run --ulimit nofile=1024:1024
  （6）内核命名空间不要共享
  Linux通过内核命名空间实现相应的隔离，比如通过 PID命名空间实现了进程之间的隔离，也就是说不同命 名空间中的进程，可以拥有相同的进程 PID。如果容器共享了主机的 PID命名空间，就意味着在容器内能够查看 主机上的所有进程，甚至可以在容器内杀死主机上的进程。
  对于其它的命名空间来说也是一样的，容器和主机之间如果共享了命名空间，也就失去了容器的隔离效果。 因此在容器启动的时候要注意命名空间相关参数的使用，比如不要用“docker run --pid=host”共享主机的 PID 命名空间；不要使用“docker run --ipc=host”共享主机的 ipc 命名空间；不要使用“docker run --uts=host ”共 享主机的 uts 命名空间。

1. 资源管理和控制
   为了预防系统资源耗尽造成的 DoS 攻击，Docker 可以使用特定的参数进行资源限制，如限制容器的 CPU、 内存或磁盘的使用量，实现资源的独占或约束。
   （1）限制容器内存使用的配置
   默认情况下，Docker 主机上的容器可以使用主机的所有内存资源，并不会对每个容器的可用资源进行限制。 用户可以通过限制容器的内存使用量，防止由一个容器耗尽主机资源而导致拒绝服务，进而影响主机上其它容器 的正常运行。
   具体可使用使用“-m”或“–memory ”参数运行容器：

• docker run --memory 256
  （2）限制容器 CPU 使用的配置
  在默认情况下，CPU 使用时间在同一主机的所有容器间平均分配，可使用 CPU 共享功能（–cpu-shares）来 设定优先级。CPU 共享机制允许一个容器的 CPU 占用优先于另一个容器，并且禁止较低优先级的容器频繁地占 用 CPU 资源。这样可确保高优先级的容器更好地运行，且可以有效的防止 CPU 资源耗尽。

比如，具体可使用使用“-c”或“–cpu-shares”参数运行容器：

• docker run --cpu-shares 512
  默认情况下，每个新创建的容器都将有 1024 个 CPU 的份额（可以理解为 100%），上述例子中将 CPU 份额 设置为 512，也就是说这个新创建的容器，会以其它容器 CPU 使用份额的 50% 启动。
  （3）限制容器存储使用的配置
  如果不对容器之间或者主机与容器之间进行数据隔离，攻击者就可以轻易获取重要数据从而造成安全风险， 较好的解决方式是采用写时复制（Copy-on-Write）特性，所有运行的容器共享一个基础文件系统镜像，容器内的 文件系统会与基础文件系统进行交互，这样可以避免容器间的数据共享风险，同时实现数据隔离。
  另外，要严格控制容器的挂载目录，不能将 /dev 、/boot 、/etc 、/sys 等主机的敏感目录作为容器卷进行挂载。 同时在将主机设备通过–device 共享给容器的时候也要特别注意，因为默认情况下，容器能够对这些设备进行读写， 还可能会从主机中删除设备。因此尽量不要直接将主机设备共享给容器，如果必须要共享的话，要适当的限制共 享权限。

1. 网络配置
   （1）不在生产环境的 Docker 主机上使用主机网络模式
   默认的 Bridge 网络模式须通过虚拟化网络技术来创建自己的网络协议栈，与之相比，Host 网络模式由于使 用了主机的本地网络堆栈，会有更好的网络性能。因而当网络性能要求非常高时，有的场景会使用主机网络模式 运行容器。
   但需要注意的是，容器将共享主机的网络堆栈，容器可看到主机的所有接口，这样就给了容器访问本地系统 服务全部的权限，如 D-bus，因此，此模式认为是不安全的，不建议在生产环境中启用。
   （2）尽量不要使用 Docker 的默认网桥 docker0
   默认的 Bridge 网络模式下，Docker 主机上的所有容器均会使用 docker0 网桥进行连接，这种方式会引发 局域网的 ARP欺骗、嗅探、广播风暴等攻击，对这些容器造成安全威胁。不建议在使用容器时直接使用默认的 docker0 网桥。
   建议用户使用自定义的网络进行容器之间的互连，比如使用如下命令，在 Docker 主机上创建自己的网络：

• docker network create --subnet 102.102.0.0/24 test
• docker run --network test …
  或者是利用 Docker Swarm 或者 Kubernetes 等容器集群管理平台，创建集群间的 Overlay 网络：
• docker network create -d overlay overlaynetwork-test
• docker run --network overlaynetwork-test …
  （3）只映射必要的端口
  在端口使用方面要注意以下几个问题：一方面，在 Linux默认情况下，普通用户不能占用 1024 以下的特权端口。 特权端口通常用来接收和发送各种敏感和特权的数据，如果将容器端口映射到主机上的特权端口，将可能带来严 重的影响。

当然，对于将 HTTP 服务绑定 80 端口，HTTPS 服务绑定 443 端口这种必须使用的，不在讨论范围。这里的 特权端口包括 22（SSH 服务）、21（FTP 服务）、25（SMTP 服务）、110（POP3 邮件服务）等。
另一方面，严格审计容器镜像的 Dockerfile 文件，确保只暴露必要的端口。 （4）容器中不要运行 SSH 等不必要的服务
通常用户在使用容器的时候，很自然地会和虚拟机进行类比，比如怎么进入容器内进行调试、sshd 怎么配 置等。要正确的使用容器，一定要有容器化的思维，正确的认识容器。特别是在微服务体系中，容器的本质就是 一个或少数进程以及运行进程所需要的各种依赖，即运行时环境的最小集。
如果在容器中运行了 SSH、TELNET 等服务，不仅不会增加该微服务的功能，反而会带来一系列的安全威胁 以及增加安全运维的复杂度。比如 SSH 服务的访问策略和安全合规性管理、各种容器的秘钥以及密码管理、SSH 服务安全升级等。因此在生产环境中，容器内不应运行 SSH 等不必要的服务。

1. 其它配置
   （1）容器重启策略配置 若不设置容器尝试重新启动的策略，重启服务则会不断的尝试重启容器，极端情况可能会造成主机宕机。
   如果一个容器异常终止，正确的做法应该是限制容器尝试重新启动的策略，并查找终止的原因，而不是无限 地进行重启。在 Docker 下，通过设置 on-failure 限制容器尝试重启的次数。从安全的角度考虑，建议将尝试重启 次数设置为 5。

• docker run --restart=on-failure:5 redis
  （2）避免使用 root 用户来启动容器服务
  CGroups 安全机制就是如果以 root 权限运行容器，容器内的 root 用户也就拥有了主机的 root 权限。要防止 此类攻击，不要为单一的容器分配过多的资源即可避免此类问题。因此在运行容器时应该避免使用 root 用户，应 该使用普通用户启动容器服务。
  （3）检查容器运行时的状态
  如果容器的镜像中没有定义 HEALTHCHECK指令，建议在容器运行时添加 health-cmd 参数检查容器运行情
  况。例如：
• docker run --health-cmd = ‘stat /etc/passwd || exit 1’
  （4）尽可能限制容器拥有的 Linux 内核功能
  对于容器里服务不必要的内核功能（如 Docker 默认的内核功能包括：chown、dac_override、 fowner、 kill、setgid、setuid、setpcap、net_bind_service、net_raw、sys_chroot、mknod、 setfcaph 和 audit_write）， 可以通过 --cap-drop 和 --cap-add 来限制启动。

参考资料

绿盟 容器安全技术报告

友情链接

绿盟 2015全年DDoS威胁报告