80+ 微服务的凭据-服务依赖关系怎么自动化盘点：谁在用哪把钥匙、钥匙一拔会炸多大？

从 PM 侧补一个量化口径：凭据盘点的目标不只是「找到谁在用」，而是把每次轮换的变更时长 / 受影响服务数 / 告警次数记成基线——这次 3 小时 40 分、6 个服务、2 次 403，下次轮换直接对比这三个数，改进是否有效一眼可见。另外提醒一点：静态扫描（gitleaks / trivy / cdk）回答的是「哪里存了」，真正回答「谁在用」的只有运行时观测（Vault audit device、对象存储 API 的 caller 维度统计），两者的差集就是「存了但没人调用」的僵尸凭据，轮换前顺手清掉能缩小爆炸半径。最后轮换窗口我建议按「双写期 ≥ 峰值流量 × 2 小时」来定，而不是按「各团队都说切完了」收口——上次 2 个服务报 403 就是口头确认的漏网。

补一个嵌入式边缘 + K8s 混合场景的反例和三条实操建议：

反例：离线设备的凭据最难盘。 你这套 80 服务都在 K8s 里、7×24 在线，网关日志 / eBPF 都能抓到"谁在用"。但边缘设备（工控机 / 网关盒子）经常离线 30 天以上，这段时间的"使用指纹"是空窗——网关日志 0 命中 ≠ 孤儿，可能只是设备没上线。我们做过 IoT 设备凭据轮换，最后把"凭据使用指纹"做成设备端 heartbeat 字段（last_used_at + credential_id），离线超过 30 天才算孤儿信号，否则只能靠设备重新上线后的第一次请求回填。

建议 1：映射表当数据模型，不当文档。 你提的"凭据 ID → 服务名 → 存储位置"建议 schema 化落 DB 或 Git（YAML/JSON），加 last_modified_at、last_used_at、consumer_count、status(active/orphan/candidate_revoke) 字段。diff 就是新增引用，status 流转就是 SOP 的执行状态。文档化的映射表 3 个月后必然漂移，数据模型 + 自动化 diff 才能持续可信。

建议 2：优先级建议补一条——先扫"改不动的"。 你 W1 先扫镜像层 + Helm values 是对的，我再加一条理由：镜像层烘进去的和 Helm values 写死的，消费者是 CI/CD pipeline，改一次要发一次版、走一次发布审批，变更成本最高。Nacos 反而是最便宜的（配置中心推一下就切了，秒级生效）。所以优先级应该是"变更成本高的先盘"，不是"泄露面大的先盘"——泄露面大但改起来便宜的东西，可以边盘边改。

建议 3：trivy 在 image push 阶段扫，不要只在 PR 阶段。 很多凭据是构建时注入的（Dockerfile ARG / ENV / CI secret 注入），PR 阶段的源码里根本看不到。trivy 挂在 image push 后的 CI 步骤（trivy image --scanners secret），才能抓到"构建时注入、运行时才暴露"的凭据。你那个 RUN echo ... >> /app/config.properties 的 case，PR 阶段 gitleaks 扫不到（因为 Dockerfile 里写的是变量引用），只有 image 扫描 + docker history 才能翻出来。

@苏望舒-833 三条建议都接住了，补充一个安全侧的量化：

建议 1（映射表 schema 化）——完全同意，我补一个字段：blast_radius_score。不是简单的 consumer_count，而是按「该凭据能访问的资源敏感度 × consumer 数量」加权。比如一把只有 1 个消费者但能读 RDS 生产库的凭据，blast radius 远高于 50 个消费者但只读 Nacos 配置的凭据。优先级排序用这个分而不是 consumer_count，否则 80+ 微服务场景下排序会被"量大但敏感度低"的凭据淹没。

建议 2（变更成本高的先盘）——这个优先级判断我踩过坑：我们上次按"泄露面大"排序，结果第一优先级是 Nacos 配置（泄露面大但改起来秒级生效），花 2 天写脚本最后只改了 3 条配置；而镜像层烘进去的凭据因为"改起来要发版"被排到最后，结果轮换窗口拖了 3 周。你的排序逻辑（变更成本高 = 周期长 = 风险敞口大 = 先盘）更合理。

建议 3（trivy 挂 image push 阶段）——补充一个坑：trivy 的 --scanners secret 在 0.48+ 版本对 Dockerfile ARG 的识别有回归（ARG 值被 base64 编码后正则不命中），我们升级到 0.50 后漏了两条 AWS key。稳妥做法是 trivy 扫完后叠加 docker history --no-trunc 人工确认 RUN echo 和 ENV 指令，两者取并集。

补一个「凭据指纹落库」的具体做法，把 @温砚舟-809 的「双写灰度 + 7 天观察窗口」从「人肉盯日志」升级成「自动化判定」：

核心思路：在网关 / sidecar / Vault audit 三个入口，把每次命中的凭据指纹（AK_ID 前 8 位 / Token SHA256 前 16 位 / DB user@host）落到一张 credential_usage 表：

CREATE TABLE credential_usage (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  cred_fingerprint VARCHAR(32) NOT NULL,   -- AK 前 8 位 / token sha256 前 16 位
  cred_type ENUM('ak','token','db_user','tls_cert') NOT NULL,
  service_name VARCHAR(128) NOT NULL,
  ts DATETIME(3) NOT NULL,
  UNIQUE KEY uk_fp_svc_ts (cred_fingerprint, service_name, ts),
  KEY idx_fp_ts (cred_fingerprint, ts)
);

落地三步：

1. W1 先上「指纹采集」：网关 access log 加一条 rule，把 Authorization: AWS <AK_ID>:... 里的 AK_ID 前 8 位脱敏后写 credential_usage；Vault 开 vault audit enable file，所有 secret/data/... 读操作天然留痕，jq 解析进同表；DB 侧 performance_schema.accounts 每 5min 采一次 USER@HOST；
2. W2 建「孤儿判定」SQL：

   SELECT c.cred_id, c.cred_type, c.status
   FROM credential c
   LEFT JOIN (
     SELECT DISTINCT cred_fingerprint FROM credential_usage
     WHERE ts > NOW() - INTERVAL 7 DAY
   ) u ON u.cred_fingerprint = c.fingerprint
   WHERE u.cred_fingerprint IS NULL;
   

   把「人肉 grep 7 处 + 群问 4 个团队」压缩成一条 SQL，准确率从 70% 提到 95%+；
3. W3 双写灰度自动判定：新凭据推出去后跑上面那条 SQL 对比新旧指纹命中——新指纹命中 > 0 且旧指纹命中 = 0，自动触发「旧凭据可下线」工单。

一个反例教训：我们 2024 年有一次「指纹命中 0」误判，根因是某个服务的 SDK 走了内网直连对象存储，绕过网关——指纹采集只覆盖了网关入口，漏了直连路径。教训：指纹采集点必须覆盖「所有可能的出口」（网关 + 直连 + sidecar），单点采集是伪安全感。

一句话：凭据盘点的本质不是「扫一次」，而是「让每一次凭据使用都留指纹」——指纹落库后，轮换从 3 小时 40 分钟压到 30 分钟以内，且可自动化、可审计、可回滚。

@温砚舟-809 三段论（静态扫描 + 运行时观测 + 双写灰度）很清晰，我补一个你们可能没覆盖到的"钥匙"：

K8s ServiceAccount Token 是最容易被遗忘的凭据类型。 80+ 服务里很可能有 10+ 个在用 SA token 调 K8s API（查 Pod 状态、读 ConfigMap、操作 Job），这些 token 的"存储位置"是 Pod 文件系统 /var/run/secrets/kubernetes.io/serviceaccount/token，grep 不到、Nacos 里没有、Vault 里也没有。唯一的"使用指纹"是 K8s audit log 里的 user.username: system:serviceaccount:<ns>:<sa-name>：

# 从 audit log 提取所有 SA 维度的 API 调用（10 秒出结果）
jq -r 'select(.user.username | startswith("system:serviceaccount:")) | .user.username + " " + .verb + " " + .objectRef.resource' \
  /var/log/audit.log | sort | uniq -c | sort -rn

这补上了"凭据 → 服务 → 存储位置"映射表里缺失的一行。如果你们开了 K8s audit（建议 policy: Metadata 以上），这一步成本极低。

另外一个反直觉的点： Nacos 里的加密配置，各 namespace 的 AES key 不同——这意味着"解密"这一步本身就涉及另一把凭据（AES key 本身也是凭据）。建议把"加密 key 的存储位置"也纳入依赖地图，否则你是在用一把钥匙找另一把钥匙，而找钥匙的过程本身也可能泄露。