【云攻防系列】云原生中DOS攻击研究

深信服千里目安全实验室 · 公众号 · · 2022-03-26 18:00

正文

序言

云原生（cloud-native）伴随着云计算发展的浪潮应运而生，它充分发挥了云计算平台的弹性以及分布式架构优势。

云原生计算基金会（CNCF）对云原生给出的解释是：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。”

而新技术的产生也必然半生了新的安全问题，云原生出现后，云原生安全随之而来。云原生安全不仅仅要应对传统安全问题，更面临着全新的挑战：镜像安全、容器运行时安全、容器编排工具的安全、API安全等等…...

从目前的云原生环境来看，云原生安全问题层出不穷，威胁程度逐渐上升，从业人员面临着严峻的挑战。云攻防系列文章将围绕着云原生的各类安全问题，以攻防两个视角，着重对容器运行时安全（容器逃逸、容器内拒绝服务攻击等）进行持续探究。

研究背景

操作系统级虚拟化利用共享内核这一特性来实现高效率，并在共享内核上运行多个用户空间实例（又称容器），即在同一内核上运行多个独立的用户空间环境。与硬件虚拟化（即虚拟机）相比，操作系统级虚拟化消除了为每个用户空间实例维护操作系统内核的负担，具有更快的启动速度和更好的资源利用效率。因此，操作系统级虚拟化近年来被广泛采用，并已成为云计算的基础技术。

尽管操作系统级虚拟化效率很高，但它也带来了多种安全问题。首先，共享内核导致操作系统级虚拟化容易受到内核漏洞的攻击。因此，它无法隔离内核 bug。一旦共享内核遭到破坏，所有用户空间实例（称为容器）都将失去隔离和保护。究其原因，是操作系统级虚拟化中的共享内核设计导致容器之间存在一些共享资源（直接或间接共享），例如宿主机上的内存资源、数千个内核变量和数据结构等等。

从共享资源的角度出发，不难联想到卷（ volume ）。同样是共享资源，只是对象变为了容器与宿主机。

攻击思路


       Docker

的


        volume

可以任意创建，并限定参数，确保宿主机的存储资源不会被


        volume

过度使用。但是，作为容器编排工具的


        kubernetes

，在不使用PV的情况下，自身却并没有方法来限制 volume 的参数。

使用 volume 映射宿主机目录后，容器声明文件中对容器的存储限制是否还会起作用呢？

答案是否定的。容器内的存储映射到的是宿主机的一个特定目录，随着容器生命周期而存在、销毁。而卷则是把宿主机的一个目录映射到容器内，这个目录脱离了容器的生命周期，从而达到持久化存储的目的。声明文件中的存储限制，仅仅是约束了容器向宿主机的映射目录，而不会影响卷。换而言之，容器向卷里的存储行为，并不会被容器的声明文件参数所限制。