Azure DevOps (VSTS) build pipeline is failing to communicate with SonarQube. This started occurring without making any changes on our end Q4 last year.
Details:
Both build agent and SonarQube server are on-prem. No firewall or proxy between.
SonarQube IIS app config has only anonymous enabled and no authorization limitations.
SonarQube configured to run as a Windows service.
No IIS logs indicating denial can be found.
Issue occurred with SonarQube 6.7.1 and 7.5.
VSTS build step is “Prepare Analysis Configuration” version 4.5.1.
Version URL is accessible by me directly with no issue.
Error received is:
2019-01-17T20:38:09.1064192Z ##[section]Starting: Prepare analysis on SonarQube
2019-01-17T20:38:09.1068110Z ==============================================================================
2019-01-17T20:38:09.1068190Z Task : Prepare Analysis Configuration
2019-01-17T20:38:09.1068260Z Description : Prepare SonarQube analysis configuration
2019-01-17T20:38:09.1068315Z Version : 4.5.1
2019-01-17T20:38:09.1068379Z Author : sonarsource
2019-01-17T20:38:09.1068440Z Help : [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
2019-01-17T20:38:09.1068533Z ==============================================================================
2019-01-17T20:38:09.9368581Z ##[error][SQ] API GET '/api/server/version' failed, status code was: 403
2019-01-17T20:38:09.9453548Z ##[section]Finishing: Prepare analysis on SonarQube
Error occurs every build, so all SonarQube analysis is failing. For now we’re just ignoring errors in these build steps.
IIRC this is one of the first things that happens in analysis & it’s a very basic call. Did permissions on your SonarQube server change? If you’re analyzing with a token, are you sure it hasn’t been revoked?
Turns out the VSTS build process was trying to route through the proxy for this call, instead of calling the internal service directly. I had to add the internal SonarQube URL to the NO_PROXY environment variable, which then short-circuited the proxy detection logic.
I don’t think that we changed anything on that side, but let’s troubleshoot.
When you are speaking about the User Agent, which kind of call are you making ? With a curl ? Postman ? Fiddler ? Directly against your SQ instance or through a service ?
Yeah, I figured out that it’s not related to the update.
We configured Amazon WAF and some of its managed rules block HTTP requests without User-Agent header.
I am doing tests to find out what exactly rules block requests without User-Agent.
PS: I use Postman to do HTTP requests
PPS: OK, after a quick tests I found that the next 2 rule sets block HTTP requests without User-Agent header:
Anonymous IP list - AWS-AWSManagedRulesAnonymousIpList, 50 rules - This group contains rules that allow you to block requests from services that allow obfuscation of viewer identity. This can include request originating from VPN, proxies, Tor nodes, and hosting providers. This is useful if you want to filter out viewers that may be trying to hide their identity from your application.
Core rule set - AWS-AWSManagedRulesCommonRuleSet,700 rules - Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications.
I would like to enable these rule sets. Would you be able to add User-Agent header in the next releases of SonarQube extension for Azure DevOps Services, @mickaelcaro ?
