後端面試：如何安全治理 W3C Baggage 的跨服務傳播？
題幹與適用場景
多個微服務透過 W3C baggage Header 傳遞租戶、實驗與請求來源。部分服務跨越不同公司或資料域，要求繼續支援 OpenTelemetry 關聯，同時避免把個人資料與內部識別碼傳給不應看到的下游。
面試官考察點
- 能否區分 Baggage 與 Trace Context，並理解它是任意鍵值的傳播機制。
- 能否按信任邊界做欄位白名單、大小限制、去識別與刪除，而非盲目透傳。
- 能否兼顧可觀測性、相容性、故障降級與稽核證據。
回答前需要釐清的問題
先確認哪些服務屬於同一信任域、可傳播欄位目錄、最大 Header 大小、是否有瀏覽器或訊息佇列入口、日誌與指標保留期限，以及下游是否會把 Baggage 寫入持久化資料。也要確認要求是阻擋敏感鍵、限制跨域，還是遷移現有自訂 Header。
30 秒回答框架
我會把 Baggage 視為不可信輸入，在入口解析並規範化，按來源、目標信任域與欄位策略決定保留、重新命名、雜湊或刪除。閘道限制鍵值長度與總大小，禁止直接複製到日誌和使用者可見回應；跨域出口採用白名單與簽章版本。OpenTelemetry traceparent 獨立傳播，Baggage 過濾失敗時寧可丟棄可選欄位，不阻斷核心請求，並記錄可稽核的策略命中結果。
分步驟深入解答
- 維護版本化欄位目錄：欄位用途、資料分類、允許的來源與目標信任域、最大長度、是否允許進入日誌。
- 在入口解析 RFC 格式，拒絕非法鍵、控制字元、過長值與重複衝突；保留原始請求摘要，不保存完整敏感 Header。
- 同域服務間按 allowlist 傳播；跨域只傳送最小化公開鍵，必要時使用不可逆租戶別名或短期簽章引用。
- 對 OpenTelemetry 注入點增加明確過濾，避免自動 instrumentation 把所有 Baggage 複製到 spans、logs 或 metrics attributes。
- 設定總位元組數、鍵值數與 hop 次數上限；超限時刪除低優先級欄位並回傳內部策略事件，不把敏感內容回顯給呼叫者。
- 出口閘道按目標域重新評估策略，訊息佇列與非同步任務也共用同一目錄；禁止把 Baggage 當作授權憑證。
- 記錄欄位名、策略版本、動作與目標域的稽核事件，不記錄原值；用合成資料測試洩露、大小攻擊與多跳累積。
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 與指標標籤，記錄策略版本和欄位名而非值，並對異常樣本設置告警。