Open Sayrus opened 4 years ago
Oy yep, looks like that's a thing. Should be addable to the RemoteWriteSpec and RemoteReadSpec objects. /me sighs in "HTTP has features for this but of course no one uses them".
We also have basic auth settings exposed as native fields. We have precedence in TLS configuration for referencing secrets, but I agree we should think about protecting more fields.
Note that it would still be exposed in clear in the Prometheus configuration (from the /config
and /api/v1/status/config
endpoints).
New Relic has already been told that passing the license key in the URL isn't a good practice.
I absolutely understand the issue with passing it in the URL. My issue was mainly that I have to write cleartext secrets in Git. However, I totally forgot that you could retrieve the configuration using the API endpoint.
While adding RBAC / Proxy blacklist to prevent config from being retrieving might work (Perhaps there are side effects which would be even harder to handle), it sounds like an overly complicated solution to a simple problem.
I will send them a feature request for bearer token or basic auth.
If they refuse to implement it properly, I'd still be interested in having the URL as a secret.
Edit: @simonpasquier I just thought that you made a fair point and even linked to a previous discussion that involved NR. Sorry if my answer was sounding aggressive, that was not my intention ! Thanks for your intervention.
@Sayrus thanks! I wasn't trying to dismiss your feature request but provide more context :-)
What is missing?
When configuring a Remote Write Endpoint, the URL itself cannot be configured from a secret.
Why do we need it?
Some providers (such as New Relic to name one) uses the Remote Write feature with an API key in a GET parameter. I'd like to be able to treat this API key (and therefore, the whole URL) as a secret and avoid having it in cleartext in the repository.
The URL looks like
https://mywebsite.com/write?API_KEY=<key>
.Environment
Anything else we need to know?: --