[mbevc1]

Let kosli snapshot azure run against Azure China, Azure Government, a private cloud or a local stand-in. Its login, Resource Manager and Kudu endpoints were fixed to the public cloud, so sovereign-cloud tenants could not use it, and Cloud Capture's end-to-end job could not run the real CLI against its Azure stand-in.

Closes #1327

New flags

• --azure-cloud (public, china, usgov; default public)
• --azure-authority-host and --azure-resource-manager-url, also settable as KOSLI_AZURE_AUTHORITY_HOST and KOSLI_AZURE_RESOURCE_MANAGER_URL

Behaviour changes for existing users

With the default public cloud and no overrides, the endpoints, token audiences and authority are the same as on main. What changes:

• Kudu token: still requested for https://management.azure.com/, but through the SDK credential (Entra v2 endpoint, cached and retried) instead of a hand-written v1 request that panicked on a missing access_token. The real-Azure integration tests download from Kudu with it and pass.
• Kudu host: comes from the site's Repository entry in hostNameSslStates, the same lookup the Azure CLI uses. The token is sent only if that host is the app's own SCM host: <app>.scm.azurewebsites.net, or <app>-<hash>.scm.<region>.azurewebsites.net for an app with a unique default hostname. Such apps did not work before. A site that lists no such host fails, naming the app, before any token is requested. App Service Environment hosts stay unsupported, as before.
• AZURE_AUTHORITY_HOST: still honoured, and now also for the Kudu token, which always went to login.microsoftonline.com before.
• ACR: one credential and token cache serve every image, instead of a new credential per image.

Design choices

• The overrides replace endpoints only. Tokens keep the chosen cloud's audiences, so a private cloud with its own Resource Manager audience would need a further flag.
• In Azure China and Azure Government the Kudu token is for management.core.chinacloudapi.cn/ or management.core.usgovcloudapi.net/, the resources the Azure CLI sends to Kudu there. Neither cloud has been tested against real Azure.
• Instance discovery is turned off when the authority is overridden, because it asks the public cloud about the new authority.
• Both overrides must be https URLs: the SDK refuses an http authority and will not send a bearer token over http.
• --azure-resource-manager-url also lifts the Kudu host check, because the site list then comes from the operator's own endpoint.

Cloud Capture

Set the two environment variables in the Snapshotter to the stand-in's https URL. The stand-in has to serve:

• /<tenant>/v2.0/.well-known/openid-configuration and the token endpoint it names
• the site list, each site with a Repository host name, which may be the stand-in's own host
• the Kudu zip at /api/zip/site/wwwroot/

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR (not needed)
• Terraform provider and related changes updated, if needed (not needed)

[claude]

Claude finished @mbevc1's task in 3m 2s —— View job

---

Follow-up review complete

• Fetch previous review comments
• Diff BEFORE..AFTER to scope review (BEFORE unreachable — full PR diff reviewed, scoped to the current commit set da32bc9d..27253192)
• Assess status of each prior finding
• Check new commits for new bugs/security issues/regressions
• Post summary comment

All three previously-raised findings are resolved and their review threads are already marked resolved on GitHub:

1. Kudu token now only goes to the app's own SCM host unless --azure-resource-manager-url overrides the endpoint (checkKuduHost/trustedKuduHost).
2. Public-cloud Kudu token resource reverted to https://management.azure.com/, matching pre-PR behaviour.
3. ACR lookups now reuse the client's shared Azure credential instead of minting one per image.

No new bugs, security issues, or regressions found in the reviewed commits. Full details posted as a summary comment.

[mbevc1]

The Kudu token no longer changes on the default path.

Default path (public cloud, no overrides) compared with main

• Authority: the credential is given no cloud, as before, so azidentity still uses AZURE_AUTHORITY_HOST when it is set.
• Resource Manager and ACR: same endpoint and audiences. With no cloud set, the SDK falls back to cloud.AzurePublic and containerregistry.azure.net, which are the values now passed explicitly.
• Kudu token: requested for https://management.azure.com/, the same resource as before. It now comes through the SDK (cached, retried) instead of a hand-written v1 request that panicked on a missing access_token.
• Kudu host: taken from the site's Repository entry in hostNameSslStates, the same lookup the Azure CLI uses (_get_scm_url). The token is sent only if that host is the app's own SCM host, either <app>.scm.azurewebsites.net or <app>-<hash>.scm.<region>.azurewebsites.net (unique default hostname). The old code built only the first form, so apps with a unique default hostname now work. App Service Environment hosts stay unsupported, as before.
• ACR: the client's credential is shared across images, so one token cache serves every image.

Other clouds

• The Kudu token resource is management.core.chinacloudapi.cn/ or management.core.usgovcloudapi.net/, which the Azure CLI sends to Kudu in those clouds.
• The Kudu host must end in chinacloudsites.cn or azurewebsites.us.
• None of this has run against Azure China or Azure Government.

Overrides

• Overrides replace endpoints only. Tokens keep the base cloud's audiences.
• Instance discovery is turned off when the authority is overridden.
• --azure-resource-manager-url also lifts the Kudu host check, because the site list then comes from the operator's own Resource Manager.

Cloud Capture

Set the two environment variables in the Snapshotter to the stand-in's https URL. The stand-in has to serve:

• instance discovery
• /<tenant>/v2.0/.well-known/openid-configuration
• the token endpoint that configuration names
• the site list, with a Repository host name for each site
• the Kudu zip at /api/zip/site/wwwroot/

[claude]

Follow-up review (commits through 2725319)

Checked the three previously-raised findings against the current code (all three GitHub threads are already marked resolved):

1. Security — Kudu token sent to arbitrary Repository host (internal/azure/azure_apps.go): Resolved. trustedKuduHost/checkKuduHost (internal/azure/cloud.go) now require the host to match the app's own SCM host in the chosen cloud's App Service domain (<app>.scm.<domain> or <app>-<hash>.scm.<region>.<domain>) unless --azure-resource-manager-url is set. Covered by TestTrustedKuduHostRefusesAnyOtherHost / TestFingerprintZipServiceRefusesAnUntrustedKuduHostBeforeAskingForAToken.
2. Kudu token resource/audience changed from management.azure.com : Resolved. kuduResources["public"] is back to https://management.azure.com/, matching the pre-PR behaviour (scope https://management.azure.com//.default), verified by TestKuduTokenIsForTheChosenCloudsResourceManager.
3. Perf — new ClientSecretCredential per ACR image: Resolved. acrImageFingerprint now calls acrCredential, which reuses azureClient.credential when the client was built via NewAzureClient, falling back to a fresh credential only for test-constructed AzureClient{} literals. Verified by TestACRReusesTheClientsCredential.

No new bugs, security issues, or regressions found in the lines touched by these commits — 0 new inline comments.

View job run