创建yaml-bomb.yaml文件：
apiVersion: v1
data:
a: &a ["web","web","web","web","web","web","web","web","web"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
name: yaml-bomb
namespace: default
通过cmdkubectl apply -f yaml-bomb.yaml将ConfigMap创建请求发送到Kubernetes API。
kube-apiCPU/内存使用率非常高，甚至稍后会重新启动。
我们如何防止这种山药炸弹？
这是十亿次笑声攻击，只能在 YAML 处理器中修复。
请注意，维基百科在这里说错了
对于任何可以包含引用的文件格式，都应该存在"十亿笑"攻击，例如这个 YAML 炸弹：
问题不在于文件格式包含引用;而是处理器扩展了它们。这违背了 YAML 规范的精神，该规范说锚点用于实际从多个位置引用的节点。在加载的数据中，锚点和别名应该成为对同一对象的多个引用，而不是将别名扩展到锚定节点的副本。
例如，当您粘贴代码片段时，比较在线 PyYAML 解析器和在线 NimYAML 解析器的行为(完全披露：我的工作(。由于扩展别名的内存负载，PyYAML 不会响应，而 NimYAML 不会扩展别名，因此响应速度很快。
令人惊讶的是，Kubernetes 遇到了这个问题;我会假设因为它是用 Go 编写的，他们能够正确处理引用。您必须向他们提交错误才能解决此问题。
我能想到一些可能的缓解措施，尽管正如@flyx所说，这里真正的修复将在 Kubernetes 使用的 YAML 解析库中。
有趣的是，在我的本地机器上的 Kubernetes 集群上运行它显示 CPU 峰值是客户端(它是 kubectl 进程搅动 CPU(而不是服务器端。
如果问题出在服务器端，那么可能的缓解措施是使用 RBAC 来最大程度地减少对 ConfigMap 创建的访问，并可能使用 OPA 等准入控制器在将清单应用于群集之前对其进行审查。
这可能应该向 Kubernetes 安全漏洞响应团队提出，以便实施适当的修复。
编辑- 我认为问题出现的地方可能归结为使用的群集版本。 服务器端应用分级到 1.16 中的测试版(默认情况下应启用(。 因此，在 1.16 集群上，也许这会攻击服务器端而不是客户端。
编辑- 只需设置一个 1.16 集群，仍然在 kubectl 中将 CPU 使用率显示为客户端...
编辑- 我在这里为此提出了一个问题，还确认可以通过使用curl而不是kubectl来实现 DoS
最终编辑- 这被分配了一个CVE(CVE-2019-11253(，并在Kubernetes 1.13+中修复。该修复程序也已应用于此处的底层 YAML 解析库，因此只要任何其他 Go 程序使用的是最新版本，它们就应该没问题。
有一篇 TrustCom19 论文研究了不同语言的 YAML 解析器中的漏洞，它发现大多数解析器都存在一些问题，所以这很常见，并且该领域最近有几个 CVE(详细信息见论文：Laughter in the Wild： A Study into DoS Vulnerability in YAML Libraries， TrustCom19. 预印本：https://www.researchgate.net/publication/333505459_Laughter_in_the_Wild_A_Study_into_DoS_Vulnerabilities_in_YAML_Libraries