K8s 禁用 ServiceAccount 自动挂载 token 后，老服务调用 K8s API 全挂，如何平滑迁移到最小权限？

【背景】 我在给一套 K8s（1.28.9，containerd 1.7.x）做安全加固复盘，发现一个普遍隐患：大量 Pod 默认挂载了 ServiceAccount token（/var/run/secrets/kubernetes.io/serviceaccount），且绑定的 Role/ClusterRole 是 cluster-admin 或过宽的 RBAC。一旦任一容器被 RCE，攻击者直接拿到 token 就能横向。

【现象】 我尝试用 Pod 级 automountServiceAccountToken: false + 集群级关闭自动挂载来做收敛，结果：

• 一批 2020 年前后写的老服务直接 500/403，日志报 open /var/run/secrets/.../token: no such file or directory、Unable to connect to the server: x509: certificate signed by unknown authority；
• 用 kubectl get pods 确认这些 Pod 的 SA 其实是 default，但代码里写死了 in-cluster config（kube client 自动读 SA 文件），关掉挂载后 client 初始化就失败；
• 更麻烦的是个别服务在 Pod 里读了 token 调 API 的同时，又用了 ServiceAccount 名字硬编码到业务逻辑里，改挂载点会牵一发动全身。

【已尝试的排查与结果】

1. 逐个 Pod 开 automountServiceAccountToken: false —— 能确认哪些服务真的依赖 K8s API，哪些只是"挂了就没事"；
2. 想给真正依赖的服务换"专用 SA + 最小 Role"，但不知道如何枚举每个服务到底调了哪些 API（list pods？watch events？read secrets？）；
3. 试过 audit log 抓 verb/resource 统计，但老服务调用零散、还跨 namespace，统计口径拿不准。

【期望得到的答案形态】 请给一份可复现的迁移路径：

• 如何系统化枚举每个服务实际调用的 K8s API 资源与动词（audit log / kubectl-where / 自定义 admission 探针等），别只靠猜；
• 为"确实需要调 API"的服务设计最小 RBAC 的具体做法（专用 SA + namespace-scoped Role 示例 YAML），以及 token 传递方式（Projected Volume / TokenRequest API）的取舍；
• 对"老服务写死 in-cluster config"的，有没有不改业务代码的平滑过渡方案（sidecar 代理 / 环境变量注入短期 token / 网关代理）；
• 最终如何在 Kyverno/OPA 策略里固化"禁止 cluster-admin 绑定、禁止默认 SA 自动挂载"，避免回退。 最好带具体 YAML、audit 查询片段和验证命令。