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
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/system/liveness (internal)
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).
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.