mTLS 客户端证书私钥泄露（非轮换场景）：暴露面怎么量化？有没有一份"清除 + 验证已清干净"的 checklist 可以直接抄？

结论：mTLS 私钥泄露的应急处置分三步——「先杀后清再验」，顺序反了等于没做。下面按你期望的三种形态逐一给。

一、可复现的暴露面清单（按介质分类）

核心原则：先轮换（让旧密钥失效）→ 再清介质 → 最后验证。轮换是唯一的"釜底抽薪"，清除只是降低二次风险面。

1. CI 构建机 /tmp

| 步骤 | 命令 / 动作 | 验证方式 | 判定标准 | |------|------------|---------|---------| | 清除 | find /tmp /var/tmp /home -name "*.pem" -o -name "*.key" 2>/dev/null \| xargs -r shred -u -z；再 sync && echo 3 > /proc/sys/vm/drop_caches | grep -rl "<PEM首行base64前64字符>" /tmp /var/tmp /home 2>/dev/null（用密钥 PEM 头部唯一片段做指纹） | 无输出 + 无残留 inode（lsof +D /tmp 无 .pem） | | 深层 | 检查 swap：grep -c "<指纹>" /dev/vgswap* 2>/dev/null；检查 crash dump：find /var/crash -name "*.dmp" -exec strings {} \| grep "<指纹>" | 同上 | 无匹配 | | 进程内存 | 泄露时若有进程持有该文件 fd：lsof \| grep pem，确认无进程仍持有 | lsof 输出为空 | 无进程持有 |

关于 page cache：echo 3 > /proc/sys/vm/drop_caches 会清 page cache，但不能清进程私有内存页。如果泄露文件当时被某进程 mmap 或 read 进 heap，那部分在进程退出前无法清除——所以轮换优先级高于清除，清不干净也 OK，因为旧密钥已经失效了。

2. Git 对象库（本地 + 远端）

| 步骤 | 命令 | 验证 | |------|------|------| | 定位 | git log --all -p -S "<指纹片段>" -- '*.pem' '*.key'；若历史被 squash 过，用 git cat-file --batch-all-objects --batch-check \| while read h _ t _; do git cat-file -p $h 2>/dev/null \| grep -q "<指纹>" && echo "$h"; done（全量对象扫描，10k 对象约 30s） | 输出为空 | | 清除（本地） | git filter-repo --path <path> --invert-paths（比 BFG 更彻底，重写所有引用） | 同上全量扫描 | | 清除（远端） | 强制 push 后，要求 CI 平台/镜像仓库清除 build cache；GitHub 需联系 support 清 cache | 重新 clone 后 git cat-file --batch-all-objects 再扫一次 | | 派生副本 | 所有 git clone 的本地副本：开发者列表 × git log --all -p -S "<指纹>" | 全员确认 |

反直觉坑：git revert 不清对象，git rm + commit 也不清。只有 filter-repo / git filter-branch 重写历史 + 强制 push + 全端重新 clone 才真正清除。

3. Docker / containerd 镜像层

| 步骤 | 命令 | 验证 | |------|------|------| | 定位 | docker history <image> 逐层看；docker save <image> -o /tmp/img.tar && tar -xOf /tmp/img.tar layer.tar \| strings \| grep "<指纹>" | 无匹配 | | 清除 | 删除所有含该层的 image：docker rmi <sha>；containerd 下 crictl rmi <image-ref> | docker images / crictl images 无残留 | | build cache | docker builder prune -a -f（或 BuildKit 的 BUILDKIT_CACHE_MOUNT_PATH 目录 rm -rf） | 重新 build 不含该密钥 |

4. K8s Secret（base64 副本）

| 步骤 | 命令 | 验证 | |------|------|------| | 轮换 | kubectl rollout restart deployment/<svc>（触发 cert-manager 重签）；或直接 kubectl delete secret <name> && kubectl apply -f new-secret.yaml | kubectl get secret <name> -o jsonpath='{.data.tls\.key}' \| base64 -d \| head -1 确认是新密钥 | | etcd 中残留 | etcd 的 MVCC 会保留旧 revision 直到 compaction。如果泄露的 Secret 曾被 kubectl delete + re-create，旧值仍在 etcd 中直到 compaction（默认 1h）。关键动作：etcdctl --endpoints=https://127.0.0.1:2379 compaction（需要 etcd 访问权限） | etcdctl get --prefix /registry/secrets/ \| grep "<指纹>" 无输出 | | 备份介质 | etcd 快照（etcdctl snapshot save）、Veeam / Velero 备份：逐一 etcdctl snapshot restore 到隔离环境后 grep | 快照中无该密钥 |

5. 开发机本地

• 通知所有有 clone 权限的人（你的场景是 2 名外包），要求执行：git -C <repo> log --all -p -S "<指纹>" + find ~/ -name "*.pem" -exec grep -l "<指纹>" {} \;
• 如果无法确认（外包已离职），按"未清除"处理，轮换是唯一兜底。

6. CI 平台 secret 缓存

• Jenkins：JENKINS_HOME/secrets/ 目录 + JENKINS_HOME/workspaces/*/ 构建目录
• GitLab CI：Runner 的 builds/ 目录 + artifacts/
• 清除后验证：grep -rl "<指纹>" $JENKINS_HOME/ 2>/dev/null

二、吊销传播延迟的测量方法

你问的"标记吊销 → 最后一个存量连接断开"的时间，取决于验证方的检查策略，不是网络传播。Istio mTLS STRICT 下的实际机制：

1. 新连接：每次 TLS 握手时，Istio sidecar（istio-agent）校验对端证书 + 查 SDS 拿的 CA bundle 中是否有 CRL/OCSP。如果你用的是 cert-manager + 自签 CA，默认没有 CRL 分发点——吊销靠的是「轮换后旧证书不再被 CA 信任」，即 sidecar 的 CA bundle 更新后，旧证书签名链断裂。

2. 存量连接（已握手）：TLS 1.2/1.3 的已建立会话在对端主动断开或 TLS session timeout 到期前不会重新验证。gRPC keep-alive 30s 只是 ping 包，不触发重新握手。

精确测量方法（可在 staging 复现）

# 1. 建立一条 gRPC 长连接（客户端 A → 服务端 B）
grpcurl -v -plaintext localhost:50051 myservice.Ping &  # 或 grpc_health_check

# 2. 记录时间 T0
T0=$(date +%s.%N)

# 3. 触发吊销：删除旧 Secret → cert-manager 重签 → 新证书下发
kubectl delete secret <old-cert>
# 等待 istio-agent 刷新（默认 SDS 推送 < 5s）

# 4. 在客户端 A 上循环发请求，直到收到 GOAWAY / connection reset
while grpcurl -plaintext localhost:50051 myservice.Ping 2>/dev/null; do sleep 1; done

# 5. 记录时间 T1
T1=$(date +%s.%N)
echo "传播延迟: $(echo "$T1 - $T0" | bc)s"

影响变量清单：

• istio-agent 的 SDS 证书刷新周期（默认 15s 检查一次，push 模式 < 5s）
• 服务端 sidecar 收到新 CA bundle 后，对已建立连接的处理：Istio 1.21 默认不断开存量连接，直到连接自然关闭或 PILOT_CERT_TTL 到期
• 如果你们配了 meshConfig.defaultConfig.proxyMetadata 中的 GRPC_KEEPALIVE_TIME，keep-alive ping 不触发重新认证
• 实际窗口 = max(存量连接生命周期, CA bundle 刷新延迟)，通常 5~30s（Istio push 模式）到 15min（如果 sidecar 重启后从 SDS 重新拉取）

建议：在 Istio 的 meshConfig 中加 defaultConfig.proxyConfig.stdsInitialDelay: 1s，并开启 PILOT_ENABLE_TLS_SESSION_RESUMPTION: false（避免 TLS session resumption 绕过验证）。

三、时间线模板（可直接抄）

T+0min    发现密钥落盘（CI 构建机 /tmp）
T+0~5min  确认泄露范围：哪些进程曾持有该文件 fd（lsof）、是否有 cron 任务读取
T+5~15min 执行轮换：删除旧 Secret → cert-manager 重签 → 全集群 sidecar 刷新
          （此步完成后，旧密钥对新连接已无效，存量连接进入"衰减窗口"）
T+15~30min 清除 CI 构建机 /tmp + build cache
T+30~60min 清除 git 对象库（filter-repo + force push + 全端 re-clone）
T+60~120min 清除镜像层 + K8s Secret 旧 revision（etcd compaction）
T+120min+ 通知外包开发自查开发机，收集确认回执
T+24h     验证闭环：全介质 grep 指纹无命中 + 监控 24h 无异常 TLS 握手失败
T+72h     安全审计 sign-off

关键决策点：

• 轮换在清除之前（T+5 就轮换，T+15 才开始清）——因为清不干净也是常态，但轮换后旧密钥已死
• etcd compaction 容易被遗漏——Secret 被 delete + recreate 后，旧值在 etcd 中存活到 compaction，窗口可达 1h
• page cache 不需要清——只要进程不再持有该文件的内存映射，OS 会在内存压力下回收；而且你无法从用户态强制清某个进程的私有内存页

踩坑点（来自实际事故）：

1. find / -name "*.pem" 漏掉了没有 .pem 后缀的文件（运维脚本写成了 key_$(date +%s) 这种命名）——用内容指纹（PEM 头部 base64 前 64 字符）做 grep -rl 比文件名匹配可靠 10 倍
2. Docker build cache 的 layer 即使 docker rmi 了，/var/lib/docker/overlay2/ 下可能还有残留——需要 docker system prune -a 或 rm -rf /var/lib/docker/overlay2/*
3. Istio SDS 推送有 1~5s 延迟，不要假设"删除 Secret 的瞬间全网就失效了"——留 30s 安全余量

引用 [1] 的清除顺序（轮换 → 清本地 → 清远端 → 清派生副本）完全适用本场景，补充一点：在"清派生副本"之后还有一步清 etcd 旧 revision，这是 K8s 场景特有的。