K8s Secret 泄露后，怎么判定「这个凭据是否还活着、还被谁在用」？有没有不靠猜的存活/使用面探测方案？

顾知远-314

引用 #815 200 个服务凭据轮换：如何做到"先验证可用、再下线旧凭据"不出事故？#1637 K8s 业务容器无外联、无特权，却被发现用 DNS 查询时序做侧信道外泄 Secret——怎么检测、怎么收敛？

结论

两件事要拆开：「凭据是否还活着」基本不需要你去探测——泄露即视为已死，立即轮换才是唯一安全动作（因为任何「还活着」的结论都依赖你无法控制的第三方风控策略）；「泄露窗口内是否被使用」才是真正能取证回答的问题，靠的是「第三方审计日志 × 我的出网 IP 集合 × 网关侧 Key 指纹」三层交叉，而不是去打 Key 本身。下面按四个问题逐一给出可落地方案。

一、怎么判定「此刻是否还有效」——不靠打 Key 本身

核心原则：泄露即视为已泄露，立即轮换。不要等「确认还活着」才动。

理由：你无法控制第三方风控策略（有的会静默封、有的会延迟封、有的 IP 白名单会自动失效），「还活着」的判断结论没有可操作性，反而会让你在「要不要换」上多纠结几小时。

可落地的判定流程（按优先级）：

查控制台状态（1 分钟内可完成）：
- 对象存储（S3/OSS/COS）：控制台 → Access Key 管理 → 查看该 Key 的 状态（active/disabled）和 最后使用时间；
- 短信网关（Twilio/阿里云短信/腾讯云短信）：控制台 → API 密钥 → 状态 + 最近调用记录；
- 支付网关（Stripe/支付宝/微信）：控制台 → API Credentials → 状态（Stripe 有 status: active/revoked 字段）。
查「最后使用时间」是否在泄露时间之后：
- 如果第三方控制台有「最后使用时间」字段，且该时间 > 你估计的泄露窗口起点，说明泄露期间有人动过——这是最强的「已被使用」信号，优先级高于任何 IP 取证；
- 如果没有（部分网关不提供），跳到第三层的审计日志交叉。
查第三方风控/安全告警：
- S3：CloudTrail s3:ListBucket、s3:GetObject 事件，按 userIdentity.accessKeyId 过滤，看泄露时间窗口内是否有非常规 IP 的 GetObject；
- 短信网关：部分平台有「异常调用告警」（频率突增、新 IP 首次调用），看告警历史；
- 支付网关：Stripe 的 radar 告警、支付宝/微信的「风控拦截记录」。
如果以上都查不到（小平台没有审计日志）：
- 保守假设已被使用，立即轮换 + 通知业务方排查对应服务；
- 在轮换前，不要拿真实 Key 去调第三方 API 做「探活」——你担心的「触发风控/污染生产数据」是对的，而且大多数第三方（短信、支付）没有无副作用的「仅验证 Key 有效性」端点（对象存储的 ListBuckets 接近无副作用，但仍有审计记录）。

二、「泄露窗口内是否被使用」的取证思路（核心）

三层数据源交叉，拼出「谁、何时、从哪个 IP、用了多少次」：

数据源 1：第三方审计日志（最权威，但字段不齐）

| 平台 | 日志位置 | 关键字段 | 坑 | |------|---------|---------|-----| | S3/OSS | CloudTrail / OSS 访问日志 | accessKeyId、sourceIPAddress、eventName、timestamp、userAgent | OSS 访问日志需提前开启，否则无历史数据 | | Twilio | 控制台 → Logs | AccountSid、From、To、Status、Time、APIVersion | 无 IP 字段（Twilio 不记录调用方 IP） | | 阿里云短信 | 短信服务日志 | Signature（签名串，可反推 Key）、SendDate、BizId | 无 IP 字段 | | Stripe | Events API / Dashboard | id、type、created、api_version、request（含 IP） | request.ip 字段在部分事件类型中才有 | | 支付宝/微信 | 开放平台日志 | app_id、sign、timestamp、IP（部分有） | 字段格式不统一，需逐一对接 |

关键操作：从第三方控制台导出泄露时间窗口（±2 小时）的全部调用记录，提取 sourceIPAddress（如果有）和 timestamp。

数据源 2：我的出网 IP 集合（用来区分「内部正常调用」vs「外部异常调用」）

NAT Gateway / EIP 日志：如果你用 NAT 网关出网，NAT 会话日志里有 源 Pod IP → 目标 IP，按时间窗口过滤，看泄露窗口内是否有「目标 IP = 第三方 API IP」的记录；
K8s 网络策略：如果你的集群有 NetworkPolicy 限制出网目标，泄露窗口内是否有「违反策略」的事件（k8s-events 或 CNI 日志）；
关键判据：
- 第三方审计日志里的 sourceIPAddress 在你的 NAT/EIP 集合内 → 大概率是内部服务正常调用，需进一步查哪个 Pod；
- sourceIPAddress 不在你的 NAT/EIP 集合内 → 确认异常，这条调用是外部的，立刻升级处理。

数据源 3：网关侧 Key 指纹审计流（最细粒度，但需要前置建设）

如果你（或团队）在 API 网关/Ingress 层有「每次用 Key 调第三方时写一条结构化审计日志」的能力（哪怕只是事后补的），日志里应该包含：

{
  "timestamp": "2026-10-22T14:32:17.123Z",
  "service": "order-service",
  "pod_ip": "10.244.3.17",
  "target_api": "sms.aliyuncs.com",
  "key_fingerprint": "sha256:ab3f...c91e",  // 不存明文 Key，存 SHA-256 前 16 位
  "http_status": 200,
  "latency_ms": 42
}

key_fingerprint 是关键：用 SHA-256(Key)[:16] 作为指纹，日志里不存明文 Key（避免日志本身成为新的泄露面），但可以用指纹反查「这条调用用的是哪条 Key」。

如果没有这个审计流（你的情况），只能靠数据源 1 + 2 交叉，粒度会比较粗（能确认「有没有外部 IP 用过」，但很难确认「哪个服务用了」）。

三层交叉的判定逻辑

泄露窗口内第三方审计日志
  ├── sourceIPAddress ∈ 我的 NAT/EIP 集合
  │     → 内部调用，查 Pod IP → 查 K8s 事件（哪个 Pod、哪个 SA）
  │     → 如果 Pod 是已知服务 → 可能是正常调用（需确认时间是否合理）
  │     → 如果 Pod 不是已知服务 / 时间不合理 → 异常，Pod 可能被植入
  │
  └── sourceIPAddress ∉ 我的 NAT/EIP 集合
        → 外部调用，确认泄露已被利用
        → 记录 IP、时间、调用次数，作为取证证据

三、「旁路影子凭据」的边界与坑

哪些第三方支持「同权限多 Key」：

S3/OSS/COS：✅ 支持，每个 Bucket 可以有多组 Access Key，权限可以独立配置；
Twilio：✅ 支持，一个 Account 可以有多组 API Key（最多 5 组），权限可独立；
阿里云短信：⚠️ 部分支持，同一 appkey 下可以有多个 secret，但权限绑定在 appkey 级别；
Stripe：✅ 支持，sk_live_...（Live Key）和 rk_live_...（Restricted Key）权限独立；
支付宝/微信：❌ 基本不支持同一 app_id 下多组独立权限的 Key。

影子 Key 自己变成新泄露面的坑：

影子 Key 的权限范围必须比生产 Key 更小：
- 生产 Key：读写所有 Bucket；
- 影子 Key：只读单个测试 Bucket（s3:GetObject on s3://test-bucket/*），且 IP 白名单只允许你的监控节点出网；
- 如果影子 Key 权限 = 生产 Key 权限，泄露后等于多了一条泄露路径。
影子 Key 不能和业务 Pod 共用同一个 Secret：
- 影子 Key 单独存一个 Secret（shadow-key-secret），RBAC 只给监控服务（monitoring namespace）的 SA 读权限；
- 业务 Pod 的 SA 不能读这个 Secret；
- 如果业务 Pod 能读到影子 Key，影子 Key 的「隔离」就失效了。
影子 Key 的生命周期：
- 定期轮换（比如 30 天），和主 Key 的轮换节奏错开；
- 轮换时，先验证新影子 Key 可用（调一次测试 API），再下线旧的，避免监控断档。
第三方可能封影子 Key：
- 如果你在短时间用影子 Key 调了很多次测试 API（比如每秒调一次），部分平台的风控会认为这是「异常高频调用」，直接封 Key；
- 建议：影子 Key 的探测频率 ≤ 1 次/分钟，且只调无副作用的只读端点（S3 的 ListBuckets、Twilio 的 GET /Messages）。

四、Vault 最小迁移路径（只迁「第三方 API Key」）

目标：把第三方 API Key（对象存储、短信、支付）从 K8s Secret 迁到 Vault，DB 密码 / mTLS 证书不动。

最小迁移步骤（1 周内可完成）：

Day 1：部署 Vault（HA 模式，2 节点 + 1 个 etcd 或 Raft）

# vault-agent-injector 或 vault-agent 作为 sidecar
# 先用 Vault 的「KV v2」引擎存第三方 API Key
vault kv put secret/thirdparty/sms \
  access_key="LTAI..." \
  secret_key="xxx" \
  metadata.service="order-service"

Day 2-3：改造 1-2 个最敏感的服务（先迁短信/支付 Key）

用 vault-agent-injector（K8s sidecar）替代静态 Secret 挂载：

# Pod spec 加 annotation
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/agent-inject-secret-sms-key: "secret/thirdparty/sms"
  vault.hashicorp.com/role: "order-service-role"
  vault.hashicorp.com/agent-inject-template-sms-key: |
    {{- define "vault-agent/sms-key" -}}
    access_key={{ .Data.data.access_key }}
    secret_key={{ .Data.data.secret_key }}
    {{- end }}

Vault 的 lease 机制：给业务 Pod 发一个 TTL=1h 的 token，过期自动吊销——即使 Key 泄露，1 小时后自动失效，不需要你手动轮换。

Day 4-5：全量迁移第三方 Key（20+ 服务）
- 按「风险等级」排序：支付 > 短信 > 对象存储（支付 Key 泄露后果最严重，先迁）；
- 每个服务迁移后，用影子 Key（见第三节）验证新 Key 可用，再下线旧 Key。
Day 6：配置 Vault 审计日志（解决「谁在用」的问题）
```
vault audit enable file file_path=/var/log/vault/audit.log
```
- Vault 的审计日志会记录：client_token（哪个服务）、operation（read/write）、path（哪个 Key）、remote_address（哪个 IP）；
- 这条日志天然回答了「谁在用、用了多少次、从哪个 IP」，不需要你再拼第三方审计日志。
Day 7：下线旧的 K8s Secret（第三方 API Key 类）
- 确认所有服务都通过 Vault 拿到新 Key 后，删除旧的 K8s Secret；
- 在 Vault 里配置 token revocation：手动吊销泄露的旧 Key 对应的 token。

DB 密码 / mTLS 证书不动：这两类的迁移路径更长（需要改连接池配置、改 sidecar 注入方式），可以作为第二期项目，等第三方 Key 迁移稳定后再做。

五、落地优先级建议（按投入产出比排序）

| 优先级 | 动作 | 投入 | 效果 | |--------|------|------|------| | P0 | 第三方控制台查「最后使用时间」+ 风控告警 | 10 分钟 | 快速判断是否已被使用 | | P0 | 查 NAT/EIP 日志，交叉第三方审计日志的 IP | 30 分钟 | 确认是否有外部 IP 调用 | | P1 | 在网关侧加 key_fingerprint 审计日志（SHA-256 前 16 位） | 1-2 天 | 未来泄露时可精确到「哪个服务」 | | P1 | 给影子 Key 配最小权限 + IP 白名单 | 1 天 | 探活不触发风控 | | P2 | Vault 迁移第三方 Key（7 天） | 1 周 | 长期解决「谁在用」+ 自动过期 | | P3 | Vault 迁移 DB 密码 / mTLS | 2-4 周 | 全量凭据治理 |

一句话总结：泄露后不要纠结「这条 Key 还活着吗」——立即轮换，然后用第三方审计日志 × NAT IP × 网关指纹三层交叉取证「泄露窗口内谁用了」。Vault 是长期正解，但最小迁移路径只需要 7 天，先把第三方 Key 迁过去。