Skip to content

BUILD-12911: Resolve Prod Edge reader tokens through production Vault - #357

Merged
bwalsh434 merged 2 commits into
masterfrom
feat/bwalsh/BUILD-12911-centralize-edge-token-issuance
Oct 9, 2026
Merged

bwalsh434 merged 2 commits into
masterfrom
feat/bwalsh/BUILD-12911-centralize-edge-token-issuance

Conversation

@bwalsh434

@bwalsh434 bwalsh434 commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

BUILD-12911: Issue production Edge reader credentials through production Vault while preserving existing dev Edge authentication.

Previously every non-jfrog.io resolve URL requested tokens from dev Vault's artifactory-edge-dev, including production Edge URLs. The eight reader credential steps now select the matching Vault server and engine:

  • SaaS resolves through development/artifactory on https://vault.sonar.build.
  • Dev Edge resolves through the existing development/artifactory-edge-dev on https://vault.dev.sonar.build.
  • Production Edge resolves through development/artifactory-edge-prod on https://vault.sonar.build.
  • Preserve visibility-based reader defaults and custom reader-role suffixes.
  • Preserve SaaS deployment, promotion and build-info credential paths and destinations.
  • Preserve the current dev Edge URL and token routing for existing consumers; bootstrap or rotation of the dev Vault engine is not part of this rollout.
  • Advertise only the production Edge endpoint in action descriptions and the README; retain dev routing for existing consumers and keep bootstrap details in this PR.

Rollout prerequisites

Repositories using SonarSource Orchestrator integration tests must first use an Orchestrator release that recognizes repox-internal.sonar.build as an authenticated SonarSource Artifactory host. Its current default-branch ArtifactoryFactory recognizes only SaaS and dev Edge, so switching such repositories now can select the unauthenticated Maven client and break private downloads or version alias resolution. The isolated sonarlint-core download experiment does not validate this Orchestrator behavior.

Keep this change unreleased until the production Edge engine on production Vault has been seeded with a production-Edge-issued admin token, rotated, activated and validated. Bootstrap only artifactory-edge-prod; do not seed the unwanted dev engine on production Vault or rotate the existing dev Vault credential.

https://github.com/SonarSource/re-terraform-aws-vault/pull/9762 removes the unused dev Edge mount from production Vault while retaining dev issuance on dev Vault. After bootstrap, merge that correction and verify its new post-merge production apply succeeds. Do not rerun the old activation commit, which still attempts to configure both Edge engines on production Vault.

Before release, compare a representative private-artifact dev CI run on its existing action version with a pilot using this PR's exact commit and the same dev Edge URL/reader role. Separately validate production Edge resolution, including cache hits and misses. Existing dev consumers retain their current URLs and action pins during the production pilot.

Test plan

  • Evaluate both credential paths in 144 routing cases using the GitHub Actions expression evaluator: eight actions, six SaaS/Edge URLs and three reader roles.
  • Pass 43 existing package configuration ShellSpec examples.
  • Pass applicable pre-commit hooks (including YAML and Markdown lint) and git diff --check.
  • Record a successful private-artifact dev Edge baseline with the current action pin, resolve URL, reader role and run link.
  • Pilot this PR's exact commit against dev Edge and confirm credentials still come from dev Vault's existing engine, with successful private resolution.
  • Validate authorized and denied unauthorized production reader issuance after bootstrap and production apply.
  • Confirm production private artifact cache hits and misses succeed; deployment, promotion and build-info publication still use SaaS.
  • Verify repox-url: https://repox.jfrog.io returns reads to SaaS.

Preparation and activation infrastructure changes are already merged:
https://github.com/SonarSource/re-terraform-aws-vault/pull/9759
https://github.com/SonarSource/re-terraform-aws-vault/pull/9760

Required correction before release:
https://github.com/SonarSource/re-terraform-aws-vault/pull/9762

Actual action validation

The isolated draft experiment SonarSource/sonarlint-core#2374 ran config-maven from this PR at f335f47fa10fc0ed2252014f81ca133c2e0a5b8e against both internal Edge URLs:
https://github.com/SonarSource/sonarlint-core/actions/runs/37980454381

Both jobs successfully obtained their private-reader credentials through the expected Vault server/engine (dev → dev Vault/artifactory-edge-dev; prod → production Vault/artifactory-edge-prod), exported the matching ARTIFACTORY_URL, downloaded the full private Developer ZIP (HTTP 200, 1,499,439,841 bytes), and repeated a ranged read (HTTP 206, 1,024 bytes). This exercises the actual config-maven action rather than the Vault wrapper alone. It does not prove Edge cache hit/miss classification, unauthorized-role denial, every package action, or Orchestrator support.

@hashicorp-vault-sonar-prod

hashicorp-vault-sonar-prod Bot commented Oct 6, 2026 •

Copy link
Copy Markdown

BUILD-12911

Comment thread README.md Outdated
@bwalsh434
bwalsh434 force-pushed the feat/bwalsh/BUILD-12911-centralize-edge-token-issuance branch from 72d8884 to 5e56c0b Compare October 6, 2026 18:04
@bwalsh434 bwalsh434 changed the title BUILD-12911: Resolve Edge reader tokens through production Vault [DO NOT MERGE] BUILD-12911: Resolve Edge reader tokens through production Vault Oct 6, 2026
@bwalsh434 bwalsh434 changed the title [DO NOT MERGE] BUILD-12911: Resolve Edge reader tokens through production Vault BUILD-12911: [DO NOT MERGE] Resolve Edge reader tokens through production Vault Oct 6, 2026
@bwalsh434 bwalsh434 changed the title BUILD-12911: [DO NOT MERGE] Resolve Edge reader tokens through production Vault [DO NOT MERGE] BUILD-12911: Resolve Edge reader tokens through production Vault Oct 6, 2026
@bwalsh434
bwalsh434 marked this pull request as ready for review October 6, 2026 19:47
@bwalsh434
bwalsh434 requested a review from a team as a code owner October 6, 2026 19:47
Comment thread build-gradle/action.yml Outdated
Comment thread README.md Outdated
@hedinasr

hedinasr commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

I pushed a commit that keeps *.dev.sonar.build resolves on dev Vault, since production Vault will only issue production Edge tokens (https://github.com/SonarSource/re-terraform-aws-vault/pull/9762).

Comment thread README.md Outdated
@bwalsh434 bwalsh434 changed the title [DO NOT MERGE] BUILD-12911: Resolve Edge reader tokens through production Vault [DO NOT MERGE] BUILD-12911: Resolve Prod Edge reader tokens through production Vault Oct 9, 2026
Production Vault issues only production Edge tokens. The dev Edge keeps its seeded artifactory-edge-dev engine on dev Vault.
@bwalsh434
bwalsh434 force-pushed the feat/bwalsh/BUILD-12911-centralize-edge-token-issuance branch from 29398f6 to f335f47 Compare October 9, 2026 19:14
@sonarqubecloud

sonarqubecloud Bot commented Oct 9, 2026

Copy link
Copy Markdown

Comment thread README.md
@bwalsh434
bwalsh434 merged commit c60fa5c into master Oct 9, 2026
24 checks passed
@bwalsh434
bwalsh434 deleted the feat/bwalsh/BUILD-12911-centralize-edge-token-issuance branch October 9, 2026 19:48
@bwalsh434 bwalsh434 changed the title [DO NOT MERGE] BUILD-12911: Resolve Prod Edge reader tokens through production Vault BUILD-12911: Resolve Prod Edge reader tokens through production Vault Oct 9, 2026
@gitar-bot

gitar-bot Bot commented Oct 14, 2026

Copy link
Copy Markdown
Code Review 👍 Approved with suggestions 2 closed / 3 findings

🔴 High risk · Changing Vault engines for Edge reader-token issuance could grant or deny private artifact access if endpoint routing selects the wrong credentials.

Routes the eight reader credential steps to the matching Vault for SaaS, dev Edge, and production Edge, while keeping dev Edge tokens on dev Vault and preserving SaaS deployment paths. Two resolved this session: the repox-url input descriptions and the README now match the dev-Vault split.

  • Open minor: orchestrator's ArtifactoryFactory.isSonarSourceArtifactory does not recognise repox-internal.sonar.build, so ITs against the production Edge would fall back to unauthenticated MavenArtifactory. Until an orchestrator release adds the host, note this in the README Edge section and the rollout prerequisites.
💡 Cross-Repo: Orchestrator doesn't recognise the new production Edge host

📄 README.md:73 📄 config-maven/action.yml

Fix here and in SonarSource/orchestrator

Breaks in: SonarSource/orchestrator - sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java - ArtifactoryFactory.isSonarSourceArtifactory

This PR tells consumers to set repox-url: https://repox-internal.sonar.build (README.md:73 and the repox-url descriptions). config-maven, like the other config actions, then exports ARTIFACTORY_URL=https://repox-internal.sonar.build/artifactory and ARTIFACTORY_ACCESS_TOKEN into GITHUB_ENV. Integration tests that run on SonarSource/orchestrator pick up that URL. But ArtifactoryFactory.isSonarSourceArtifactory in sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java only matches repox.jfrog.io and repox-internal.dev.sonar.build exactly. So orchestrator treats the production Edge as a plain Maven repository and uses the unauthenticated MavenArtifactory, with no token and no Artifactory version search. DEV/LATEST_RELEASE alias resolution and private artifact downloads would then fail for any pilot repo that runs orchestrator ITs against the production Edge.

Here: Until an orchestrator release recognises repox-internal.sonar.build, add a note to the README Edge section (and the rollout prerequisites) saying that repos running orchestrator-based ITs need that orchestrator version before switching repox-url to the production Edge.

There: In SonarSource/orchestrator, add repox-internal.sonar.build to the hosts that ArtifactoryFactory.isSonarSourceArtifactory recognises, so the production Edge uses the authenticated SonarSource Artifactory client. Release that version before the production Edge pilot.

In SonarSource/orchestrator - sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java:

private static final Set<String> SONARSOURCE_ARTIFACTORY_HOSTS = Set.of(
  "repox.jfrog.io",
  "repox-internal.dev.sonar.build",
  "repox-internal.sonar.build");
✅ 2 closed
✅ Quality: repox-url input descriptions still point only to the dev Edge

📄 build-yarn/action.yml 📄 config-gradle/action.yml 📄 config-maven/action.yml 📄 config-npm/action.yml 📄 config-nuget/action.yml 📄 config-pip/action.yml 📄 config-poetry/action.yml 📄 config-uv/action.yml 📄 README.md:72-74
The README now names https://repox-internal.sonar.build as the production JFrog Edge and lists https://repox-internal.dev.sonar.build separately as the dev Edge. The routing expression also now sends any non-.dev.sonar.build Edge URL to artifactory-edge-prod. But the repox-url input description in every config-* and build-* action.yml still says Use https://repox-internal.dev.sonar.build for the JFrog Edge.. Users who read the input metadata (for example, the Marketplace or IDE hints) are still pointed only at the dev Edge, which disagrees with the README this PR updated. Update the descriptions to name both endpoints.

✅ Quality: PR claims and README no longer match the dev-Vault split

📄 README.md:77-83 📄 build-yarn/action.yml:137
This commit moves dev Edge resolution back to https://vault.dev.sonar.build in all eight actions, for example the url: expression at build-yarn/action.yml:137. The PR description was not updated. It still says the eight reader steps "now use production Vault" for dev Edge too, and its rollout gate asks for both production Vault Edge engines to be seeded. The same commit also removed the README note about engine prerequisites, so the README no longer covers the one prerequisite that still applies: development/artifactory-edge-prod must be seeded on production Vault before anyone sets repox-url: https://repox-internal.sonar.build. The description still promises to "Document ... engine prerequisites". Fix: update the PR description to say only the production engine must be seeded, and add back a one-line README prerequisite for the production Edge engine.

🤖 Prompt for agents
Code Review: Routes the eight reader credential steps to the matching Vault for SaaS, dev Edge, and production Edge, while keeping dev Edge tokens on dev Vault and preserving SaaS deployment paths. Two resolved this session: the `repox-url` input descriptions and the README now match the dev-Vault split.
  
  - Open minor: orchestrator's `ArtifactoryFactory.isSonarSourceArtifactory` does not recognise `repox-internal.sonar.build`, so ITs against the production Edge would fall back to unauthenticated `MavenArtifactory`. Until an orchestrator release adds the host, note this in the README Edge section and the rollout prerequisites.

1. 💡 Cross-Repo: Orchestrator doesn't recognise the new production Edge host
   Files: README.md:73, config-maven/action.yml

   **Fix here and in [`SonarSource/orchestrator`](https://github.com/SonarSource/orchestrator)**
   
   **Breaks in:** [`SonarSource/orchestrator`](https://github.com/SonarSource/orchestrator) - [`sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java`](https://github.com/SonarSource/orchestrator/blob/HEAD/sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java) - `ArtifactoryFactory.isSonarSourceArtifactory`
   
   This PR tells consumers to set `repox-url: https://repox-internal.sonar.build` (README.md:73 and the `repox-url` descriptions). config-maven, like the other config actions, then exports `ARTIFACTORY_URL=https://repox-internal.sonar.build/artifactory` and `ARTIFACTORY_ACCESS_TOKEN` into `GITHUB_ENV`. Integration tests that run on SonarSource/orchestrator pick up that URL. But `ArtifactoryFactory.isSonarSourceArtifactory` in `sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java` only matches `repox.jfrog.io` and `repox-internal.dev.sonar.build` exactly. So orchestrator treats the production Edge as a plain Maven repository and uses the unauthenticated `MavenArtifactory`, with no token and no Artifactory version search. DEV/LATEST_RELEASE alias resolution and private artifact downloads would then fail for any pilot repo that runs orchestrator ITs against the production Edge.
   
   **Here:** Until an orchestrator release recognises `repox-internal.sonar.build`, add a note to the README Edge section (and the rollout prerequisites) saying that repos running orchestrator-based ITs need that orchestrator version before switching `repox-url` to the production Edge.
   
   **There:** In SonarSource/orchestrator, add `repox-internal.sonar.build` to the hosts that `ArtifactoryFactory.isSonarSourceArtifactory` recognises, so the production Edge uses the authenticated SonarSource Artifactory client. Release that version before the production Edge pilot.
   
   In SonarSource/orchestrator - `sonar-orchestrator-locators/src/main/java/com/sonar/orchestrator/locator/ArtifactoryFactory.java`:
   
   ````
   private static final Set<String> SONARSOURCE_ARTIFACTORY_HOSTS = Set.of(
     "repox.jfrog.io",
     "repox-internal.dev.sonar.build",
     "repox-internal.sonar.build");
   ````

Verification Repos 1 inspected

Functional validation No results

Rules No rules evaluated

Broader impact Repos 1 inspected
Cross-repo 1 repository inspected 1 open impact

SonarSource/orchestrator Inspected

Auto-approval Not enabled

Set up

For more verification details, comment gitar display:verbose.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Auto-apply Compact
gitar auto-apply:on         
gitar display:verbose         

Was this helpful? React with 👍 / 👎 | Gitar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants