Closed vin01 closed 1 year ago
Thanks for the PR, I'll try to have a look at it in the coming days.
It can be risky to allow accessing values of keys from monitoring systems. A secure default and an option to explicitly enable value extraction would be safer.
That's true but IMO it falls outside the scope of the redis_exporter. It's up to the operator to set up the system in a secure way. I agree with you that a more sensible default could have been chosen. But backwards compatibility is a big issue and I don't want to change this lightly.
Fair enough, how about keeping it backwards compatible but making the option available so it can be configured to avoid exposure of keys and values? I can update the tests and default to reflect that.
Since exporters mostly run standalone and not behind reverse proxies, filtering these out would be not trivial if it needs to be done outside the exporter itself.
Hi, Thanks for this handy exporter.
I noticed that using
/scrape
andcheck-keys
GET parameter, it is possible to extract keys' values allowing monitoring systems to extract actual content instead of just metrics.It can be risky to allow accessing values of keys from monitoring systems. A secure default and an option to explicitly enable value extraction would be safer.
it is a breaking change though for people using this feature but I am not sure if keeping the insecure default would be a wise choice. wdyt?