Entrevista de backend: ¿Cómo gobernaría de forma segura la propagación de W3C Baggage?

Pregunta y escenario

Varios microservicios utilizan el encabezado W3C baggage para el contexto del inquilino, del experimento y del origen de la solicitud. Algunos servicios cruzan los límites de la empresa o del dominio de datos, por lo que la correlación de OpenTelemetry debe mantenerse mientras que los datos personales y los identificadores internos permanecen fuera de los sistemas downstream no confiables.

Qué evalúa el entrevistador

• Separar Baggage de Trace Context y reconocer la propagación arbitraria de clave-valor.
• Aplicar listas de permitidos (allowlists) en los límites de confianza, límites de tamaño, redacción y eliminación en lugar de un reenvío a ciegas.
• Equilibrar la observabilidad, la compatibilidad, la degradación elegante y la evidencia de auditoría.

Preguntas aclaratorias antes de responder

Aclare qué servicios comparten un dominio de confianza, el catálogo de campos permitidos, el tamaño máximo de encabezado, los puntos de entrada del navegador o de colas, la retención de telemetría y si los sistemas downstream persisten Baggage. Aclare si el objetivo es bloquear claves confidenciales, restringir la propagación entre dominios o migrar encabezados personalizados.

Estructura de respuesta de 30 segundos

Trataría a Baggage como una entrada no confiable. Lo analizaría y normalizaría en el ingreso (ingress), para luego retener, renombrar, aplicar hash o eliminar campos según el origen, el dominio de confianza de destino y la política. La puerta de enlace limita el tamaño por clave/valor y el tamaño total, nunca copia valores sin procesar en registros (logs) ni en respuestas a usuarios, y utiliza una lista de permitidos junto con la versión de la política en la salida (egress) entre dominios. Traceparent se maneja de forma independiente. Si el filtrado falla, se descartan los campos opcionales, se continúa con la solicitud principal y se registra una acción de política auditable.

Respuesta profunda paso a paso

1. Mantenga un catálogo de campos versionado: propósito, clase de datos, dominios de origen y destino permitidos, longitud máxima y permisos de registro (logging).
2. Analice el formato estándar en el ingreso y rechace claves inválidas, caracteres de control, valores sobredimensionados y conflictos por duplicados. Conserve un resumen (digest) de la solicitud, no el encabezado confidencial.
3. Propague una lista de permitidos dentro de un mismo dominio de confianza. Entre diferentes dominios, envíe únicamente claves públicas minimizadas, o un alias de inquilino irreversible o una referencia firmada de corta duración.
4. Agregue filtrado explícito en los puntos de inyección de OpenTelemetry para que la instrumentación automática no pueda copiar cada elemento de Baggage en spans, registros o atributos de métricas.
5. Limite el total de bytes, el recuento de elementos y el recuento de saltos (hops). En caso de desbordamiento, elimine los campos de baja prioridad y emita un evento de política interno sin reflejar datos confidenciales.
6. Reevalúe la política en cada salida; reutilice el catálogo para colas y tareas asíncronas. Nunca utilice Baggage como una credencial de autorización.
7. Audite el nombre del campo, la versión de la política, la acción y el destino, no el valor original. Pruebe fugas sintéticas, ataques por tamaño y acumulación en múltiples saltos.

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

Ejemplo de respuesta de alta calidad

Comenzaría afirmando que Baggage no es un portador de autenticación ni de autorización; cada valor es no confiable. Un catálogo de campos versionado rige el análisis y los límites en el ingreso, y las listas de permitidos gobiernan la propagación dentro del mismo dominio. Entre límites de confianza, envíe solo un alias minimizado o una referencia de corta duración. Maneje el contexto de traza de OpenTelemetry por separado, filtre la inyección automática y nunca registre valores sin procesar. Ante un desbordamiento o una política desconocida, descarte los campos opcionales, continúe con la solicitud principal y registre el nombre del campo, la acción y la versión de la política. Pruebas sintéticas de múltiples saltos, pruebas en límites de colas y consultas de auditoría verifican que el riesgo de privacidad se reduzca sin ocultarlo detrás de una traza en buen estado.

Errores comunes

• Tratar a Baggage como identidad confiable, autorización o aislamiento de inquilinos.
• Permitir claves arbitrarias a través de los límites de confianza o depender únicamente de una lista negra (blacklist) de cadenas.
• Escribir el encabezado completo en registros, trazas o respuestas de error.
• Gobernar HTTP pero olvidar las colas, los reintentos y las tareas asíncronas.
• Devolver un 4xx por un desbordamiento opcional, o descartar datos silenciosamente sin un evento de auditoría.

Preguntas de seguimiento y respuestas

¿Cuál es la diferencia entre Baggage y Trace Context?

Trace Context transporta metadatos estándar necesarios para el rastreo distribuido. Baggage es un conjunto de clave-valor definido por la aplicación que puede funcionar de manera independiente, por lo que su semántica y riesgos de privacidad pertenecen a la aplicación.

¿Por qué preferir una lista de permitidos (allowlist) sobre una lista negra (blacklist)?

Las claves de Baggage no tienen una semántica de negocio fija y con el tiempo aparecen nuevos campos. Una lista de permitidos rechaza datos desconocidos por defecto, evitando que un nuevo servicio o proveedor propague accidentalmente un valor confidencial.

¿Debería una falla de filtrado bloquear la solicitud?

Si el campo es solo de observación, descártelo y continúe. Si un flujo de negocio lo requiere, devuelva un error de política reconocible sin reflejar el valor. El catálogo debe marcar qué campos son críticos.

¿Cómo demuestra que los valores sin procesar no ingresan a la telemetría?

Ejecute pruebas de redacción tanto en el Collector como en el SDK, escanee registros, atributos de span y etiquetas de métricas, registre nombres y versiones de políticas en lugar de valores, y active alertas sobre canarios sintéticos.