yurishkuro
commented
1 year ago Option 3 doesn't make sense to me, because for sidecar plugin we're starting a binary so it's natural to give it config, but with grpc remote storage we're just a gRPC client, there's no special handshake to pass the config
Option 2 in the query service is used for response headers (flag could be named better).
Option 1 seems consistent with Prometheus: +1
Requirement
As a Jaeger user I want to be able to configure an auth token for the SAAS based remote storage backends So that I can test and deploy Jaeger without the need to configure a reverse proxy on my side
Problem
There is no way to configure an auth token (or any other means of authorization) when using a remote storage GRPC plugin model. For SAAS storage backends that represents an issue, as there can be potentially thousands of customers connecting to the same endpoint. All of them would like to access their own data, and prevent anyone else from accessing their data.
Configuring reverse proxies on the side of the SAAS offering is not scalable. Forcing customers to configure reverse proxies on their side is not very user friendly, and complicates development, testing & deployment.
Using an auth token forwarding by the query service complicates testing (jaeger-all-in-one does not provide means to configure this token), and does not allow to write spans into the storage.
Proposal
Approach 1: Implement
gprc-storage.token-filelike it is implemented for Prometheus (--prometheus.token-file) and Elastic Search (--es.token-fileand--es-archive.token-file). Approach 2: Implementgrpc-storage.additional-headerslike it is implemented for Query service (--query.additional-headers) Approach 3: Implement forwarding a config to GRPC remote storage backend (maybe in the form of GRPC headers), like it is implemented for the sidecar mode GRPC plugins (--grpc-storage-plugin.configuration-file)Approaches 2 & 3 are more complex, but would allow for better customization & integration with remote backends.
Open questions
No response