Gitlab::HTTP should forward labkit context fields
Problem
With labkit-ruby, we allow collecting request context data that can be logged out and transmitted over HTTP via a header field. This allows us to correlate requests spanning more than one system.
Right now, labkit context does not propagate across services automatically. We serialize the context into a header here in labkit, which will makes it available (but not yet used) for enriching other system logs.
However, this does not affect any requests made through GitLab::HTTP
, so we should include those headers into outgoing requests. Then we can have the middleware in labkit-ruby inflate that context from the request headers.
This would allow us to correlate requests that gitlab-rails makes to CustomersDot.
Constraints
- We should exercise
privacy by design
- Context data from self-managed instances must be stripped free of potential PII (perhaps only forward
correlation_id
to begin with). It is likely safer to choose an allow-list approach for which fields to include. - Context data must never be sent to 3P services. We should inspect e.g. the TLD to ensure that GitLab context is only forwarded to services operated by GitLab.
Edited by Matthias Käppler