Repository navigation
SC-60373 Use WIF to authenticate SonarQube Cloud scans in build actions - #363
aurelien-poscia-sonarsource wants to merge 4 commits into
Conversation
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
| - uses: SonarSource/sonarqube-auth-action@0c409727662aa45022382faba75676ae449788ad # v1 | ||
| id: sqc-eu-auth | ||
| if: inputs.run-shadow-scans == 'true' || inputs.sonar-platform == 'sqc-eu' | ||
| with: | ||
| sonar-host-url: https://sonarcloud.io | ||
| export-env: 'false' | ||
| - uses: SonarSource/sonarqube-auth-action@0c409727662aa45022382faba75676ae449788ad # v1 | ||
| id: sqc-us-auth | ||
| if: inputs.run-shadow-scans == 'true' || inputs.sonar-platform == 'sqc-us' | ||
| with: | ||
| sonar-host-url: https://sonarqube.us | ||
| export-env: 'false' |
There was a problem hiding this comment.
💡 Cross-Repo: sonar-dummy-python-oss on build-poetry@master switches to WIF on merge
Fix here and in SonarSource/sonar-dummy-python-oss
Breaks in: SonarSource/sonar-dummy-python-oss - .github/workflows/build.yml - Build job (SonarSource/ci-github-actions/build-poetry@master, sonar-platform: sqc-eu)
SonarSource/sonar-dummy-python-oss calls SonarSource/ci-github-actions/build-poetry@master in two workflows: .github/workflows/build.yml with sonar-platform: sqc-eu, and unified-dogfooding.yml with run-shadow-scans: true. Once this PR merges to master, those jobs stop reading the sonarcloud and sonarqube-us Vault tokens. They run sonarqube-auth-action for EU, and for shadow scans for US as well, and there is no Vault fallback. The 3.0.0 versioning does not protect these jobs, because they pin @master. Each job then fails at the token exchange unless the repository is bound to a SonarQube Cloud project on every analyzed platform (both EU and US for the shadow-scan workflow) with trusted scanning enabled, and the analysis finishes within the 30-minute token life. The break is intended. The consumer has to be ready before merge.
Here: Before merging to master, confirm that the dogfood repositories on @master (including sonar-dummy-python-oss) are bound and have trusted scanning enabled on sqc-eu and sqc-us. Alternatively, ship the change on a beta/3.x branch first, as the test plan suggests, and add a migration note for @master consumers.
There: In SonarSource/sonar-dummy-python-oss, bind the repository to SonarQube Cloud projects on both sqc-eu and sqc-us (shadow scans need both), enable trusted scanning, and keep id-token: write on the build.yml and unified-dogfooding.yml jobs. Also check that sonar.organization/sonar.projectKey match the bound projects.
Was this helpful? React with 👍 / 👎
The two sonarqube-auth-action steps were duplicated in the five build-* actions. They now live in shared/sonar-auth, so the SHA pin and the conditions are maintained in one place. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Use the shared platform list in the poetry shadow scan loop, and state in the README that check-sca still reads the SonarQube Cloud Vault secrets. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
| development/kv/data/sign key | SIGN_KEY; | ||
| development/kv/data/sign passphrase | PGP_PASSPHRASE; | ||
| # yamllint enable rule:line-length | ||
| # The SonarQube Cloud tokens expire after 30 minutes: keep this step right before the build step. |
There was a problem hiding this comment.
Is it enough for long-running builds? Is the token used at the beginning and/or at the end of the Maven build?
There was a problem hiding this comment.
The token fetch happens before the maven build is started, by design. The goal of modifying this action is to be able to dogfood the public sonarqube-auth-action at scale.
So we have two options:
- We have a custom implem here to fetch the token differently and not use the
sonarqube-auth-action - On the adopters of this action, only sonarqube build exceeded 30 minutes twice out of the recorded 25 runs.
I would rather adopt a specific solution for sonarqube, and let all other projects use the public sonarqube-auth-action
There was a problem hiding this comment.
IMO this is a major design flaw of those shared actions (and to be honest, of our Maven/Gradle scanners). We should have isolated the Sonar analysis from the build of the project.
This is what I am trying to do on some projects, like here:
https://github.com/SonarSource/sonar-scanner-engine/actions/runs/39807148955
This is especially true if the build takes longer than 30 min, we should extract it, run tests in parallel jobs, and only run the SQ analysis in a downstream job.
| next) : "${NEXT_URL:?}" "${NEXT_TOKEN:?}" ;; | ||
| sqc-us) : "${SQC_US_URL:?}" "${SQC_US_TOKEN:?}" ;; | ||
| sqc-eu) : "${SQC_EU_URL:?}" "${SQC_EU_TOKEN:?}" ;; | ||
| *) ;; |
There was a problem hiding this comment.
require_sonar_env ignores unknown platforms (silent no-op)
A typo like sonar-platform: sqc_eu would run no auth step and no check, so it would only fail later. The old code had the same weakness, so it's optional and also fine as it is.
sonarqube-auth-action replaced the sonar-host-url input and output with sonar-region. The shared sonar-auth action now only provides the tokens, and the build actions read the SonarQube Cloud URLs from Vault again. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
| The `build-*` actions authenticate to SonarQube Cloud (`sonar-platform: sqc-eu` or `sqc-us`, and the matching platforms of | ||
| `run-shadow-scans`) with the GitHub OIDC token of the job, through | ||
| [`sonarqube-auth-action`](https://github.com/SonarSource/sonarqube-auth-action), instead of with tokens stored in Vault. | ||
| The SonarQube Cloud URLs, and the URL and token of the `next` platform, are still read from Vault. |
There was a problem hiding this comment.
💡 Quality: README still says build-* no longer read the SQC Vault secrets
This commit makes every build-* action read development/kv/data/sonarcloud url and development/kv/data/sonarqube-us url from Vault again, for example in build-gradle/action.yml:147-148. Line 100 of the README was updated to say so. Lines 115-116 were left unchanged and still say the build-* actions "do not read the secrets development/kv/data/sonarcloud and development/kv/data/sonarqube-us anymore" and that only check-sca still uses them. An operator who follows that paragraph could conclude that these secrets can be revoked once check-sca migrates. Doing that would leave SQC_EU_URL/SQC_US_URL empty and break every SQC scan in the build actions. Fix: reword lines 115-116 to say that only the token fields of those secrets are no longer read by build-*, and that the url fields are still required.
Clarify that only the token fields stopped being read:
The `build-*` actions do not read the `token` fields of the secrets `development/kv/data/sonarcloud` and
`development/kv/data/sonarqube-us` anymore, but still read their `url` fields. The tokens are still used by
[`check-sca`](#check-sca), so these secrets must not be revoked yet.
- Apply fix
Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎
| ${{ (inputs.sonar-platform != 'none' || inputs.run-shadow-scans == 'true') && 'development/kv/data/sonarqube-us url | SQC_US_URL;' || '' }} | ||
| ${{ (inputs.sonar-platform != 'none' || inputs.run-shadow-scans == 'true') && 'development/kv/data/sonarqube-us token | SQC_US_TOKEN;' || '' }} | ||
| ${{ (inputs.sonar-platform != 'none' || inputs.run-shadow-scans == 'true') && 'development/kv/data/sonarcloud url | SQC_EU_URL;' || '' }} |
There was a problem hiding this comment.
⚠️ Cross-Repo: sonar-dummy-gradle-oss shadow scans on @master will need WIF on EU and US
Fix here and in SonarSource/sonar-dummy-gradle-oss
Breaks in: SonarSource/sonar-dummy-gradle-oss - .github/workflows/unified-dogfooding.yml - Build and run shadow scans job (build-gradle@master, run-shadow-scans: true)
SonarSource/sonar-dummy-gradle-oss calls SonarSource/ci-github-actions/build-gradle@master with run-shadow-scans: true in .github/workflows/unified-dogfooding.yml (the "Build and run shadow scans" job). After this PR, build-gradle/action.yml reads only the SonarQube Cloud URLs from Vault (lines 147-148). The SQC_EU_TOKEN/SQC_US_TOKEN values come only from shared/sonar-auth, which runs sonarqube-auth-action for both EU and US whenever shadow scans are on, and there is no Vault fallback. The job pins @master, so the 3.0.0 versioning does not shield it. Once this merges, the job fails at the token exchange unless three things hold: the repository is bound to SonarQube Cloud projects on both sqc-eu and sqc-us with trusted scanning enabled, the job has id-token: write, and the build plus analysis finishes within the 30-minute token lifetime. The PR intends this break, so the consumer has to be ready before merge.
Here: Before merging to master, confirm that sonar-dummy-gradle-oss (and the other @master dogfood repos) is bound and has trusted scanning enabled on both sqc-eu and sqc-us. Otherwise, ship this on a 3.x/beta branch first and add a migration note in the README for @master consumers.
There: In SonarSource/sonar-dummy-gradle-oss, bind the repository to SonarQube Cloud projects on sqc-eu and sqc-us and enable trusted scanning. Add id-token: write to the shadow-scan job in .github/workflows/unified-dogfooding.yml, and make sure sonar.organization/sonar.projectKey match the bound projects.
In SonarSource/sonar-dummy-gradle-oss - .github/workflows/unified-dogfooding.yml:
permissions:
id-token: write
contents: write
Was this helpful? React with 👍 / 👎
Code Review
|
| Auto-apply | Compact | Unblock |
|
|
|
Was this helpful? React with 👍 / 👎 | Gitar
Summary
SC-60373, part of SC-50795.
build-gradle,build-maven,build-npm,build-poetryandbuild-yarnnow authenticate to SonarQube Cloud (sqc-eu,sqc-us) with the GitHub OIDC token of the job, throughsonarqube-auth-action, instead of the sharedsonarcloudandsonarqube-usVault tokens. SonarQube Next still reads its token from Vault.This is a breaking change, to be released as
3.0.0. There is no fallback to Vault: upgrading means WIF.Changes
shared/sonar-auth(new, internal) andbuild-*/action.yml: each build action callsshared/sonar-authright before the build step. It runs twosonarqube-auth-actionsteps (EU and US), only for the analyzed platforms, withexport-env: falseand nocontinue-on-error.SQC_EU_*andSQC_US_*come from its outputs. The SHA pin and the conditions live in one place. The four Vault lines forsonarcloudandsonarqube-usare removed, and thenextsecrets are only fetched whennextis analyzed.shared/common-functions.sh,build-*/build.sh: the check that required all sixNEXT_*andSQC_*variables is replaced byrequire_sonar_env, which only requires the variables of the platforms that are analyzed. Without it,sonar-platform: sqc-euorsqc-uswould fail because the other platform is skipped.README.md: new "SonarQube Cloud authentication" section, linked from eachbuild-*section.Requirements for consumers
id-token: writeon the job (already needed for Vault).sonar.projectKeyandsonar.organizationmatch the bound project.build-*step has a median of 2.4 minutes and a p99 of 18.7 minutes. Thesonarquberepository is the only one above 30 minutes, and its build is being shortened separately.Merge prerequisites
Merging changes
@masteronly:@v1(283 usages),@v2(146) and SHA-pinned (36) consumers are unaffected until a new tag is cut. Six repositories callbuild-*@masterand will switch to WIF on merge, with no fallback to Vault. They are thesonar-dummytest repositories, one per build action:sonar-dummybuild-mavensonar-dummy-maven-enterprisebuild-mavensonar-dummy-gradle-ossbuild-gradlesonar-dummy-jsbuild-npmsonar-dummy-yarnbuild-yarnsonar-dummy-python-ossbuild-poetryBefore merging, each one needs
id-token: writeon its jobs, a binding to a SonarQube Cloud project on every platform it scans (EU and US for shadow scans), trusted scanning enabled in the organization, andsonar.projectKey/sonar.organizationmatching the bound project.Test plan
require_sonar_env, and they fail when the helper requires every platform.action.ymlfiles validate against the GitHub Actions schema.update-release-channel_spec.sh, which fails the same way onmaster(check-jsonschemamissing locally).sqc-eusingle-platform: sonar-scanner-integration-tester#95@masterrepositories above.sonarqube-auth-actionrelease and update the pinned SHA (currently the commitv1points to).3.0.0.🤖 Generated with Claude Code