SonarQube Prometheus and authentication

SonarQube Server / Community Build
1

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:

2

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)

3

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).

6

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

8

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.

9

Hi @leo.geoffroy thanks for opening the ticket.
In my opinion the direction of the ticket is a bit reversed:

  • Please make at least the liveness (1) and readiness (2) endpoints accessible without any authentication.
  • You do not need to expose any information in the body, a 20x response is sufficient and indicates:
    1. whether the Java process itself does “live” resp.
    2. the service is ready/able to handle requests and should now answer “real” requests of users.
  • As said, you can achieve a liveness check by accessing the homepage of SonarQube and if any HTML is rendered, it is alive. And if you see a login box and not a starting up message it is ready. Parsing HTML is cumbersome.

(BTW: we run an 10 million lines enterprise edition but without support)