AWS VDP | 报告 #3328291 - 已终止Pod的存在允许绕过Kubernetes网络策略 | HackerOne
描述
当配置为管理NetworkPolicy规则时，Amazon VPC CNI控制器会错误地将防火墙规则应用于“已完成”（Completed）状态的Pod，就好像这些Pod仍在运行一样。这导致这些规则被应用于其他恰好获得与已终止Pod相同IP地址的不相关Pod。
例如，如果您有一个IP地址为X的Pod A。通过NetworkPolicy允许Pod A进行某些访问，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上测试了此问题：
- 在启用网络策略控制器的自动模式下
- 在非自动模式下，使用VPC CNI插件 v1.19.5-eksbuild.1
- 在非自动模式下，使用VPC CNI插件 v1.20.1-eksbuild.3
严格模式没有任何影响。
概念验证
在启用了自动模式，或VPC CNI控制器将enableNetworkPolicy设置为true的EKS集群上，应用以下预备性Kubernetes资源：
apiVersion:apps/v1kind:Deploymentmetadata:name:whoaminamespace:networkpolicy-testspec:replicas:1selector:matchLabels:app:whoamitemplate:metadata:labels:app:whoamispec:containers:-name:whoamiimage:traefik/whoami:latestports:-containerPort:80apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:ingressnamespace:networkpolicy-testspec:podSelector:{}policyTypes:-Ingressingress:-from:-podSelector:matchLabels:test:allowedports:-protocol:TCPport:80此NetworkPolicy配置将允许以下Job连接到Deployment：
apiVersion:batch/v1kind:Jobmetadata:name:blockednamespace:networkpolicy-testspec:template:metadata:name:curllabels:test:blockedspec:containers:-name:curlimage:"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集群上，存在已完成的、曾被允许某些访问的Pod将导致其他Pod被授予相同的访问权限。
逐步说明
如果没有可用的、配置了VPC CNI控制器来管理NetworkPolicies的现有Kubernetes集群，设置带有VPC CNI控制器的环境的最简单方法是创建一个启用了自动模式的新EKS集群。对于大多数初始设置，标准的AWS指南就足够了，因此我将参考这些指南。
- 创建启用自动模式的EKS集群：https://docs.aws.amazon.com/eks/latest/userguide/create-cluster-auto.html
如果通过AWS控制台操作：
1.1 随意命名集群。
1.2 使用“创建推荐角色”按钮创建集群角色（可以任意命名）。
1.3 在集群设置页面中选择创建的集群角色。
1.4 所有其他设置可以保留为默认值。 - 集群创建完成后，配置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中创建的集群名称> - 启用网络策略管理（参考：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来排空所有现有节点。 - 通过运行
kubectl apply -f setup.yaml来设置测试Kubernetes命名空间和资源。 - 验证Kubernetes NetworkPolicies是否在集群上工作。
5.1 运行kubectl apply -f blocked-job.yaml
5.2 使用kubectl get pod -n networkpolicy-test -l test=blocked检查创建的Pod状态。最初它将显示“运行中”（Running）状态，然后在超时后将显示“错误”（Error）状态。存在状态为“错误”的Pod表明Kubernetes集群上启用了NetworkPolicy管理。存在状态为“已完成”（Completed）的Pod表明集群上未正确配置NetworkPolicy管理（请返回步骤3）。
5.3 通过运行以下命令清理Job：kubectl delete job -n networkpolicy-test blocked - 创建旨在能够连接到whoami部署的Jobs。
6.1 运行kubectl apply -f ████
6.2 所有Jobs都应启动并在没有错误的情况下完成（即显示“已完成”状态），可以使用kubectl get pod -n networkpolicy-test或kubectl get job -n networkpolicy-test进行检查。 - 创建应被NetworkPolicy阻止的Jobs。
7.1 运行kubectl apply -f blocked-job20.yaml
7.2 稍等片刻，让所有Pod启动。 - 验证
8.1 使用kubectl get pod -n networkpolicy-test -l test=blocked检查被阻止Pod的状态。
8.2 所有被阻止的Pod原本都应该被配置的NetworkPolicy阻止。如果一些Pod显示“已完成”（Completed）状态，而另一些显示“错误”（Error）或“运行中”（Running）状态，则漏洞被确认。
8.3 为了进一步确认漏洞，通过运行kubectl get pod -n networkpolicy-test -o wide检查Pod的IP地址。所有IP地址与一个或多个允许Pod的IP地址冲突的被阻止Pod应显示“已完成”状态。任何IP地址与允许Pod的IP地址不匹配的被阻止Pod应显示“错误”或“运行中”状态。
影响
同一Kubernetes集群上的Pod能够访问它们本应被NetworkPolicy规则阻止访问的网络端点（防火墙绕过）。
具体来说，NetworkPolicy规则是随机（基于IP地址分配）错误应用的。一些Pod将被授予它们本不应具有的访问权限。这实际上使EKS中的NetworkPolicy规则失效。
机密性：暴露了哪些具体数据或信息？
依赖网络控制来保护数据的在EKS中运行的服务可能会暴露其数据。完整性：系统完整性如何受到影响？
依赖NetworkPolicy规则防止未经授权访问端点的服务可能被访问。可用性：对服务可用性的潜在影响是什么？
基本不适用。
基于POC中提供的证据，我认为严重性显示了以下影响：
同一Kubernetes集群上的Pod能够访问它们本应被NetworkPolicy规则阻止访问的网络端点，这实际上创建了防火墙绕过。因此，中等严重性是适用的。
请注意，在团队基于补偿控制和上下文做出最终评估后，这可能会发生变化。
biOK/hzhVF2yKaGc5mK8ofWU54x+5CPhFAFI2w3Wf7rJKdanH/f91ggwGTOvI7mc
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
