Skip to content

v1.0.0-alpha-317

@ignis-celestis ignis-celestis tagged this 29 Jul 11:23
A trace could say an endpoint was slow but never who it was slow for, so a complaint from one
customer could only be investigated by guessing from route and timing. IdentityTracingMiddleware
stamps user.id and tenant.id onto the span the HTTP middleware already opened, which turns "show me
everything this account did" into a filter.

It sits at 675 — inside AuthMiddleware (700) and TenantContextMiddleware (680) — because the span is
opened before authentication runs, so the identity is not knowable when the span starts. Anonymous
requests are left unstamped rather than tagged "anonymous": the absence says it, and a constant
value would only add noise. The tenant is recorded even without a user, because public applicant
pages are still scoped to an organisation and that is exactly when it matters.

Opaque identifiers only. A user id is inert without this application's database; an email is not,
and it would be leaving our infrastructure for a third-party store. That distinction is the whole
design, and a test asserts the span carries those two keys and nothing else.

The collector now scrubs the traces pipeline as a backstop. Spans carry identifiers deliberately
and arbitrary attributes incidentally, so the same secret and PII shapes already barred from logs —
JWTs, bearer tokens, AWS keys, card numbers, email addresses — are stripped before anything leaves
the host. That is what makes attaching an identifier a bounded decision rather than an open-ended
one: the ids we chose survive, the shapes we never want do not.

None of this belongs in metrics and it deliberately stays out. A span attribute is a field on one
event; a metric label is a new time series per distinct value, so a user id there means one series
per user and an unusable metrics store. The cardinality deny-list stands.

TracingMiddleware::SPAN_ATTRIBUTE becomes public, since enrichment necessarily happens downstream of
the middleware that opens the span.

NoPlaintextSecretInArtifactTest needed tightening rather than relaxing: it scanned the whole
rendered config for "AKIA" and "Bearer", which a redaction processor legitimately contains as the
patterns it blocks. It now excludes the redaction processors and scans everything else, with a
second test asserting nothing but a redaction processor can claim that exemption.

Split from 382da9f27c49b02083f2841cebf6cd3d87e3c09f
Assets 2
Loading