GKE集群已废弃API排查：定位PodSecurityPolicy v1beta1调用来源

针对你遇到的/apis/policy/v1beta1/podsecuritypolicies API调用（用户代理为python-requests/2.31.0），可以通过以下步骤精准定位来源：

• 利用GKE审计日志精准筛选
  GKE的审计日志会完整记录所有API请求，之前可能未设置正确的筛选条件。在日志探索器中使用以下查询语句：

  resource.type="k8s_cluster" AND protoPayload.methodName="GET" AND protoPayload.request.resourcePath:"/apis/policy/v1beta1/podsecuritypolicies" AND protoPayload.userAgent="python-requests/2.31.0"
  

  查看返回日志中的protoPayload.sourceIp（请求来源IP）、protoPayload.authInfo.principalEmail（调用身份，通常是服务账号邮箱），这两个字段能直接缩小排查范围。

• 关联服务账号到具体Pod
  如果审计日志中找到对应的服务账号，执行以下命令搜索集群内所有使用该SA的Pod：

  kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.spec.serviceAccountName}{"\n"}{end}' | grep <目标服务账号名>
  

  找到Pod后，检查其镜像内容（比如进入Pod执行pip list确认requests版本）或日志，验证是否存在调用旧PSP API的逻辑。

• 排查节点上的本地进程
  部分调用可能来自节点本身的脚本或第三方代理，而非集群内的Pod。登录目标节点：

  gcloud compute ssh <节点名称> --zone <节点所在可用区>
  

  搜索节点上的Python进程：

  ps aux | grep python
  

  查看进程的命令行参数和工作目录，检查是否有调用K8s API的脚本；也可以查看节点的系统日志（/var/log/syslog或/var/log/messages），寻找相关请求痕迹。

• 检查CRD与自定义Operator
  自定义资源定义（CRD）对应的Operator可能会调用旧API。列出所有CRD：

  kubectl get crds
  

  针对每个CRD，找到其对应的控制器Pod（通常在同一命名空间，名称包含operator或controller），查看Pod日志或镜像内的代码，确认是否使用了policy/v1beta1版本的PSP API。

• 排查外部集成工具
  若审计日志显示来源IP是集群外地址，检查你的CI/CD工具（如Jenkins、GitLab Runner）、监控工具（如自定义Exporter）、安全扫描工具等，这些工具可能通过kubeconfig直接访问GKE API，需检查其配置或代码中是否存在旧API调用。

• API Server抓包分析
  若以上方法均无效，可在API Server节点上抓包过滤6443端口的流量：

  tcpdump -i any port 6443 -A | grep "policy/v1beta1/podsecuritypolicies"
  

  抓包结果会包含请求的来源IP、用户代理等信息，进一步定位发起请求的实体。

内容的提问来源于stack exchange，提问作者Satish G