序言
云原生（cloud-native）伴随着云计算发展的浪潮应运而生，它充分发挥了云计算平台的弹性以及分布式架构优势。
云原生计算基金会（CNCF）对云原生给出的解释是：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。”
而新技术的产生也必然半生了新的安全问题，云原生出现后，云原生安全随之而来。云原生安全不仅仅要应对传统安全问题，更面临着全新的挑战：镜像安全、容器运行时安全、容器编排工具的安全、API安全等等…...
从目前的云原生环境来看，云原生安全问题层出不穷，威胁程度逐渐上升，从业人员面临着严峻的挑战。云攻防系列文章将围绕着云原生的各类安全问题，以攻防两个视角，着重对容器运行时安全（容器逃逸、容器内拒绝服务攻击等）进行持续探究。
研究背景
操作系统级虚拟化利用共享内核这一特性来实现高效率，并在共享内核上运行多个用户空间实例（又称容器），即在同一内核上运行多个独立的用户空间环境。与硬件虚拟化（即虚拟机）相比，操作系统级虚拟化消除了为每个用户空间实例维护操作系统内核的负担，具有更快的启动速度和更好的资源利用效率。因此，操作系统级虚拟化近年来被广泛采用，并已成为云计算的基础技术。
尽管操作系统级虚拟化效率很高，但它也带来了多种安全问题。首先，共享内核导致操作系统级虚拟化容易受到内核漏洞的攻击。因此，它无法隔离内核 bug。一旦共享内核遭到破坏，所有用户空间实例（称为容器）都将失去隔离和保护。究其原因，是操作系统级虚拟化中的共享内核设计导致容器之间存在一些共享资源（直接或间接共享），例如宿主机上的内存资源、数千个内核变量和数据结构等等。
从共享资源的角度出发，不难联想到卷（volume）。同样是共享资源，只是对象变为了容器与宿主机。
攻击思路
Docker 的 volume可以任意创建，并限定参数，确保宿主机的存储资源不会被 volume过度使用。但是，作为容器编排工具的 kubernetes，在不使用PV的情况下，自身却并没有方法来限制 volume 的参数。
基于上述思路，又由于 deployment 默认使用的是 hostpath，本文即在 kubernetes 节点上进行容器使用 hostpath 后的存储测试。
1 正常限制下的容器
上图是 pod 的声明文件，使用了 ephemeral-stroage 方式限制了容器最大存储为 4G。
在根目录下创建一个 5G 大小的文件，直接被终止，说明限制条件在正常的容器下生效。
K8s 主动终止 container
pod 状态：
2 使用 hostpath 方式的容器
上述拒绝服务的危害性，最小可以影响一块磁盘，使用此磁盘进行存储的所有服务都将受到影响，如果主机仅有一块磁盘，那么受影响范围将扩大到整个主机服务。而且这个验证过程均在某几个云平台进行测试，平台即不会对磁盘异常爆满做出警告，也不会主动释放，一旦造成攻击，可能运维人员要等服务停止一段时间之后才能发现，危害较大。
防御方法上也是比较明确的，即使用 PV（Persistent Volume）。PV 提供了更合理，以及功能更强大的卷使用方式，不仅能约束卷的参数，而且能够数据迁移，实现真正的持久化存储。
对于此共享资源方向上的攻击，我们创新研究院云安全团队也将持续探索研究。
深信服科技旗下安全实验室，致力于网络安全攻防技术的研究和积累，深度洞察未知网络安全威胁，解读前沿安全技术。
● 扫码关注我们
原文始发于微信公众号（深信服千里目安全实验室）：【云攻防系列】云原生中DOS攻击研究
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论