ACR auth requests the ARM audience; fails on registries with azureADAuthenticationAsArmPolicy disabled

[ma-ts]

Description

Trivy cannot pull from an Azure Container Registry whose azureADAuthenticationAsArmPolicy is disabled (the Defender-recommended hardening "Container registries should have ARM audience token authentication disabled"), even with a correctly configured workload identity / managed identity that holds AcrPull.

The ACR registry client hard-codes the ARM audience:

// pkg/fanal/image/registry/azure/azure.go
scope = "https://management.azure.com/.default"
...
aadToken, err := cred.GetToken(ctx, policy.TokenRequestOptions{Scopes: []string{r.scope}})

and then exchanges that token at <registry>/oauth2/exchange. A registry with ARM-audience auth disabled rejects it:

unexpected status code 401 from exchange request, response body:
{"errors":[{"code":"UNAUTHORIZED","message":"token validation failed CorrelationId: …"}]}

Seen with trivy-operator 0.32.1 on AKS: zero VulnerabilityReports and failing scan jobs for every image in such a registry.

Desired behavior

Request the ACR audience, https://containerregistry.azure.net/.default (what the Azure SDK's azcontainerregistry client and fluxcd/pkg/auth/azure use), with the ARM scope at most as a fallback for sovereign/custom clouds that do not define the ACR service. Authorisation is unchanged — the exchange still yields a refresh token scoped by the identity's AcrPull.

Workaround

az acr config authentication-as-arm update -r <registry> --status enabled — i.e. undo the hardening.

Environment

• Trivy 0.76.x (trivy-operator 0.32.1), AKS, workload identity (AZURE_CLIENT_ID/AZURE_TENANT_ID/AZURE_FEDERATED_TOKEN_FILE injected), Premium ACR with private endpoint.

[ma-ts]

Closing for now: observed with trivy-operator 0.30.1 / Trivy 0.69.3; I'll re-verify against the current release and reopen with exact versions if it still reproduces.

[ma-ts]

Reopening — verified against the current release.

Trivy 0.76.1 (what trivy-operator 0.36.1 / chart 0.38.1 ships) reproduces it from a workstation with AzureCliCredential, no operator involved:

$ AZURE_TENANT_ID=… trivy image --debug --image-src remote creunleepeuddev.azurecr.io/eudentify:0.1.0
DEBUG  Credential error  err="unable to refresh token: exchange access token: POST https://creunleepeuddev.azurecr.io/oauth2/exchange
RESPONSE 401: 401 Unauthorized
{ "errors": [ { "code": "UNAUTHORIZED", "message": "token validation failed CorrelationId: e6479d9c-…" } ] }"
FATAL  … GET https://creunleepeuddev.azurecr.io/oauth2/token?scope=repository%3Aeudentify%3Apull&service=…: UNAUTHORIZED: authentication required

Control, same identity, same registry (azureADAuthenticationAsArmPolicy: disabled), token POSTed to /oauth2/exchange:

token audience	exchange
https://containerregistry.azure.net	200
https://management.azure.com (what pkg/fanal/image/registry/azure/azure.go:33 requests)	401

Two things worth fixing:

1. scope should be https://containerregistry.azure.net/.default (ARM at most as a fallback for clouds without the ACR service). azcontainerregistry.ServiceName already carries the right value per cloud.
2. GetToken in pkg/fanal/image/registry/token.go logs the credential error only at DEBUG and falls back to anonymous, so the user-visible error is the misleading authentication required from /oauth2/token. At least WARN would have saved us a few days.

Versions: Trivy 0.76.1 (also 0.69.3 under trivy-operator 0.30.1 on AKS with workload identity); the ARM scope is unchanged on main.

[nikpivkin]

Hi @ma-ts , thanks for the report!

Track #11597