来源：https://www.cnblogs.com/ffx1/p/13745919.html

1. 介绍

容器是系统虚拟化的实现技术，容器技术在操作系统层面实现了对计算机系统资源的虚拟化，通过对 CPU、内存和文件系统等资源的隔离、划分和控制，实现进程间的资源使用，实现系统资源的共享。
**
Docker 容器是目前使用最广，也是最具代表性的容器，下面主要学习 docker 容器的安全性。

1.1 容器技术的发展史

Container Security - 图1

1.2 容器与虚拟化的区别：

虚拟化 (Virtualization) 和容器 (Container) 都是系统虚拟化的实现技术，可实现系统资源的“一虚多用”共享。

容器技术是一种“轻量”的虚拟化方式，此处的“轻量”主要是相比于虚拟化技术而言的。

虚拟机通常在 Hypervisor 层实现对硬件资源实现虚拟化，Hypervisor 为虚拟机提供了虚拟的硬件运行平台，在虚拟硬件上安装操作系统，管理虚拟机的操作系统运行， 每个虚拟机都有自己的操作系统、系统库以及应用。

而容器并没有 Hypervisor 层，每个容器是和主机 共享硬件 资源及操作系统 。容器技术在操作系统层面实现了对计算机系统资源的虚拟化，在操作系统中，通过对 CPU、内存和文件系统 等资源的隔离、划分和控制，实现进程之间透明的资源使用。
Container Security - 图2

2. docker 的安全风险与攻击面

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

2.1 承载容器运行的负载平台

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

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

常见的加固建议有：

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


2.2 docker 容器本身

2.2.1 docker的几种网络模式

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

  • 主机模式（host）：host 模式会有更好的网络性能，因为其使用了主机的本地网络堆栈；但此时容器将共享主机的网络堆栈，容器能看到主机的所有端口，使容器有了访问主机本地系统服务的全部权限。

  • MacVLAN 模式：这是一种轻量级网络虚拟化技术，MacVLAN 与主机的网络接口连接，MacVLAN 相比于桥接，网络驱动加强了与实体网络的隔离性，但是在该网络驱动中，同一个虚拟网络下的容器之间没有进行权限管控，攻击者可以轻易获得容器权限并进行网络攻击。对此 Docker 官方提供了一些扩展插件来实现对容器权限细粒度的控制，例如网络插件（Network Plugins） 可以提供容器间互联网络模型；数据卷插件（Volume Plugins）可以使 docker 数据卷跨多个主机；验证插件（Authorization Plugins）可提供基于权限的访问控制等。

  • overlay network 模式：利用 VXLAN 技术，在不同主机间的 Underlay 网络之上再组成新的虚拟网络。最为明显的弊端是 VXLAN 网络上的流量没有加密，传输内容很容易被攻击者盗取或篡改。

2.2.2 逃逸风险

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

具体地，一些 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 能力，因而引发了容器逃逸的风险。

2.2.3 镜像风险

  • 构建安全

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

  • 镜像仓库安全

    • 公共仓库安全：例如 docker hub，据说30%的 docker 镜像存在安全漏洞，在享受 docker hub 带来的便利时也要确保下载镜像的安全性：
      • 选择官方镜像最新版本；
      • 下载的镜像需要经过漏洞扫描，需要覆盖操作系统层面和应用层面；
      • 对于提供了公开 dockerfile 的镜像优先选择自己构建，可避免镜像后门植入，确保构建过程的安全可控；
    • 私有仓库的安全：例如 docker registry、harbor
      • 对于 docker registry，一方面是考虑 docker registry 本身的安全性，例如在使用时配置相应的安全证书；另一方面是考虑 docker 客户端与 docker registry 交互过程中的安全性，也就是实现用户访问权限限制（密码鉴权、双向 ssl 机制等）；

  • 镜像扫描

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

2.3 容器上承载的应用

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

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

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

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

2.4 服务编排安全

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

2.4.1 计算资源安全

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

2.4.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 或 Bet a的访问（Alpha和Beta的特性还处在开发阶段，可能会有限制而导致安全漏洞）

  • 开启集成前审查第三方

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

  • 频繁回收基础证书

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

3. 开源检测工具