200 个服务凭据轮换：如何做到"先验证可用、再下线旧凭据"不出事故？

前面几位把「轮换时序、双跑时长、审计留痕」讲得很透了，我从一个容易被忽略的角度补一刀：异步消息链路里的「幽灵凭据」——这是 200 个服务 × 60 个第三方 Key 里最容易翻车、也最容易被「凭据维度日志」漏掉的一类，因为它的「使用者」不是直接持有 Key 的服务，而是下游订阅者。

一、为什么异步链路会让你的「下线判据」失效

你现在的判断逻辑是：「旧 Key 调用量归零 → 可以下线」。这个逻辑对同步调用（HTTP 网关、RPC）成立，因为每次调用都过网关、都有 trace、都能归因到具体服务。

但你的链路里至少有三处会绕过网关：

1. 消息队列的 consumer 端：Kafka / RabbitMQ 的 consumer 用 Key 调第三方（比如把短信网关的 Key 写在 consumer 的业务代码里）。这类调用不经过你的网关，网关侧的「凭据维度日志」根本看不到。
2. 定时任务 / 批处理：每天凌晨跑的对账、报表、数据同步任务，用的可能是和在线服务不同的 Key（历史上为了隔离故障域），这类 Key 在「在线服务凭据盘点」里经常被漏掉。
3. SDK 内置的 fallback：有些第三方 SDK（比如支付、短信）内部会有「备用 Key」机制，主 Key 失效后自动切到备 Key——你以为在轮换主 Key，其实备 Key 一直在用，而且备 Key 的调用量可能比主 Key 还大。

我们去年做凭据治理就踩过第 3 个坑：把某支付网关的主 Key 下线了，业务侧完全无感（P99 没抖、错误率没涨），两周后才发现 SDK 一直在用备 Key 兜底，备 Key 的调用量是主 Key 的 1.4 倍。

二、识别「幽灵使用方」的具体手段（比网关日志更狠）

手段 1：在出口代理层做「凭据指纹」埋点

不管调用走不走网关，只要它要出公网，就会过你们的出口代理（Nginx / Envoy / 自建 L7）。在出口代理上做响应头 + 请求 header 的联合指纹：

# Envoy 配置示例：对第三方 API 的出口做凭据维度审计
http_filters:
- name: envoy.filters.http.router
- name: envoy.filters.http.access_log
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.access_log.v3.AccessLog
    access_log_format:
      text_format: '%REQ(X-API-KEY)% %REQ(X-AUTHORIZATION)% %UPSTREAM_HOST% %RESP(X-RATELIMIT-REMAINING)% %UPSTREAM_CLUSTER% %DURATION%\n'
    log_path: /var/log/envoy/credential-audit.log

关键：不要记完整的 Key（合规风险），记 Key 的 SHA256 前 16 位 + 时间戳 + 上游 host。这样你可以：

• 离线跑一次「Key 指纹 → 调用方 IP」的反查表（从 K8s Pod 的 IP 反查到 service / namespace / owner）
• 在 Key 下线前 7 天，把这个指纹的调用量拉出来，任何非零调用量都说明还有人在用——不管他是走网关还是走直连

手段 2：对消息队列做「consumer 凭据盘点」

这一步很多人会漏。Kafka / RabbitMQ 的 consumer 用 Key 调第三方，这个 Key 不在消息里（消息里只有业务数据），所以消息队列的审计日志看不到。

我们的做法：

• 在 consumer 侧加一个启动时的凭据上报：consumer 启动时把「我用了哪些 Key 的指纹」上报到一个内部 registry（一个简单的 etcd key 就行）
• registry 维护一个 key_fingerprint -> [consumer_pod, topic, group_id] 的映射
• Key 下线前查这个映射，只要映射非空就拒绝下线，让 consumer owner 自己来清理

# consumer 启动时的上报示例（伪代码）
import hashlib, etcd3
client = etcd3.Client(host='etcd.internal')
for key_name in my_third_party_keys:
    fp = hashlib.sha256(key_name.encode()).hexdigest()[:16]
    client.put(f'/credential-registry/{fp}', 
               json.dumps({"pod": os.environ['POD_NAME'], 
                          "topic": my_topic, 
                          "group": my_group_id}))
# 注意：要带 TTL，pod 挂了自动过期，避免僵尸注册

手段 3：对 SDK 内置的 fallback Key 做「影子流量」观测

针对上面第 3 个坑，最简单的办法是主动触发一次 Key 失效：

• 选一个低峰时段（凌晨 3~5 点）
• 把某个 Key 在第三方侧临时设为「只读 / 限流 1 QPS」（不是直接删，避免不可逆）
• 观察 10 分钟：如果业务侧无感但调用量降了 70% → 说明有 fallback 在兜底
• 恢复 Key，把 fallback Key 加入「必须轮换」清单

代价：10 分钟的低峰限流，业务侧 P99 可能抖动 50~200ms（取决于第三方 SLA）。我们做过 60 个 Key 的批量探测，总共花了 3 个晚上，发现 11 个 Key 有隐藏的 fallback，占比 18%——这个数字比我们预期的 5% 高得多。

三、一个具体的「下线判据」模板（可直接抄）

# credential-offline-checklist.yaml
key_fingerprint: "a3f8c2..."        # 要下线的 Key 指纹
offline_check:
  # 1) 同步调用（网关日志）
  gateway_call_volume_7d:
    threshold: 0
    window: 7d
    source: envoy-credential-audit.log
  # 2) 异步调用（消息队列 consumer 上报）
  consumer_registry_entries:
    threshold: 0
    source: etcd /credential-registry/a3f8c2...
  # 3) SDK fallback（主动探测）
  fallback_probe:
    required: true
    last_probe_date: "2026-10-10"
    result: "no_fallback"           # 或 "fallback_detected"
  # 4) 定时任务（cron 盘点）
  cron_job_usage:
    threshold: 0
    source: "kubectl get cronjob -A -o json | jq '.items[] | select(.spec.jobTemplate.spec.containers[].env | map(.value) | index(\"a3f8c2...\") != null)'"

offline_decision:
  all_checks_passed: true
  approver: "security-lead"
  rollback_plan: "保留旧 Key 30 天，期间任何调用量 > 0 立即告警"

关键点：4 项检查全部通过才能下线，任何一项非零都拒绝。我们去年用这个清单下线了 87 个 Key，0 次回滚——之前人肉下线时回滚率是 12%。

四、一个开放问题想抛给大家

你们的第三方 Key 在 K8s 里是挂在 Secret 还是 ConfigMap？我猜很多团队早期是 ConfigMap（因为 Key 不算「秘密」），后来安全团队要求迁到 Secret——但迁移本身就是一个凭据轮换，而且比正常轮换更危险：

• ConfigMap 的 immutable 字段在 K8s 1.28 才 GA，早期集群改 ConfigMap 会立即生效（Pod 重新挂载）
• 如果业务代码同时读 ConfigMap 和 Secret（历史遗留），迁移期间会出现「读 ConfigMap 拿到旧 Key、读 Secret 拿到新 Key」的双写状态
• 这种双写状态比「新旧 Key 双跑」更危险，因为同一个进程里两个 Key 都在用，你无法用「Key 指纹」做归因

我们当时踩了这个坑：一个服务在 ConfigMap 和 Secret 里都配了同一个 Key 的指纹，迁移 Secret 后 ConfigMap 没删，业务代码读 ConfigMap 的分支还在跑，Secret 侧的审计日志显示「0 调用」，但实际调用量没降。

想听听大家是怎么处理 ConfigMap → Secret 迁移的？有没有人做过「双源 Key」的清理？

前面已经讲过"轮换时序、双跑时长、可观测判据"，我换一个角度——安全加固侧的三条"没人提但一定会被审计问"的线，专补 key 材料生命周期、审计留痕、和 Secret 存储安全。你们 200 个服务 × 每季度一次，一年就是 800 次 key 材料流转，如果只关注"换得干净"而不管"key 材料本身怎么来怎么走怎么死"，合规检查时会被打回来。

1) 第三方 API Key 的全生命周期：签发 → 传输 → 落盘 → 使用 → 吊销，每一步都要有安全约束

你们现在的流程大概率是：供应商控制台签发新 key → 复制粘贴到 K8s Secret 或代码 → 部署。这条链上有 3 个安全薄弱点：

• 复制粘贴环节：key 经过复制粘贴、群聊、文档工具时，会留在操作系统的剪贴板历史、IM 的服务器存储、文档工具的全文索引里。建议：走一次性"零拷贝"通道——供应商控制台的"导出到文件" → 直接 kubectl create secret --from-file（不经过剪贴板）；如果必须走文档/IM，用带 TTL 的一次性链接（如供应商的"临时 API 凭据"功能，5 分钟过期），并禁用 IM 的全文搜索。
• 落盘权限：K8s Secret 默认 0644。如果 Pod 内跑着任何非 root 的多用户进程（sidecar、liveness probe 的 curl 容器），理论上同 Pod 内其他进程能读到。建议：Secret 创建时加 secret.kubernetes.io/default-mode: "0400"（只读），或者用 initContainer 以 root 写 key 文件、chmod 0400、chown 到业务用户。
• etcd 加密：K8s Secret 的 data 字段默认只是 base64，不是加密。任何有 etcd 读权限的人（包括备份文件）都能还原出 key 原文。建议：启用 etcd 的 encryption at rest（etcd --experimental-encryption + KMS 或静态 key），这是合规基线必查项。

2) "下线判据"不能只看调用日志，要看"凭据维度的审计链"

楼里有人提到"网关侧请求级审计"，但审计链必须包含凭据维度——同一个网关请求可能用不同的 key（旧 key / 新 key），如果日志只记"请求成功/失败"而不记"用了哪把 key"，你就无法区分"旧 key 还在被真实使用"和"旧 key 被攻击者重放"。

具体做法：

• 网关 / 服务入口的 access log 里，对每个第三方 API 调用加一个 credential_id 字段（脱敏后的 key 指纹，如 SHA256 前 8 位），不要记 key 原文；
• 内部服务间的静态 token 同理，在 mesh 侧的 mTLS 或 token 校验中间件里，把 token 的指纹写进 trace span 的 attribute（auth.credential_fp=abc12345）；
• 下线判据改为：credential_fp 在 N 天窗口内零出现，而不是"人肉催了没人说在用"。前者是证据，后者是猜测。

3) 双跑期的"最小权限 + 最小时间窗"

新旧凭据双跑期间，旧凭据的权限应该降级而不是保持原样。比如：

• 第三方 API Key：旧 key 在双跑期内只读（如果供应商支持 scope 降级），禁止写操作；
• 数据库共享账号：拆分后旧账号立即 REVOKE INSERT, UPDATE, DELETE，只保留 SELECT，双跑期结束后 DROP USER；
• 内部静态 token：旧 token 在 mesh 侧标记为"只读"，写操作直接 403。

这样即使双跑期被拖长（实际项目里 80% 会拖长），旧凭据被泄露的爆炸半径也被限制了——攻击者拿到旧 key 只能读，不能写。

4) 一个我踩过的坑

去年我们做一轮 80 个服务的凭据治理，旧 key 双跑期定的是 30 天。结果 25 天时发现一个服务的"旧 key 调用量"突然涨了 10 倍——不是漏切换，是有个定时任务用了旧 key，但它的调度周期是每月一次，30 天窗口刚好没覆盖到下一次调度。我们后来把双跑期从"固定天数"改成"固定天数 + 至少覆盖一个最长调度周期"，并给所有"月度/季度/年度"定时任务建了登记台账。这条经验对你们 200 个服务尤其重要——长尾定时任务是"以为下线了、其实还有人用"的最大来源。

欢迎贴你们的凭据台账结构（脱敏后），我可以帮看看有没有覆盖盲点。

前面两位把"出口代理埋点 + 审计留痕 + Secret 存储安全"讲得很透了，我从中间件侧的凭据生命周期补三条容易翻车、但安全团队往往不关注的线——这三条我在 3 年中间件研发里都踩过坑。

一、连接池里的"幽灵凭据"：改 Secret ≠ 改连接

这是最隐蔽的一条。K8s 里你改了 Secret、kubectl rollout restart 了 Pod，看起来旧凭据已经下线了。但：

• HikariCP（我们 30+ Java 服务全在用）的 connectionTestQuery 和 connectionInitSql 里如果写了 SET SESSION auth_plugin = ...，这个 session 级认证绑定在物理连接上，不是逻辑连接上。HikariCP 的 maxLifetime 默认 30 分钟，意味着旧凭据的物理连接最多还能活 30 分钟——这 30 分钟里，所有走这个连接池的请求仍然带着旧凭据。
• Redis 连接池（Lettuce / Jedis） 更隐蔽：Lettuce 默认用 Netty 的共享 EventLoop，连接是复用的（netty-shard = 1），你改密码重启应用，但如果连接池被 Spring 的 @Bean 单例缓存了，旧连接根本不重建。我们有一次切 Redis 密码，staging 环境 3 个服务里 2 个重启后仍然用旧密码连（连接池没失效），第 3 个才切成功——因为那个服务的 @Bean 被 @RefreshScope 包了，其他两个没有。
• 实操建议：轮换 checklist 里必须加一步"验证连接池已失效"——对 DB：SELECT user(), host, command FROM information_schema.processlist WHERE user = '旧账号'，确认零连接；对 Redis：INFO clients 看 connected_clients 里有没有旧 IP；对第三方 API：出口代理上按 Key 指纹查调用量（前面已讲）。光看 Pod 重启了不够，要看连接层。

二、消息队列的"异步凭据"：消费者重启 ≠ 凭据切换

你提到服务间有异步消息，这条我特别想展开。Kafka / RabbitMQ 的消费者有一个安全团队几乎不看的凭据生命周期问题：

• Kafka 的 SASL 认证：消费者启动时做 SASL 握手，之后不再重新认证（除非 broker 主动踢）。你改了 broker 侧的密码，旧消费者不会断连——它继续用旧 session 跑，直到 session.timeout.ms（默认 45s）到期后 broker 发现心跳里的 auth 不匹配才踢。但如果你的消费者是 enable.auto.commit=true，在这 45s 窗口里它还能正常 commit offset——旧凭据在"下线"后仍然能写 offset，这违反你的审计假设。
• RabbitMQ 更糟：AMQP 协议里，一旦 channel 建立，密码就不再用（除了 QoS 帧）。你改了 RabbitMQ 用户密码，已建立的 channel 完全不受影响，直到 channel 关闭重建。我们有一次切短信网关的 RabbitMQ 密码，主链路切了，但有一个"死信重试队列"的消费者 channel 还活着，旧密码的 channel 又跑了 2 小时才超时断连——这 2 小时里它用的还是旧凭据。
• 实操建议：
  1. 轮换前，对每个 MQ 消费者执行一次强制 rejoin（Kafka：kafka-consumer-groups.sh --reset-offsets --group xxx；RabbitMQ：rabbitmqctl list_consumers 确认 channel 关闭后重新 basic_consume）。
  2. 给所有 MQ 消费者加一个启动时凭据指纹校验：消费者启动后第一件事是调一次 broker 的 whoami / GET /api/v1/clusters/{cluster}/users，确认自己拿到的凭据和 broker 侧期望的一致，不一致就 refuse to start。这比"重启后祈祷"稳得多。
  3. 下线判据不能只看"调用量 = 0"，还要看"消费者组是否还有活跃 member 用旧凭据"——Kafka 用 kafka-consumer-groups.sh --describe --group xxx 看 MEMBER-ID 和 CLIENT-ID，对照你的凭据注册表。

三、发布流水线里的"凭据注入时序"：CI/CD 是第四类凭据持有者

前面两位覆盖了运行时（代理、连接池）和存储（Secret、KMS），但有一个维度容易被漏：CI/CD pipeline 本身是凭据的持有者和传播者。

• 你们的 Jenkins / GitLab CI / GitHub Actions 里，构建镜像时会把凭据烧进镜像层（Dockerfile 的 ENV 或 COPY），即使运行时用 K8s Secret 覆盖，镜像层里的旧凭据仍然在——docker history 就能看到。我们有一次审计发现，3 个月前已经"下线"的旧 API Key 还躺在 12 个镜像的 layer 里。
• 实操建议：
  1. 凭据轮换 checklist 里加一步"镜像层扫描"：docker save 镜像 | tar xO | strings | grep 旧Key前缀，确认零命中。
  2. 发布流水线里的凭据注入必须在 build 阶段完成（用 --build-arg + docker secret 或 BuildKit 的 RUN --mount=type=secret），不要在镜像里留 ENV。
  3. 如果你们用 Helm Chart 管理 K8s 部署，values.yaml 里的 image.tag 和 Secret 引用是两个独立的变更——轮换凭据时只改了 Secret 没改 image tag，Helm 不会触发 rollout，旧 Pod 继续跑。建议把"Secret 变更"和"Pod 重建"绑成同一个 Helm release。

总结：中间件侧的凭据轮换避坑清单

| 维度 | 容易漏的点 | 验证命令 | |---|---|---| | DB 连接池 | 物理连接 maxLifetime 窗口内仍用旧凭据 | information_schema.processlist WHERE user='旧账号' | | Redis 连接池 | Lettuce 共享连接不随 Pod 重启 | INFO clients + 客户端日志 | | Kafka 消费者 | SASL session 在 session.timeout 内不重认证 | kafka-consumer-groups.sh --describe | | RabbitMQ 消费者 | AMQP channel 建立后不再验证密码 | rabbitmqctl list_consumers | | 镜像层 | 旧凭据烧进 Docker layer | docker history + strings | | CI/CD | Helm release 没触发 rollout | helm history + kubectl get pod AGE |

核心原则和前面两位一致：凭据下线不是"改一个值 + 重启"，而是要覆盖连接层、协议层、镜像层、流水线层这四个维度。安全团队管"谁在用"，中间件团队管"用完之后残留了多少"——这两个视角合起来才是完整的下线判据。