AWS VDP | 报告 #3328291 - 已完成的Pod存在导致Kubernetes网络策略被绕过

报告时间：2025年9月5日，UTC时间上午11:23 报告者：savannabungee 报告对象：AWS VDP

描述

当配置为管理网络策略规则时，Amazon VPC CNI控制器会错误地继续应用针对已完成（Completed）Pod的防火墙规则，就好像这些Pod仍在运行一样。这导致这些规则会被应用到其他不相关的Pod上，只要这些Pod恰好分配到了与已终止Pod相同的IP地址。

例如，假设有一个Pod A，其IP地址为X。Pod A通过NetworkPolicy被允许进行某些访问，VPC CNI控制器通过为节点上的IP地址X添加防火墙规则来实现这一点。当Pod A完成任务（例如它是一个Job）后，这些防火墙规则不会被移除。由于Pod已终止，其他Pod可以自由地获取相同的IP地址。如果未被NetworkPolicy授予任何访问权限的Pod B被分配了相同的IP地址X，那么Pod B将继承Pod A所具有的网络访问权限，直到已完成的Pod A被删除为止。

正确的行为应该是检查Pod的完成状态，并将Pod完成视为与Pod删除相同，在Pod完成时移除防火墙规则。

受影响版本

我在EKS版本1.33上测试了此问题：

在启用了网络策略控制器的“auto”模式下
在非“auto”模式下，使用VPC CNI附加组件 v1.19.5-eksbuild.1
在非“auto”模式下，使用VPC CNI附加组件 v1.20.1-eksbuild.3

“Strict”模式没有任何影响。

概念验证（PoC）

在一个启用了“auto”模式或设置了 enableNetworkPolicy=true 的VPC CNI控制器的EKS集群上，应用以下准备性的Kubernetes资源：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


---
apiVersion: v1
kind: Namespace
metadata:
  name: networkpolicy-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: networkpolicy-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami:latest
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: whoami
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress
  namespace: networkpolicy-test
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          test: allowed
    ports:
    - protocol: TCP
      port: 80

此网络策略配置将允许以下Job连接到Deployment：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


---
apiVersion: batch/v1
kind: Job
metadata:
  name: allowed
  namespace: networkpolicy-test
spec:
  template:
    metadata:
      name: curl
      labels:
        test: allowed
    spec:
      containers:
        - name: curl
          image: "alpine/curl:latest"
          command: ["curl", "-v", "whoami.networkpolicy-test.svc.cluster.local:80"]
      restartPolicy: Never

但以下Job将被阻止并超时：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


---
apiVersion: batch/v1
kind: Job
metadata:
  name: blocked
  namespace: networkpolicy-test
spec:
  template:
    metadata:
      name: curl
      labels:
        test: blocked
    spec:
      containers:
        - name: curl
          image: "alpine/curl:latest"
          command: ["curl", "-v", "whoami.networkpolicy-test.svc.cluster.local:80"]
      restartPolicy: Never

然而，如果存在一个处于“Completed”状态的允许的Job，被阻止的Pod就有机会获得与已完成的允许Pod相同的IP地址。当这种情况发生时，被阻止的Pod将违反NetworkPolicy，能够访问Deployment。

为了便于复现，我建议应用随附的█████████文件来创建20个允许的Job。等待所有20个Job完成，然后应用随附的██████████来创建20个被阻止的Job。几乎可以肯定，一些被阻止的Pod将被赋予与已完成的允许Pod匹配的IP地址，因此将能够成功连接到Deployment并成功退出。一些被阻止的Pod将被赋予不同的IP地址，因此将正确地无法连接到Deployment，挂起然后报错。

影响

摘要：在依赖Kubernetes NetworkPolicy规则来限制网络访问的EKS集群上，存在已被允许某些访问的“Completed”Pod将导致其他Pod被授予相同的访问权限。

时间线与互动记录

2025年9月5日，UTC时间上午11:27：savannabungee 更新了漏洞信息。

2025年9月5日（大约）：h1_analyst_lucas (HackerOne triage) 将状态更改为 “需要更多信息”。

互动内容摘要： HackerOne分析员要求提供更详细的信息以进行验证和分类，包括：

用于测试此问题的初始设置的详细分步说明。

完整的复现步骤，假设读者对此特定问题没有先验知识。

关于如何验证问题存在（而不对系统造成任何损害）的明确指导。

关于安全影响的更具体细节：机密性、完整性和可用性。

大约11天前：savannabungee 将状态更改为 “新建”，并提供了详细的分步说明。

详细的设置和复现步骤摘要：

创建启用了“auto”模式的EKS集群。

配置 kubectl 以连接集群。

启用网络策略管理：应用YAML文件并打补丁，可能需要排空现有节点。

设置测试环境：应用 setup.yaml 创建测试命名空间和资源（Deployment, Service, NetworkPolicy）。

验证网络策略正常工作：应用一个“被阻止”的Job，确认其因网络策略而失败（状态为Error），然后清理。

创建允许的Job：应用一个文件创建多个允许的Job，它们都应成功完成（状态为Completed）。

创建被阻止的Job：应用另一个文件创建多个被阻止的Job。

验证漏洞：检查被阻止Pod的状态。如果其中一些显示为“Completed”（成功），而另一些显示为“Error”或“Running”（失败），则漏洞得到确认。进一步可以通过检查IP地址来验证：成功完成的被阻止Pod的IP地址必然与某个已完成的允许Pod的IP地址相同。

影响补充说明：

机密性：依赖网络控制来保护数据的EKS服务可能面临数据暴露。
完整性：依赖NetworkPolicy规则防止未授权访问端点的服务可能被访问。
可用性：基本不适用。

2025年9月7日，UTC时间上午6:58：h1_analyst_lucas (HackerOne triage) 将严重性从 中危 (4.4) 更新为 中危 (4.3)。

备注：基于PoC中提供的证据，分析员认为严重性反映了以下影响：同一Kubernetes集群上的Pod能够访问NetworkPolicy规则本应阻止它们访问的网络端点，实质上造成了防火墙绕过。因此适用中危严重性。请注意，在团队基于补偿控制和上下文做出最终评估后，此评级可能更改。

大约11天前：h1_analyst_lucas (HackerOne triage) 将状态更改为 “等待项目方审查”。

备注：HackerOne通知报告者，他们已能够验证报告，并将其提交给相应的修复团队进行审查。状态和严重性可能会发生变化。

大约11天前：gabagh00l418 (AWS VDP staff) 发表了评论。

备注：AWS VDP团队确认收到了报告，正在审查中，并将每月提供更新。

大约11天前：gabagh00l418 (AWS VDP staff) 将状态更改为 “已分类”。

备注：AWS VDP团队确认已成功验证报告，并正在制定相应的修复方案。同时询问报告者是否计划在任何期刊或其他平台发布其发现，并表示愿意合作。

2025年9月22日，UTC时间下午1:18：savannabungee 发表了评论。

评论内容：感谢。希望AWS在认为适当时将报告公开。报告者注意到代码库中问题已修复，希望了解修复程序何时部署以及用户是否需要采取任何措施。

大约11天前：gabagh00l418 (AWS VDP staff) 发表了评论。

评论内容：AWS通知报告者，修复程序已部署到所有EKS区域，客户无需采取任何操作即可应用修复。在披露之前，他们将完成标准准备流程，并会在报告公开时通知报告者。

大约11天前：gabagh00l418 (AWS VDP staff) 关闭了报告并将状态更改为 “已解决”。

评论内容：AWS感谢报告者的耐心等待，表示已完成剩余流程，将继续解决此案例并努力使此报告公开可用。

11天前：gabagh00l418 (AWS VDP staff) 请求披露此报告。

11天前：gabagh00l418 (AWS VDP staff) 披露了此报告。

报告摘要

报告ID: #3328291
状态: 已解决
严重性: 中危 (4.3)
披露时间: 2025年11月19日，UTC时间下午11:05
弱点类型: 不当的访问控制 - 通用
CVE ID: 无
赏金: 无