浅谈云原生安全，从零基础到精通，收藏这篇就够了！

程序员霸哥

于 2025-04-16 22:03:48 发布

阅读量482

点赞数 11

分类专栏：程序员编程网络安全文章标签：云原生安全 web安全网络大数据 python java

本文链接：https://blog.csdn.net/logic1001/article/details/147287739

版权

程序员同时被 3 个专栏收录

2536 篇文章

订阅专栏

网络安全

2318 篇文章

订阅专栏

编程

724 篇文章

订阅专栏

引言

1.云原生概念简述

云原生是一种应用架构的理念，它强调将应用程序设计、开发、部署和管理与云计算环境密切结合。云原生不仅仅是简单地将应用迁移到云上，而是借助云计算的优势重新构思和设计应用，使其适应动态、弹性和分布式的云环境。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API，这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。

2.云原生安全的重要性

新兴IT技术的发展，往往绕不开安全性话题。新技术可以给我们带来更多便捷和生产力，但新技术一定是伴随着新的安全风险一起出现，系统的稳定运行、数据的全生命周期安全保障仍需要我们努力保护，不容有失。云原生安全除了包含传统网络安全，还具有其自己的特性，这也是我们研究云原生安全的重点和挑战。

3.文章目的与结构概述

本文旨在通过对云原生安全的解释和分析，为我司自建容器云平台系统的安全能力赋能和加固提供理论基础和安全建议。本文从云原生安全基础、云原生安全关键领域及风险和云原生安全防护体系三方面来展开对云原生安全的分析。

云原生安全基础

1.云原生安全定义与核心要素

云原生安全是指云平台安全原生化和云安全产品原生化。它作为一种新兴的安全理念，旨在解决云计算普及带来的安全问题，并强调以原生的思维构建云上安全建设、部署与应用，推动安全与云计算深度融合。

云原生安全不仅关注云计算环境本身的安全，更强调从应用、服务到基础设施的全生命周期安全防护。它通过将安全防护措施集成到云原生应用和基础设施中，实现从开发到部署、运行的全过程保护。

2.云原生架构与安全挑战

云原生技术架构充分利用了云计算弹性、敏捷、资源池和服务化特性，在改变云端应用的设计、开发、部署和运行模式的同时，也带来了新的安全要求和挑战。以容器、 Serverless 为载体的云原生应用实例极大地缩短了应用生命周期；微服务化拆分带来应用间交互式端口的指数级增长以及组件间组合设计复杂度的陡升；多服务实例共享操作系统带来了单个漏洞的集群化扩散；独立的研发运营流程增加了软件全生命周期各个环节的潜在风险。

新的安全挑战主要包括：

1）容器化部署成为云原生安全计算环境风险输入源

2）微服务细粒度切分增加云原生规模化应用风险

3）Serverless的高灵活性带来模型和平台管控风险

4）DevOps提升了研运流程和安全管理的防范难度

5）API爆发式增长催化分离管控和权限滥用风险

3.传统安全难以应对云原生安全风险

谈及云原生安全不少人还停留在传统安全意识和观念，关注Web攻防和系统攻防，关注密码暴力破解和反弹Shell。然而安全总是具有“短板效应”，有时一个简单的端口暴露、未授权访问没及时处理就为攻击者提供了不费吹灰之力长驱直入的机会。此外云原生技术架构带来的风险在未来数年内会成为攻击者关注和利用的重点，进而发动针对云原生系统。安全防护模型的转变要求在应用程序生命周期中采用更高的自动化程度，并通过架构设计来确保安全方案实施落地；在云原生系统建设初期，需要进行安全左移设计，将安全投资更多地放到开发安全，包括安全编码、供应链（软件库、开源软件等）安全、镜像及镜像仓库安全等。

云原生安全关键领域及风险

容器化部署是云原生的核心技术，也是新型安全风险的主要输入源。容器化带来的主要云原生安全关键在于以下几方面：

1.容器安全

（1）容器运行时安全

容器运行时指的是容器运行的整个生命周期，包括但不限于镜像启动成为容器实例、容器运行、容器停止。在这些阶段主要涉及以下安全问题：

①容器逃逸：
首先攻击者通过劫持容器化业务逻辑或直接控制（CaaS等合法获得容器控制权的场景）等方式，已经获得了容器内特殊权限下的命令执行能力；攻击者利用这种命令执行能力，进一步获得该容器所在的直接宿主机上特殊权限下的命令执行能力。直接宿主机可以是虚拟机也可以是实体机，在这里不在展开讲解虚拟机逃逸。

容器逃逸的主要利用的脆弱点包括：危险配置、危险挂载、相关程序漏洞、宿主机内核漏洞等。

②资源耗尽型攻击：
同为虚拟化技术容器与虚拟机既存在相似之处也有显著不同。在资源限制方面，无论使用VMware、VirtualBox还是QEMU，我们都需要为即将创建的虚拟机设定明确的CPU、内存及硬盘资源阈值，在虚拟机内部的进程看来，它处于一台被设定好的独立计算机之中。但是容器运行时默认情况下并未对容器内进程在资源使用上做任何限制，以Pod为基本单位的容器编排管理系统在默认情况下同样未对用户创建的Pod做任何CPU、内存使用限制。缺乏限制使得云原生环境面临资源耗尽型攻击的风险。攻击者可能通过在一个容器内发起拒绝服务来占用大量宿主机资源，从而影响到宿主机自身或宿主机上其他容器的正常运行。以上所说的是默认配置下的资源限制缺失，从而导致容器的隔离性在一定程度上失效（影响到容器外系统或服务的正常运行），而非针对某容器本身的拒绝服务攻击。

（2）容器网络安全

容器网络安全主要是由于容器网络访问控制的细粒度更细，增加了分离管控难度，且业务间依赖关系复杂难以梳理最小化最优化的访问控制规则，导致容器网络更容易存在风险。

如果容器网络层不能依据业务关系实现细粒度的访问控制策略，就会带来网络权限放大的风险，例如：无需被外网访问的业务被默认设置了外网访问权限，容器网络可无限制访问宿主节点的下层网络等。攻击者将利用这些漏洞获取权限外甚至核心系统的访问控制权限，最终实现越权甚至提权攻击。

除此之外访问控制管控规则设置不合理还会增加横向攻击的风险。服务之间的数据流动极其频繁，在云原生环境下多个服务实例共享操作系统，一个存在漏洞服务被攻陷将会导致运行在同一主机上的其他服务受到影响。如果各服务单元对应的容器组之间、容器网络与物理网络之间没有做好网络权限的分离管控，外网攻击者就能从高风险实例逃逸，伴随东西向流量在集群网络内部的实例之间进行横向攻击，导致威胁在集群内大范围扩散。另外有些云原生平台采用underlay模式的网络插件，使得容器IP与节点IP共享同一网络平面，在业务IP暴露给最终用户的同时，管理控制台会面临被入侵的风险。

2.编排系统安全

（1）编排工具自身漏洞导致的非法提权和逃逸攻击。

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

②逃逸攻击：指攻击者通过劫持容器内某种权限下的命令执行能力，借助一些手段进一步获得该容器所在宿主机上某种权限下的命令执行能力。以CVE-2017-1002101漏洞为例，这是一个Kubernetes的文件系统逃逸漏洞，允许攻击者使用subPath卷挂载来访问卷空间外的文件或目录。

（2）编排组件不安全配置引起账户管理问题导致系统入侵。

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

（3）编排节点访问策略配置不当导致未授权主机非法访问。

维护编排环境中各节点之间的信任关系时需要充分考虑依赖和调用关系，编排工具访问策略配置不当可能让编排工具和其上运行的容器技术组件面临极大风险，例如主机之间通信未加密或未认证，导致未经授权的主机加入集群并运行容器；用于认证的密钥在所有节点中共享编排工具，导致集群中单个主机被入侵后扩散至整个集群被入侵等。

3.镜像及镜像仓库安全

（1）镜像更新不及时导致存在漏洞

在传统模式中，操作系统和软件在其运行的主机上可以通过线上或离线方式进行更新。但容器则必须在上游的镜像中进行更新然后重新部署。因此容器化环境的常见风险之一就是用于创建容器的镜像版本存在漏洞未及时修复，从而导致所部署的容器存在漏洞。

（2）镜像来源不可信注入毒镜像

镜像及容器技术一个主要的特点就是方便移植和部署，云原生用户可以将符合OCI标准的第三方镜像轻松部署到自己的生产环境中。因此攻击者可将含有恶意程序的镜像上传至公共镜像库，诱导用户下载并在生产环境中部署运行，从而实现其攻击目的。

（3）镜像仓库中间人攻击

保证容器镜像从镜像仓库到运行启动时的完整性是镜像仓库面临的一个重要安全问题。如果用户以明文形式拉取镜像，在与镜像仓库交互的过程中极易遭遇中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像，从而造成镜像仓库和用户双方的安全风险。

4.云原生应用安全

云原生应用安全的新风险主要是由于计算模式变革带来的。企业在应用微服务化后会进一步聚焦于业务自身并将功能函数化，因而出现了无服务器计算这类新的云计算模式，并引入了Serverless应用和Serverless平台的新风险。Serverless是云原生架构下，针对应用程序构建和部署运行的模型，其目标是使开发人员专注于应用程序的构建和部署运行，而无需管理服务器等资源。

Serverless模型包含了开发者开发、部署、运行的应用程序，以及云计算供应商提供的Serverless支撑平台。对应Serverless的安全风险，一方面包含应用本身固有的安全风险，另一方面包含Serverless模型以及平台的安全风险。

Serverless模型以及平台的安全风险，主要包括以下几类：

（1）函数多源输入导致供应链安全风险。

Serverless模式下函数调用由事件源触发，这种输入来源的不确定性增加了安全风险。如果函数未对外界输入数据进行有效的过滤或安全校验，就可能存在SQL注入、系统命令执行等类型的攻击风险。

（2）资源权限管控不当带来函数使用风险。

Serverless应用通常会由诸多函数组成，函数间的访问权限、函数与资源的权限映射会非常多，如何高效地进行角色和权限的管控是一个复杂的问题。许多开发者可能暴力地为所有函数配置单一的角色和权限，这一行为将极大地增加函数使用风险。

（3）设计使用不规范引入数据泄露风险。

一是数据源增加导致数据攻击面增加。传统应用只是从单一服务器上获取敏感数据，而Serverless架构中攻击者可针对各种数据源进行攻击，攻击面更广。二是环境变量替代配置文件引入泄露风险。Serverless应用由众多函数组成，无法像传统应用程序使用单个集中式配置文件存储的方式，因此开发人员多使用环境变量替代，虽然存储更为简单，但使用环境变量本就是一个不安全的行为，一旦攻击者进入运行环境，可以轻易获取环境变量信息，引起信息泄露。三是跨函数调用数据清理不及时引入数据泄露风险。Serverless函数基于触发机制实现函数调用与运行，在无状态函数的运行过程中，倘若函数调用结束后没有及时清除暂存的配置参数、账号信息或其他业务敏感信息，后续使用基础设施资源的函数可能会访问这些数据，存在机密数据泄露的风险。

（4）FaaS平台自身漏洞带来入侵风险。

私有云FaaS平台由于其自身代码含有漏洞进而导致函数遭受攻击的案例越来越多，这些攻击行为主要以攻击者利用平台漏洞进行挖矿、数据窃取为主。

（5）缺乏Serverless专有安全解决方案导致风险应对能力不足。

广泛使用的安全检测体系如WAF、IPS/IDS、DAST、SAST、日志审计工具等，均是基于云场景中虚机或容器底座、基于Web应用或传统应用架构进行设计、开发和应用的；而Serverless无论机制、架构还是应用场景均存在一定的特殊性，现阶段成熟有效的安全检测工具与机制无法直接匹配或移植，使得Serverless服务的使用者和运营者难以有效应对网络中层出不穷的新攻击方法与手段，在方法机制与工具支撑方面存在较大的差距与风险。

云原生安全防护体系和思路

1.安全左移

安全左移主要需考虑开发安全、软件供应链安全、镜像及镜像仓库。

（1）开发安全：自有代码产生脆弱性的主要原因是开发者缺乏安全经验和意识，在编写代码时没有进行必要的安全检查。为了应对代码产生的漏洞，应该对代码进行安全审计。审计实施人员对系统重要业务场景进行风险分析并审计源代码，通常可使用静态应用安全测试的方式进行审计。

（2）供应链安全：软件供应链存在风险，第三方库的安全性是非可信的，特别是开源软件，通常一个项目会使用大量的开源软件。如今新应用程序70%～90%的代码来自外部或第三方组件，平均每个应用程序有100余个开源组件。其中最让人不安的是企业对其是否使用了开源软件、使用了什么开源软件并不了解。为了应对此类风险，可使用软件成分分析（SCA）技术以发现项目中用到的第三方软件库（特别是开源软件），分析相关代码版本库将其与漏洞库比较，如有匹配则告知存在漏洞。

（3）镜像安全：镜像构建的方式通常有两种，基于容器直接构建或基于Dockerfile构建。建议所有的镜像文件由Dockerfile创建，因为基于Dockerfile构建的镜像是完全透明的，所有的操作指令都是可控和可追溯的。

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

针对以上问题可以从下面几方面来加固镜像构建安全：1）验证镜像来源，向远程镜像仓库发送和接收的数据加入数字签名功能，这些签名允许客户端验证镜像标签的完整性和发布者。2）镜像轻量化，只安装必要的软件包，这不仅在提高容器性能方面有很大帮助，更重要的是减少了攻击面。3）正确使用镜像指令，在构建镜像时要选择恰当的指令。4）敏感信息处理，尽管Docker为用户分配了只读权限，但有时用户仍需要小心容器中存储的数据，建议以加密格式存储，并且在查找时只能由授权的用户解密。

镜像除了在本地进行构建以外，还会通过官方或第三方镜像库直接下载，这两种镜像都需要进行安全检测，这是保证镜像安全的一个重要环节。这里的检测主要还是针对已知的CVE漏洞进行扫描分析。镜像检测的核心目前仍然是已知系统CVE检测，扫描器获取到镜像后，将它分离成相应的层和软件包，然后将这些包与多个CVE数据库包的名称和版本进行对比，从而判定是否存在漏洞。还有一些通过扫描镜像中的环境变量、操作命令及端口开放信息来识别恶意镜像的方案。

（4）镜像仓库安全：镜像仓库主要应关注用户和管理员账号的身份校验、权限控制和数据传输。容器镜像在上传镜像仓库和从镜像仓库下载时必须保证完整性和秘密性，以下建议有助于抵御如中间人攻击等威胁。

1）数字签名，上传者主动给要上传的镜像签名，下载者获取镜像时先验证签名再使用，防止其被恶意篡改。

2）用户访问控制，敏感系统和部署工具（注册中心、编排工具等）应该具备有效限制和监控用户访问权限的机制。

3）尽可能使用支持HTTPS的镜像仓库，为避免引入可疑镜像，用户谨慎使用–insecure-registry选项，以免连接来源不可靠的HTTP镜像仓库。

2.持续监控和响应

随着云原生时代的来临，业务变的越来越开放和复杂，固定的防御边界已不复存在，而攻击者的手段却越来越多样。Gartner自适应安全架构指出，大多数企业在安全保护方面会优先集中在拦截防御、以及基于策略的防御上（例如防火墙），以将危险拦截在外。然而防御体系总是难以应对所有威胁，高级定向攻击总能轻而易举地绕过各种防御手段，安全威胁已防不胜防。

攻击者的攻击行为是不间断的，渗透系统的行为不可能被完全拦截，系统应假设自己时刻处于被动攻击中。为解决传统防御手段的被动处境，需要为系统添加强大的实时监控和响应能力，以帮助企业高效预测风险、精准感知威胁、全面提升响应效率。企业监控应转被动为主动，持续监控尽可能多的云原生环境，如网络活动层、端点层、系统交互层等；同时应建立持续响应的防护机制，对攻击进行迅速分析和处理，并建立数据收集池进行溯源追踪，发现系统中的安全缺陷，逐步提升企业整体的安全防护水平。实现事前快速布局、事中精准响应、事后全面回溯。

总结

本文从云原生安全的定义、原则、核心要素讲到关键领域、风险、防护体系和思路，为大家简单介绍了云原生技术在网络安全方面需要注意的风险和需要落实的工作。希望从事云计算开发和运营的同事可以从本文获取一些有用的信息，让我们一起将容器云平台建设得更加安全、健壮。

参考材料：

声明：本文部分观点和内容摘取自于以下文章和书籍。
1、《云原生架构安全白皮书（2021年）》——云原生产业联盟
2、《云原生安全：攻防实践与体系构建》——刘文懋，江国龙，浦明，阮博男，叶晓虎

作者简介

王建一，北银金科信息安全部，为总行、分行及各投资机构提供网络安全服务，助力北京银行的网络安全体系建设和技术发展。

招聘启事

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传