We are setting up a new SQ instance that will be exposed on Internet, and we would like to have a first authentication in front of SQ webapp, to protect it in case of a vulnerability.
Cloudflare Access is a nice solution for this that we already use for other sites, it acts as an auth proxy with SSO in front of the site to protect.
It works well for users, but we need to allow access for the Sonar scanners that will run in our CI/CD pipelines.
I had considered authorizing the IP ranges of the runners of our devops platforms, but the IP ranges from Github runners is endless, with millions of IPs to whitelist, it is not exploitable.
It would therefore be necessary to go for another form of authentication. I had thought of passing a specific http header to be able to authenticate the sonar scanners with Cloudflare, but it seems this is not supported by the scanners. This question remained unanswered: node.js - Adding extra headers in sonarqube webhook - Stack Overflow
Other options would be to use cloudflared to create a tunnel between the sonar scanner and Cloudflare but it’s a bit complex and probably require at least the scanner to run inside a specific Docker image.
Do you have any suggestion about how we could achieve this?
Thanks Colin, this is definitely interesting. The ticket raised by Ken is completely aligned with my need.
SONAR_SCANNER_OPTS could indeed be an option to pass the required parameters but the ones related to http proxy that you shared won’t cover our need (http proxy is used to provide access to internet from private network).
Such parameter could work though:
This would be quite straightforward to implement, adding specific headers in http client framework is a 1 liner. i can open a PR if the source code is available (did not check).
You’re welcome to raise a PR – however keep this in mind:
Please be aware that we are not actively looking for feature contributions. The truth is that it’s extremely difficult for someone outside SonarSource to comply with our roadmap and expectations. Therefore, we typically only accept minor cosmetic changes and typo fixes.
With that in mind, if you would like to submit a code contribution, please create a pull request for this repository. Please explain your motives to contribute this change: what problem you are trying to fix, what improvement you are trying to make.
And, we’ve seen some more technical PRs accepted lately, so I don’t want to discourage you.
Colin - We would really like to see this functionality, I’d be willing to open a PR, but I can see a few possible ways to approach this, and I would like to avoid opening a PR that would directly be rejected.
I am unable to follow the process documented here Contributing to SonarQube to open a Jira ticket, as it appears that people outside of SonarSource no longer have access to view/create tickets.
What is the appropriate way to collaborate with the SS team to align on an approach before opening a PR?
We didn’t use one of the existing marketplace actions that run SonarQube because those were running inside a container in which case the first step had no effect when running inside container. That’s why the 2 custom GH actions were composite eunning directly in tha bash shell of the coresponding runner
More on custom GH actions and the types of them here