云原生环境中存在哪些风险？

随着越来越多的云原生应用落地和使用，其相关的安全风险与威 胁也不断涌现。

一、容器化基础设施的威胁风险

在实现云原生的主要技术中，容器作为支撑应用运行的重要载体为应用的运行提供了隔离和封装，因此成为云原生应 用的基础设施底座。云原生架构的安全风险包含容器化基础设施自身的安全风险，容器化部署则成为云原生计算环境 风险的输入源。

1．容器全生命周期的威胁风险 容器的秒级启动或消失的特性以及持续频繁的动态变化，极大程度地缩短了生命周期，但也增加了安全保护的难度和 挑战。容器的安全问题，在容器全生命周期（创建、分发、运行、停止）的各个阶段都存在相应的风险和威胁隐患。

（1）容器镜像构建阶段存在的风险 随着容器技术的普及，容器镜像也成为了软件供应链中重要的一环。因此，当业务依赖的基础镜像存在安全漏洞或者 包含恶意代码时，其潜在危害比黑客从外部发起攻击要严重得多。

“镜像漏洞利用”指的是镜像本身存在漏洞时，依据镜像创建并运行的容器通常也会存在相同漏洞，镜像中存在的漏 洞会被攻击者用以攻击容器的情况。这种行为往往会对容器造成严重影响。备受开发者青睐的 Alpine 镜像曾曝出过 一个漏洞，编号为 CVE-2019-5021。在 3.3 到 3.9 版本的 Alpine 镜像中，root 用户密码被设置为空，攻击者在攻入容 器后获得容器内部 root 权限的机会增大。

镜像投毒是一个宽泛的话题。指的是攻击者通过某些方式，如上传镜像到公开仓库、入侵系统后上传镜像到受害者本 地仓库以及修改镜像名称假冒正常镜像等，欺骗、诱导受害者使用攻击者指定的恶意镜像创建并运行容器，从而实现 入侵或利用受害者的主机进行恶意活动的行为。 根据目的不同，常见的镜像投毒有三种类型：投放恶意挖矿镜像、投放恶意后门镜像和投放恶意 exploit 镜像。

投递恶意挖矿镜像。这种投毒行为主要是通过欺骗受害者在机器上部署容器的方式获得经济收益。2018 年 6 月，一 份研究报告指出，一个名为 docker123321 的账号向 Docker Hub 上陆续上传了 17 个包含挖矿代码的恶意镜像。截 至 Docker Hub 官方移除这些镜像时，它们已经累计被下载超过 500 万次。据统计，黑客借助这一行为获得了市值约 9 万美元的门罗币。

投放恶意后门镜像。这种投毒行为的主要目的是控制容器。通常，受害者在机器上部署容器后，攻击者会收到容器反 弹过来的 Shell。在 2017 年 9 月，有用户在 Docker Hub 的反馈页面中反馈前述 docker123321 账号上传的 Tomcat 镜像包含了后门程序。结合该账号上传的其他恶意镜像的挖矿行为可推测出攻击者在连接上述后门后会部署挖矿程序 以此获得经济收益的可能性。 投放恶意 exploit 镜像。这种投毒行为是为了在受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸，以 实现对受害者机器更强控制。从攻防对抗的角度来看，恶意 exploit 镜像只不过是一种攻击载荷投递方式，其特点在 于具有隐蔽性和可能产生巨大的影响范围。试想，如果 Docker Hub 上某一热门镜像包含了某个 1day 甚至 0day 漏 洞的利用程序，理论上，攻击者将一下子获取上百万台计算机的控制权限。

（2）容器镜像分发阶段存在的风险 镜像的安全需要重点建设。镜像的安全性会直接影响容器安全，因为容器镜像在存储和使用的过程中，可能会被植入 恶意程序或修改内容以此篡改。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。

（3）容器运行时存在的风险 在容器运行时存在的安全问题中，“容器逃逸”是最具代表性的高风险安全问题。攻击者可通过利用漏洞“逃逸”出 自身拥有的权限，实现对宿主机或者宿主机上其他容器的访问，同时带来进行时资源耗尽的风险。

（4）容器网络存在的风险 在网络安全方面，由于 K8S 默认不做网络隔离，传统物理网络的攻击手段依然有效（如 ARP 欺骗、DNS 劫持、广播 风暴等）。同时，攻击者可利用失陷的容器进行针对 K8s 集群内部、内网主机的横向渗透； 容器网络环境也面临着“访问关系梳理难，控制难”的痛点。比如：东西向访问流量庞大，无法感知业务间访问关系； 业务访问关系错综复杂，无法制定精细化的访问控制策略；静态策略无法跟随虚拟机自动迁移；容器平台体量巨大， 上下线周期短，容器 IP 地址变化频繁，难以适配容器环境等等。

2．宿主机的威胁风险 容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机中安装有漏洞的 软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问风险，防火墙未正确配置会降低主机的 安全性，没有按照密钥的认证方式登录可能会导致暴力破解并登录宿主机等。安全是一个整体，任何一个环节出问题， 都会影响到其他环节。应用安全可影响到容器安全，容器逃逸可影响到虚拟主机及容器集群的安全，虚拟主机逃逸会 影响到虚拟化基础设施的安全。

3．容器化开发测试过程的威胁风险 DevOps 所倡导的理念是追求敏捷、协作与快速迭代。开发人员往往为了追求便捷的开发环境与快速的迭代节奏选择 将安全系统配置（如权限管理、访问控制等）的优先级降低，为效率与敏捷让步，最终可能使敏感数据权限管理不当 而在容易发生泄露、系统资源无防护的内部开放。若研发环境采用传统安全防护措施，一旦边界防御措施被突破，内 部数据与资源将会对外部攻击者完全开放，产生不可估量的损失与影响。

二、容器编排平台的风险分析

在云原生环境中，编排系统无疑处于重中之重的地位。任何编排系统都会受到一些攻击，这些攻击会影响部署的整体 安全性和运行时的持续安全性。而 Kubernetes 早已成为容器编排系统的“事实标准”，下面对容器编排平台的风险 进行分析。

1．Kubernetes 组件不安全配置 Kubernetes 编排工具组件众多、各组件配置复杂，配置复杂度的提升增加了不安全配置的概率。不安全配置引起的 风险不容小觑，比如 Kubernetes API Server 的未授权访问，Kubernetes Dashboard 的未授权访问，Kubelet 的未授 权访问等，都可能会导致编排工具中帐户管理薄弱，或部分帐户在编排工具中享有很高特权，入侵这些账户可能会导 致整个系统遭到入侵。

2．Kubernetes 提权 Kubernetes 非法提权，是指普通用户获得管理员权限或 Web 用户直接提权成管理员用户。编排工具可能存在多种 漏洞导致此类攻击，Kubernetes 权限提升。以 CVE-2018-1002105 漏洞为例，这是一个 Kubernetes 的权限提升漏 洞，允许攻击者在拥有集群内低权限的情况下提升至 Kubernetes API Server 权限；通过构造一个对 Kubernetes API Server 的特殊请求，攻击者能够借助其作为代理，建立一个到后端服务器的连接，攻击者就能以 Kubernetes API Server 的身份向后端服务器发送任意请求，实现权限提升。

3．Kubernetes 拒绝服务 传统虚拟化技术设定明确的 CPU、内存和磁盘资源使用阈值，而容器在默认状态下并未对容器内进程的资源使用阈 值做限制，以 Pod 为单位的容器编排管理工具也是如此。资源使用限制的缺失使得云原生环境面临资源耗尽的攻击 风险，攻击者可以通过在容器内运行恶意程序，或对容器服务发起拒绝服务攻击占用大量宿主机资源，从而影响宿主 机和宿主机上其他容器的正常运行。

4．Kubernetes 中间人攻击 默认情况下，Kubernetes 集群中所有 pod 组成了一个小型的局域网络，那么就可能发生像中间人攻击这样针对局域 网的攻击行为。假如攻击者借助 Web 渗透等方式攻破了某个 Pod，就有可能针对集群内的其他 Pod 发起中间人攻击， 进而进行 DNS 劫持等。攻击者能够潜伏在集群中，不断对其他 Pod 的网络流量进行窃听，甚至可以悄无声息地劫持、 篡改集群其他 Pod 的网络通信，危害极大。

三、云原生应用的威胁风险

云原生化应用主要包括微服务、Serverless；同时云原生基础设施和云原生应用也会在原有云计算场景下显著扩大 API 的应用规模，新的安全风险也不容忽视。

1．微服务的威胁风险 首先，随着微服务的增多，暴露的端口数量也急剧增加，进而扩大了攻击面，且微服务间的网络流量多为东西向流量， 网络安全防护维度发生了改变；其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互 认证授权机制更为复杂，人为因素导致认证授权配置错误成为了一大未知风险。并且微服务通信依赖于 API，随着业务规模的增大，微服务 API 数量激增，恶意的 API 操作可能会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒 绝服务等风险；最后，微服务治理框架采用了大量开源组件，会引入框架自身的漏洞以及开源治理的风险。

微服务入口点增加导致攻击面增大。单体应用的场景下，入口点只有一个，所有的请求都会从这个入口点进来。在这 个入口点建立一组 Filter 或者 Interceptor，就可以控制所有的风险。微服务场景下，业务逻辑并不在一个单一的进程 里，而是分散在很多进程里。每一个进程都有自己的入口点，导致需要防范的攻击面比原来更大，风险也会更高。 微服务调度复杂增加访问控制难度带来越权风险。在单体应用架构下，应用作为一个整体对用户进行授权；而在微服 务场景下，所有服务均需对各自的访问进行授权，明确当前用户的访问控制权限。传统的单体应用访问来源相对单 一，基本为浏览器，而微服务的访问来源还包括内部的其它微服务。因此，微服务授权除了服务对用户的授权，还增 加了服务对服务的授权。默认情况下，容器网络间以白名单模式出现，如果不对 Pod 间访问进行显式授权，一旦某 一 Pod 失陷，将极速扩展至整个集群的 Pod。

微服务治理框架漏洞引入应用风险。常用的微服务治理框架，例如 Spring Cloud、Dubbo 等都是基于社区的模式运 作，虽然内置了许多安全机制，但默认值通常并不安全，常常引入不可预料的漏洞，例如用户鉴权混乱、请求来源校 验不到位等。这些漏洞将会导致微服务业务层面的攻击变得更加容易，为微服务的开发和使用者带来安全隐患。比如 Spring Cloud config 存在 CVE-2019-3799、CVE-2020-5405 漏洞，有的社区对这些漏洞进行了及时修复，需要软件及 时更新到新版本；但也有的漏洞长期缺乏修复，需要微服务开发厂商自行修复，这类漏洞通常修复比较复杂、修复成 本较高。

2．API 的威胁风险 云原生带来 API 爆发式增长增加滥用风险。云原生化之后，从基础架构层、到上面的微服务业务层都会有很多标准或 非标准的 API。因为 API 既充当外部与应用的访问入口，也充当应用内部服务间的访问入口，所以数量急剧增加、调 用异常频繁。爆发式的增长导致 API 在身份认证、访问控制、通信加密、以及攻击防御等方面的问题更加明显，面临 更多潜在的风险。与此同时，企业面对大量的 API 设计需求，其相应的 API 安全方案往往不够成熟。