docker容器安全风险初探

一、前置知识

容器是系统虚拟化的实现技术，容器技术在操作系统层面实现了对计算机系统资源的虚拟化，通过对CPU、内存和文件系统等资源的隔离、划分和控制，实现进程间的资源使用，实现系统资源的共享。docker容器是使用最广、也是最具代表性的容器，这篇文章就来简单探讨docker容器的安全性，学习docker容器的风险与攻击面。

容器技术的发展史：

容器与虚拟化的区别

虚拟化(Virtualization)和容器(Container)都是系统虚拟化的实现技术，可实现系统资源的“一虚多”共享。 容器技术是一种“轻量”的虚拟化方式，此处的“轻量”主要是相比于虚拟化技术而言的。例如，虚拟化通常在 Hypervisor 层实现对硬件资源的虚拟化，Hypervisor 为虚拟机提供了虚拟的运行平台，管理虚拟机的操作系统运行， 每个虚拟机都有自己的操作系统、系统库以及应用。而容器并没有 Hypervisor 层，每个容器是和主机 共享硬件 资源及操作系统 。容器技术在操作系统层面实现了对计算机系统资源的虚拟化，在操作系统中，通过对 CPU、内存和文件系统 等资源的隔离、划分和控制，实现进程之间透明的资源使用。

docker的安全风险与攻击面

如下主要从承载容器运行的负载平台、容器自身、容器中运行的应用、容器编排工具 这几个维度来说明，当然也有别的维度。

承载容器运行的负载

我们都知道，容器与宿主机共享操作系统内核，因此宿主机的配置对容器的运行安全有着至关重要的影响。

然而，随着云原生时代的到来，此处的『宿主机』不限于物理主机，可能是公有云、私有云、甚至混合云的环境，可以统称为『工作负载』；这种横跨物理机、公有云、私有云、混合云等环境时，可以参考云工作负载保护平台（CWPP），当然CWPP不在本次的讨论范围内。

常见的加固建议有：

  • 最小化安装：禁止不必要的端口、不安装额外的服务与软件等；
  • 为容器的存储安装单独的分区；
  • 工作负载加固：主机安全加固、云工作负载平台加固，保证符合安全规范；
  • 更新容器到最新版本；
  • 守护进程的控制权限、行为审计
  • docker相关的文件和目录进行审计

docker容器本身

  1. docker的几种网络模式

  • 桥接模式（bridge）：在默认的bridge网络模式下，docker主机上的容器都会使用docker0这个网关，容易造成ARP欺骗、端口嗅探等，建议是自行给容器分配网络 或使用docker swarm、kubernetes等容器集群管理平台，创建集群间的overlay网络。

  • 主机模式（host）:host模式会有更好的网络性能，因为其使用了主机的本地网络堆栈，共享网络命名空间（漏洞案例：host模式容器逃逸漏洞 cve-2020-15257）；但此时 容器将共享主机的网络堆栈，容器能看到主机的所有端口，使容器有了访问主机本地系统服务的全部权限。

  • none模式：在这种模式下，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。

  • container模式：这个模式指定新创建的容器和已经存在的一个容器共享一个Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的，两个容器进程通过lookback网卡通信。

  1. 逃逸风险
    容器逃逸攻击与虚拟机逃逸攻击相似，利用虚拟化软件存在的漏洞，通过容器获取主机权限入侵主机，以达到攻击主机的目的。

具体地，一些 PoC 工具，如 Shocker[48]，可展示如何从 Docker 容器逃逸并读取到主机某个目录的文件内容。 Shocker 攻击的关键是执行了系统调用 open_by_handle_at 函数，Linux 手册中特别提到调用 open_by_handle_at 函数需要具备 CAP_DAC_READ_SEARCH 能力，而 Docker1.0 版本对 Capability 使用黑名单管理策略，并且没有 限制CAP_DAC_READ_SEARCH 能力，因而引发了容器逃逸的风险。

  1. 镜像风险

  • 构建安全
    构建方式有基于容器的和基于dockerfile的，风险包括如下：
    1）. pull 的基础镜像并不是由可信的组织和人员发布，镜像本身存在后门或者其它风险项。
    2）. 在 Dockerfile 中存储敏感信息。例如配置服务时中使用明文固定密码或凭证等。
    3）. 安装不必要的软件扩大了攻击面。

  • 仓库安全
    1）.公共仓库安全：
    例如：docker hub，据说30%的docker镜像存在安全漏洞，在享受docker hub带来的便利时也要确保下载镜像的安全性：
    - 选择官方镜像最新版本
    - 下载的镜像需要经过漏洞扫描，需要覆盖操作系统层面和应用层面
    - 对于提供了公开dockerfile的镜像优先选择自己构建，可避免镜像后门植入，确保构建过程的安全可控

2). 私有仓库的安全
例如 docker registry和harbor
- 对于docker registry，一方面是考虑docker registry本身的安全性，例如在使用时配置相应的安全证书；另一方面是考虑docker客户端与docker registry交互过程中的安全性，也就是实现用户访问权限限制（密码鉴权、双向ssl机制等）

  • 镜像扫描
    比较主流的镜像扫描引擎有docker security scanning（不开源）、clair（开源）和anchore（开源）等。

镜像检测的核心目前仍然是已知系统 CVE 检测。扫描器获取到镜像后，将它分离成相应的层和软件包 （Package）。然后这些 Package 将与多个 CVE 数据库 Package 的名称和版本进行对比，从而判定是否存在漏洞。还有一些通过扫描镜像中的环境变量、操作命令以及端口开放信息来识别恶意镜像的方案，但仍然需要使用 者自己基于结果来判断，还不能直接给出一个明确的结果。

容器上承载的应用

  1. 微服务
    服务软件从单一的应用程序迁移为基于容器的大量微服务，在带来许多好处的同时也改变了软件内部的通讯 模式。从网络和安全角度来看，最显著的变化是内部网络的东西向通信流量剧增，边界变得更加模糊。尽管每个 运行中的容器都可以被加固，也可限定有限的对外网络通信接口，但因为通信接口总量的激增，也给网络攻击者 探测和发现漏洞带来更多机会在这种动态变化的容器环境中，传统网络防火墙不仅难以看到容器之间的网络流量，而且随着容器的快速启 动和消失，它也无法适应这种持续的变化。正如一位网络安全架构师所说：“在一个容器化的世界里，你无法手 动配置 Iptables 或手动更新防火墙规则。”

云原生的环境中，需要对应的云原生容器防火墙，它能够隔离和保护应用程序容器和服务。即使在容器动态扩展或缩小的情况下也会自动实现发现、跟随和保护。

微分段是比传统以网络地址为粒度的分段更细的隔离机制，例如可以是单个容器、同网段的容器集合或容器 应用等。微分段也是容器防火墙的基本功能之一，容器防火墙可感知第七层或者应用层，根据上层应用对连接进 行动态的控制，因而容器防火墙可实现面向业务的动态微分段，成为了保护东西向流量场景中容器免受恶意攻击 第一道防线。

容器防火墙主要是针对保护容器之间的网络会话，面向东西向场景，所以并不会取代部署在数据中心入口处 的防火墙等系统，比如 NGFW、IDS/IPS或WAF。相反，容器防火墙和传统防火墙协同合作，可以有效防止内部应用程序级别的攻击。

编排安全

容器技术的成熟推动者微服务的发展和落地，企业逐渐采用微服务架构来组件自己的应用，其中容器编排工具管理者承载各类服务的容器集群。以社区热度最高的kubernetes编排工具来举例说明编排工具的需要的安全防护措施。

  1. 计算资源安全：PodSecurityPolicy是集群级别的资源控，用于控制 Pod 规范以及管理 Pod 安全，PodSecurityPolicy 对象定义了一组必须运行的条件以及相关字段的默认值， 集群管理员通过 PodSecurityPolicy 可以控制以下内容。

  2. 集群安全

  • 控制kubermetes API访问
    Kubernetes 的 API Server 针对所有 API 流量使用了安全传输协议(TLS)以确保服务间访问的安全性，另外 又提供了访问认证、访问授权、Admission Control 等访问控制机制。

  • 控制对kubelet的访问
    kubelet的HTTPS端点公开了API，这些API授予了节点上容器强大的控制权，默认情况下允许对此API进行未授权认证的访问。生产环境集群中建议开启kubelet身份验证和授权。

  • 控制集群运行时工作负载和用户的能力：限制集群中资源的使用、控制root权限运行容器、限制网络访问、控制pod访问

  • 保护集群中各组件
    限制对etcd的访问：对于 API 来说，拥有 Etcd 服务器后端的写权限相当于获得了整个集群的 root 权限。在 API Server 访问 Etcd 服务器时，管理员应该使用广受信任的凭证，比如通过 TLS 客户端证书的相互认证。通常建议将 Etcd 服务器隔 离到只有 API Server 可以访问的防火墙后面；

  • 对Etcd数据进行加密；

  • 启用审计日志
    Kubernetes 启用审计日志来记录 API 发生破坏时进行后续的分析操作。

  • 限制对Alpha或Beta的访问（Alpha和Beta的特性还处在开发阶段，可能会有限制而导致安全漏洞）

  • 开启集成前审查第三方：许多集成至 Kubernetes 的第三方插件都可以改变集群的安全配置，所以在启用第三方插件时，应当检查扩展请求的权限，Kubernetes 中的 Pod 安全策略(PodSecurityPolicy)可以提高其安全性。

  • 频繁回收基础证书：Kubernetes 中一个 Secret 或凭据的寿命越短，攻击者就越难使用该凭据，所以在证书上设置短生命周期并 实现自动回收证书是安全防护的一个好办法。因此使用身份验证机制时，应该设置发布令牌的可用时间，尽量缩 短寿命。

开源检测工具

主流厂商

posted @ 2020-09-28 17:29  人间修行  阅读(1417)  评论(0)  编辑  收藏  举报