SonarQube Prometheus and authentication

Hi,

I know there was a similar question but with 9.5 SonarQube now offers an internal solution and I have some questions:

  • We run 9.5.
  • We use prometheus and all other endpoints we scrape are not authenticated.
  • Even access to our prometheus UI is not authenticated as it is only reachable inhouse.
  • It seems for SonarQube only project keys are “leaked” which are known to our users anyways.
  • If I understand it correctly, I need to pass an system admin credential for scraping the information from SonarQube.
  • Now prometheus shows its config as well.
  • So I would expose an SonarQube admin credential, so I need to switch to authentication in prometheus etc.
  • This is IMO unfortunate.
  • And: I consider it an anti-pattern to expose these relatively insensitive prometheus metrics using such a strong credential.
  • I see there is the option to set sonar.web.systemPasscode in the properties file. Is this systemPasscode used for something else as well? Does it allow general admin access?
  • Could you maybe use another secret for exposing prometheus metrics?

Thanks for your answers :slight_smile:

Hey there.

sonar.web.systemPasscode is only supported for specific Web APIs, so it is safer to use than admin credentials. Those Web APIs are (as of 9.5) the following:

GET api/ce/info (internal)
GET api/ce/pause (internal)
GET api/ce/resume (internal)
GET api/monitoring/metrics
GET api/system/health
GET api/system/liveness (internal)

Hi Colin,

thanks for your quick answer. So using systemPasscode looks more reasonable. However I would really appreciate if stuff like prometheus or liveness would get an other permission scope. Pausing the CE could be too much.

I mean, liveness in Kubernetes is about process is running (functional up and so instance is really able to handle traffic would be readiness). Therefore returning a 401 or 403 is for most systems sufficient for a liveness check (we run thirdparty systems where we use a 403 for liveness).

Hello Mirko,

Thank you for the feedback, I think it would make sense that the monitoring applications should not have access to system functions such as pausing or resuming the compute engine.

I have created a ticket to investigate how we could differentiate those accesses

Thanks @leo.geoffroy, and I would definitely think about opening the liveness check completely.
As I said: Kubernetes is even fine with an empty response so you just state that the servlet engine is reacting so you could use any path in SonarQube for liveness checks anyways.