后端面试：如何安全治理 W3C Baggage 的跨服务传播？

题干与适用场景

多个微服务通过 W3C baggage Header 传递租户、实验和请求来源。部分服务跨越不同公司或数据域，要求继续支持 OpenTelemetry 关联，同时避免把个人信息和内部标识传播给不该看到的下游。

面试官考察点

• 能否区分 Baggage 与 Trace Context，并理解它是任意键值的传播机制。
• 能否按信任边界做字段白名单、大小限制、脱敏和删除，而非盲目透传。
• 能否兼顾可观测性、兼容性、故障降级和审计证据。

回答前需要澄清的问题

先确认哪些服务属于同一信任域、允许传播的字段目录、最大 Header 大小、是否有浏览器或消息队列入口、日志和指标的保留期限，以及下游是否会把 Baggage 写入持久化数据。还要确认要求是阻断敏感键、限制跨域，还是迁移现有自定义 Header。

30 秒回答框架

我会把 Baggage 视为不可信输入，在入口解析并规范化，按来源、目标信任域和字段策略决定保留、重命名、哈希或删除。网关限制键值长度与总大小，禁止直接复制到日志和用户可见响应；在跨域出口采用白名单和签名版本。OpenTelemetry traceparent 独立传播，Baggage 过滤失败时宁可丢弃可选字段，不阻断核心请求，并记录可审计的策略命中结果。

分步骤深入解答

1. 维护版本化字段目录：字段用途、数据分类、允许的来源和目标信任域、最大长度、是否允许进入日志。
2. 在入口解析 RFC 格式，拒绝非法键、控制字符、过长值和重复冲突；保留原始请求摘要，不保存完整敏感 Header。
3. 在同域服务间按 allowlist 传播；跨域只发送最小化的公开键，必要时使用不可逆的租户别名或短期签名引用。
4. 对 OpenTelemetry 注入点增加显式过滤，避免自动 instrumentation 把所有 Baggage 复制到 spans、logs 或 metrics attributes。
5. 设置总字节数、键值数和 hop 次数上限；超限时删除低优先级字段并返回内部策略事件，不把敏感内容回显给调用者。
6. 出口网关按目标域重新评估策略，消息队列和异步任务也复用同一目录；禁止把 Baggage 当作授权凭证。
7. 记录字段名、策略版本、动作和目标域的审计事件，不记录原值；用合成数据测试泄露、大小攻击和多跳累积。

incoming baggage: tenant=acme,experiment=A,pii_email=alice@example.org
same-trust output: tenant=acme,experiment=A
cross-trust output: tenant_ref=hash:v3:...,experiment=A

高质量示范回答

我会先声明 Baggage 不是认证或授权载体，所有值都按不可信输入处理。入口依据版本化字段目录解析并限制大小，服务间传播采用 allowlist；跨信任域只传最小化别名或短期引用。OpenTelemetry 的 trace context 与 Baggage 分开处理，自动注入必须经过过滤，日志不写原值。超限或策略未知时删除可选字段，继续核心请求并记录字段名、动作和策略版本。通过多跳合成测试、队列边界测试和审计查询验证效果，逐步收紧目录而不把隐私风险隐藏成“链路追踪正常”。

常见错误

• 把 Baggage 当作可信身份、权限或租户隔离依据。
• 允许任意键跨越信任边界，或只靠字符串黑名单过滤。
• 将完整 Header 写入日志、Trace 或错误响应。
• 只治理 HTTP，遗漏消息队列、重试和异步任务。
• 超限直接返回 4xx 造成核心业务中断，或静默丢弃且没有审计。

追问及应对

Baggage 和 Trace Context 有什么区别？

Trace Context 携带驱动分布式追踪所需的标准元数据；Baggage 是应用定义的键值集合，可独立使用，语义由应用负责，因此隐私和信任风险更高。

为什么字段白名单优于黑名单？

Baggage 的键和值没有固定业务语义，新字段会不断出现；白名单默认拒绝未知数据，能避免新增服务或供应商意外扩散敏感值。

过滤失败时应阻断请求吗？

若字段只是观测辅助，删除可选字段并继续请求更稳妥；若业务明确依赖字段，应返回可识别的策略错误，但不能把原值回显。决策应由字段目录标注的关键性驱动。

如何证明没有把原值写入遥测？

在 Collector 和应用 SDK 两侧做脱敏测试，扫描日志、span attributes 与指标标签，记录策略版本和字段名而非值，并对异常样本设置告警。