K8s 容器日志里的 PII 脱敏：在应用层、filebeat 还是 ELK 做最合适？

【背景】 我负责一套跑在 K8s 1.28（containerd，自建集群）上的 Java 17 / Spring Boot 3.1 业务，日志链路是：应用打 stdout → 节点 filebeat 采集 → Logstash 过滤 → Elasticsearch 7.17 → Kibana。最近一次合规审计挂了一条：「日志中出现的手机号、身份证号、银行卡号必须脱敏后落盘，且不得在采集链路任一环节以明文留存」。

【现象 / 卡点】

1. 手机号、身份证、银行卡号散落在三类日志里：业务日志（logback 打的）、异常堆栈（第三方 SDK 自己拼的）、access log（nginx sidecar 打的）；
2. 现状是 ELK 里能搜到完整明文，filebeat 节点上的 spool 文件里也是明文——审计口径认为「任一环节明文留存」都算不过；
3. 我们尝试过在 Logstash 里用 mutate.gsub + 正则打码，能跑，但：身份证 18 位和银行卡 16–19 位正则写不准（误伤订单号、traceId），且 Logstash 挂掉时 filebeat 已经把明文 spool 到本地了，等于没脱；
4. 在应用层 logback 里加 Converter 打码：能覆盖业务日志，但第三方 SDK（支付、短信网关）自己拼的堆栈管不到，nginx access log 里的 referer/query 也管不到；
5. 团队 8 人，没有专职 SRE，方案要能落地、可回滚、不能把日志链路搞得太脆。

【已尝试与结果】

• Logstash mutate.gsub 正则打码：能跑，误伤率约 2%（订单号、traceId 被误打），且解决不了 filebeat spool 与 nginx 日志的明文；
• logback 自定义 Converter（手机号 3-4-4、身份证保留前 6 后 4）：业务日志 OK，第三方堆栈与 access log 覆盖不到；
• 看了 Elastic 官方的 geoip / user_agent 处理器，没有 PII 脱敏插件，社区版 dissect/grok 组合写正则成本太高；
• 考虑过 OpenTelemetry Collector 替换 filebeat + Logstash，但迁移成本大、团队没经验，先排除。

【期望得到的答案形态】 希望跑过同类链路的同学给一个可落地的分层方案，重点：

1. 脱敏位置怎么选：应用层 Converter / filebeat processors（如 mask、mutate）/ Logstash 三层各自适合拦哪类日志，有没有「只在 filebeat 一层就够」的判据？
2. 正则与误伤：身份证 18 位、银行卡 16–19 位、手机号 11 位，有没有踩过坑的正则写法或现成处理器（比如 filebeat 的 mask processor 对身份证支不支持）？怎么和订单号、traceId 区分？
3. filebeat spool 明文：filebeat 在本地 spool 的明文文件，有没有办法让它「落盘即脱」？还是只能靠节点磁盘加密 + 短 TTL 兜底？
4. 可回滚：脱敏规则想灰度 / 回滚，怎么做到「规则集中管理、按服务灰度、出问题能秒回」？有没有现成的配置中心 + 动态加载方案？
5. 审计对齐：合规审计认「脱敏后落盘」的口径，有没有同学对过审计，知道他们具体看哪几个环节（filebeat spool / Logstash 内存 / ES 索引）？

不用贴完整 pipeline，给分层判据 + 关键配置片段 + 踩坑点就行。