Security in Prometheus exporter

[fmhwong]

What are you trying to achieve?
In the current spec for the Prometheus exporter https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/prometheus.md, it doesn't mention anything about securing the metrics endpoint.

When using the automatic instrumentation opentelemetry-javaagent.jar and the Prometheus exporter is enabled, the metrics endpoint (e.g. http://localhost:9464/) is not protected.

What did you expect to see?
There should be an option to use https and have the metrics endpoint protected by

• username/password
• OpenShift service account token

Additional context.

Add any other context about the problem here. If you followed an existing documentation, please share the link to it.

[sandeepsharat]

Under which version is this feature released?...

[dyladan]

@sandeepsharat it is no released. This is a feature request

[mtwo]

Chiming in during triage - this seems very useful. Tagging @open-telemetry/wg-prometheus for their comments.

[dashpole]

This is a good idea, but might only apply to auto-instrumentation. From looking at manual instrumentation in a few languages, it looks like most allow you to either replace the HTTP handler, serve the endpoint using the prometheus client library, or require you to serve the http endpoint yourself.

[trask]

This is a good idea, but might only apply to auto-instrumentation. From looking at manual instrumentation in a few languages, it looks like most allow you to either replace the HTTP handler, serve the endpoint using the prometheus client library, or require you to serve the http endpoint yourself.

@dashpole do you think there's something we should add to the spec to support this, or should people open issues directly with various implementations to support it? thanks

[dashpole]

@dashpole do you think there's something we should add to the spec to support this, or should people open issues directly with various implementations to support it? thanks

I would recommend people open issues directly with implementations, since most prometheus exporters don't directly configure the endpoint. I'm generally a in favor of using prometheus client libraries (which is recommended by the current spec) for serving, and think any additional capabilities around securing the endpoint probably belongs in prometheus clients, rather than in OTel. For things like auto-instrumentation, where we configure the endpoint, we should try and "pass through" configuration to prometheus client libraries as much as possible, rather than re-invent the wheel, and try to direct people to the prometheus clients if there are feature gaps.

[trask]

Thanks, makes sense, let's try this and people can loop back here as needed.