How to finalize the request context propagation through the persistent queue

[dmitryax]

Several recent PRs (#13188, #13220, #13232) introduced the ability to store parts of the request context in the persistent queue.

One part of the context that is still not persisted is client.Auth, an interface implemented by various auth extensions.

It's unclear how we should proceed. Implementing plain Marshal/Unmarshal interfaces on the extension side isn't sufficient, since the payload could contain sensitive information that should not be written to disk in plaintext.

If we decide to support persisting Auth information, the Collector needs to ensure exclusive access to the data. This likely means using symmetric encryption with a configurable key. The open questions are:

• Where should the encryption key be configured?
  • The auth extension seems like the most natural place.
  • Alternatively, the exporter configuration could own it. Especially if the encryption will applied more broadly to client metadata. However, the mashaling/unmarshaling of the client metadata could also be managed by the header setter extension.

If we don't go down this path, we may need to explicitly document that auth extensions are incompatible with persistent queues.

[bogdandrutu]

Shouldn’t be the responsibility of the storage extension to store data encrypted if needed?

[dmitryax]

All the storage extensions we have in contrib don't provide any additional layer of encryption beyond what’s offered by the underlying storage. The underlying storage encryption is probably not enough, since it doesn’t guarantee exclusive access to the data — any storage client could potentially read it.

We could document that if users want to preserve auth data, they must ensure the collector has exclusive access to the underlying storage. In that case, we’d still probably want to make auth data serialization configurable — maybe disabled by default for the persistent queue, and enabled for the in-memory queue?