容器云平台常见风险和基础安全设计

1 容器云平台风险及挑战

容器云平台是通过容器编排引擎及容器运行时等技术提供应用运行平台，从而实现运维自动化、快速部署应用、弹性伸缩和动态调整应用环境资源，进而提高研发运营的效率，目前市场上主流的容器云平台是基于Google Kubernetes（简称k8s）容器编排引擎和容器引擎建立。本文中介绍内容也是针对此类的容器云平台。

作为平台级的容器环境，比以往任何的基础架构平台更加的接近业务，同时也包含了更多的层级和组件，因此也带来了更多的风险；目前容器安全也是一个信息安全的新兴领域，该领域的技术和产品也在不断完善中，下面我们先从风险的角度列举几个常见的例子，让大家对容器平台安全有个感性认识：

1.1 软件漏洞风险

容器的设计虽然实现了良好的操作系统级隔离，但同时也存在很多安全隐患，比如容器是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机的操作系统内核，其次在Linux内核中，有很多资源和对象是不能被Namespace化的，最典型的例子是：时间，即如果某个容器修改了时间，那整个宿主机的时间都会随之修改，非计划内的修改系统时间，对于时间敏感的应用可能引起数据错误甚至进程crash，老版本Oracle数据库就存在这样的问题。

Kubernetes作为容器编排引擎，如果在规划和部署架构方面存在缺陷，同样会和传统环境一样容易受到外部攻击者和具有恶意的内部人员的攻击。因此，需要保障大型容器云环境具有正确的安全部署体系结构，并为应用上云提供安全最佳实践。

根据国家信息安全漏洞库的统计，截止2019年1月2日，Docker相关的漏洞共40个，其中包括Apache、RedHat、hyper、boot2docker、Jenkins等厂商产品或开源项目。

2018年，Kubernetes生态系统因发现Kubernetes的第一个主要安全漏洞（Kubernetes特权升级漏洞 CVE-2018-1002105）而动摇。该漏洞使攻击者能够通过k8s api server实现提升k8s普通用户到k8s api-server的最高权限，然后运行代码来安装恶意软件，进而破坏k8s集群。除此之外还有CVE-2019-11245 Kubernetes kubelet v1.13.6 and v1.14.2提权漏洞，实现了在通常情况下以容器Dockerfile中指定的USER运行的容器，有时可以以root身份运行（在容器重启时，或者如果镜像先前被拉到节点）。这种情况的出现违反了容器禁止以root（容器内进程运行用户是root）运行的最佳实践。

1.2 API安全风险

此部分集中关注容器云平台基础组件提供的api服务的安全问题，比如k8s api server，如果在构建容器云平台时扩展或者封装了平台管理api，也需要关注并进行加固。

Docker很多服务默认监听在Unix Socket上，比如unix:///var/run/docker.sock，为了实现集群管理，还提供了一个远程管理接口的REST API，允许通过TCP远程访问服务。开启没有任何加密和访问控制的Docker Remote API服务是非常危险的。尤其是将默认的2375端口暴露到互联网中，一旦被攻击者发现，攻击者无需认证即可访问到容器数据，从而导致敏感信息泄露，也可以恶意删除容器上的数据，或可进一步利用容器自身特性，直接访问主机上的敏感信息，获取服务器root权限，对敏感文件进行修改并最终完全控制服务器。

在容器编排引擎kubernetes通过api server服务提供以下能力：

1．提供了容器平台管理的REST API接口；

2．提供其他模块之间的数据交互和通信的枢纽;

3．资源配额控制的入口；

4．应用部署的接口；

通俗来讲，api server就是整个容器平台的入口，任何用户和程序对集群资源的增删改查操作都可以通过api server实现。因此，为了保证集群的安全，API-server需要提供完备的安全机制。

1.3 镜像安全风险

开发者通常会在公共仓库下载镜像，这些镜像一部分来源于开发镜像相应软件的官方厂商，但还有大量镜像来自第三方组织甚至个人。比如一些自由软件，由于开源和自由获取等特性在大量使用，同时由于没有固定商业组织进行支持，此类软件的镜像多数是社区维护，镜像的质量参差不齐，更有甚者，可能镜像就是不怀好意的黑客制作，如果一旦此类镜像在生产环境使用，势必造成安全隐患。

此外，在整个应用开发生命周期中，开发人员、测试人员和运维人员都有可能根据不同需求下载并运行第三方镜像，所以在容器运行前进行镜像检查非常重要。

1.4 网络安全风险

企业内部容器云平台一般在边界上有很强的安全保障措施，但是在容器云平台内部，基于默认的网络模型，比如flannel，各个容器pod节点是扁平的，在横向网络访问隔离方面缺少必要的安全保障，基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型，优势是成熟，简单，但却缺乏访问控制。

企业内部容器云平台一般在边界上有很强的安全保障措施，但是在容器云平台内部，基于默认的网络模型，比如flannel，各个容器pod节点是扁平的，在横向网络访问隔离方面缺少必要的安全保障，基于flannel方案在容器云平台构建实践中是较普遍采用的网络模型，优势是成熟，简单，但却缺乏访问控制。

企业需要在构建容器云平台时考虑如何增强网络访问控制，进而提升网络安全。

2 容器云平台安全设计之基础安全设计

容器云平台架构

典型容器云平台，参照上面平台架构设计，包括如下几部分，从下到上包括分别是：

• 基础设施

• 容器云平台基础组件部分

• 容器云管理平台部分

• 业务应用部分

• 平台支持系统部分

其中，基础设施部分是容器云平台的基石，提供了容器云平台的运行基础计算、网络、存储资源。此部分和原来传统数据中心运行的情况一致，安全要求也没有明显变化，因此相关安全设计要求参照原来数据中心设计规范进行设计以及实现，不作为容器云安全设计的重点。

容器云平台基础组件部分提供容器云基础功能，主要包括容器运行时实现和编排引擎，其中运行部分包括虚拟化，软件定义网络，软件定义存储，编排引擎主要是kubernetes软件；容器云管理平台部分主要实现了容器平台的核心功能，比如容器调度功能，账户功能（也称租户功能），镜像管理功能，持续集成持续交付部分，此外还包括图形化和命令行管理接口以及方便第三方对接的平台API接口。容器平台基础组件部分和容器云管理平台部分是容器云平台安全设计的关键。

业务应用部分，主要是容器平台上部署的业务应用，有些容器云平台也提供了应用市场功能。根据云平台责任分担模型，此部分安全是业务功能实现方提供，云平台给出一定的安全最佳实践指导。

平台支持系统部分主要是容器平台自建或者对接的第三方系统，比如日志、监控、告警，代码管理，账户管理等。此部分系统对于容器云平台运行至关重要，但是相关系统的安全设计不在本次重点考虑范围内。

容器云平台是一个多模块组成的复杂系统，各个组合模块的安全需要独立设计以及实现，结合上面容器平台的架构，给出容器云平台安全设计架构图，如下：

容器云平台安全架构

2.1 容器运行时安全

容器运行时通常会给管理员提供多种配置选项。容器运行时配置不当会降低系统的相对安全性。例如，在Linux容器主机上，经允许的系统调用集合通常默认仅限于容器安全运行所必需的调用。如果该列表被扩大，则被入侵的容器会让其它容器和主机操作系统面临更大风险。同样，如果容器在特权模式下运行，则可以访问主机上的所有设备，从而让其本质上成为主机操作系统的一部分，并影响在主机操作系统上运行的所有其它容器。

运行时配置不安全的一个示例是允许容器在主机上挂载敏感目录。容器通常很少会对主机操作系统的文件系统进行更改，而且几乎不应该更改控制主机操作系统基本功能的位置(例如，Linux容器的/boot或/etc、Windows容器的C:\Windows)。如果允许遭到入侵的容器更改这些路径，那么，也可以被用来提权并攻击主机本身以及主机上运行的其它容器。

1．安全基线

• 建设安全基线（参照附件5和6）持续改进

• 建设安全基线检测自动化工具

• 建设容器资产清单工具，实时洞察容器运行状况

2．容器运行风格选择

容器运行风格方面，其实有多种选择，采用何种容器运行风格也是安全考虑的问题之一：

常见运行风格：

瘦容器(Thin Container):单进程应用的封装，在镜像中打包应用。这非常适于微服务架构应用的服务交付。

胖容器(Fat Container):多进程应用的封装，在镜像中打包应用。容器引擎对进程管理的特殊性，我们会利用init.d/systemd或者supervisor等来启动管理进程。但是容器应该尽可能是单一目的，容器中的进程应该是紧耦合的，并有一致的生命周期。比如可以将“nginx”和“php-fpm”打包在一个容器镜像中。

VM容器(VM Container):是利用容器模拟轻量级虚拟机:镜像本身不包含应用，需要利用在容器启动后动态安装和配置应用。这是不建议的方案，会造成容器中应用配置管理和更新的复杂性。如业务应用暂时无法改造，需要制定过渡方案。一般而言，不建议选择VM容器风格。

2.2 Kubernetes运行时安全

目前主流的容器云管理平台一般基于kubernetes构建，kubernetes平台采用分布式架构方式构建，根据平台功能由多个组件组成，如下图。典型的组件包括api server，etcd，sheduler，controller manager，kubelet，kube-proxy，cAdvisor，Plugin networks（比如flannel）等。

以上组件是容器云平台的控制（管理）平面，是容器云平台的大脑，全面洞察集群上的每一个容器和pod，并且调度新的pod，读取和存储集群中的所有私密信息，因此在通讯和数据存储和传输方面均需要严格安全包括，主要措施包括：

组件安全基线

Kubernetes安全运行需要满足必要的配置基线，关于基线建设包括：

• 建设安全基线（参照NIST规范，CIS benchmark）持续改进

• 建设安全基线检测自动化工具

组件之间通信加密

为了实现组件之间的安全，设计要求组件之间应该启用TLS，支持TLS以防止流量嗅探、验证服务器身份以及（对于相互TLS而言）验证客户端身份。

需要开启的TLS通讯包括：

1．API Server和etcd之间

2．API Server和Controller Manager之间

3．API Server和Scheduler之间

4．API Server和Kubelet之间

5．平台管理用户和API Server之间

6．Kubelet和容器之间

7．业务用户和业务pod之间（可选）

参考下图：

2.3 网络安全

网络隔离

K8s的网络策略应用于通过常用标签标识的pod组。然后，使用标签来模拟传统的分段网络，这些网络通常用于在多层应用程序中隔离层：例如，可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。

简单路由网络或常用的flannel网络程序本身不能应用网络策略。

目前Kubernetes只有几个支持网络策略的网络组件：Romana，Calico和Canal；其中Weave在不久的将来指示支持，Red Hat的OpenShift包括了网络策略功能。因此如何容器云平台基于OpenShift构建会获得OOTB的网络策略功能。

从网络模型的流行度来看，flannel的网络方案最流行，市场占有率较大，基于calico+network policy的方案逐步成熟中，可以持续跟进，在容器云构建中可以在测试环境中进行验证。

在一些落地的方案中，容器云平台建设过程中采用flannel的方案，但是通过为不同安全级别的应用（租户）建设不同的集群而实现应用（租户）网络隔离。

南北向流量的安全

对于南北向的流量，应该引入传统的网络流量分析控制设备，例如IPS/IDS/审计/NGFW/WAF等。

东西向流量的安全

东西向流量的安全也是非常关键的，目前可以采用的技术和产品比较少，但这个方面却是非常关键的安全控制点，在没有合适的产品可以替代的情况下，应该尽量：

1．采用Mini Knernel的容器化操作系统；

2．非特权用户运行容器；

3．采用强制访问控制技术；

4．监控宿主机文件系统的变更；

5．保持系统和组件的安全补丁为最新。