DefaultAzureCredential authentication failed

[hamid-elaosta]

Forgive me if this is a mistake on my end, but after having followed various bits of documentation I am at a loss.

I'm using vals with helm secrets plugin to manage secrets in helm values files for Terraform.

I had previously used this with no issues by following the very simple setup described here but now have a new laptop; I have downloaded the latest versions of Azure CLI and vals. I'm running Ubuntu 24.04 where previously I was running Debian 12.

Previously, I would simply az login, follow the login steps in my web browser, and then vals would be able to access secrets in my Azure KeyVault.

Since setting up from scratch, I have followed the same steps (I don't remember any additional steps being required) of az login and then use vals or helm secrets as required, but now I receive this error that the token couldn't be acquired.

helm secrets --backend vals decrypt values.akv.yaml --terraform
[helm-secrets] vals error: expand azurekeyvault://keyvault-name/asecret: DefaultAzureCredential authentication failed. failed to acquire a token.
Attempted credentials:
	EnvironmentCredential: missing environment variable AZURE_TENANT_ID
	WorkloadIdentityCredential: no client ID specified. Check pod configuration or set ClientID in the options
	ManagedIdentityCredential authentication failed. ManagedIdentityCredential authentication failed. authentication failed
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 404 Not Found
--------------------------------------------------------------------------------
not found
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#managed-id
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 404 Not Found
--------------------------------------------------------------------------------
not found
--------------------------------------------------------------------------------
To troubleshoot, visit https://aka.ms/azsdk/go/identity/troubleshoot#managed-id
GET http://169.254.169.254/metadata/identity/oauth2/token
--------------------------------------------------------------------------------
RESPONSE 404 Not Found
--------------------------------------------------------------------------------
not found
--------------------------------------------------------------------------------
[helm-secrets] File is not encrypted: values.akv.yaml
Error: plugin "secrets" exited with error

I'm not using Environment credentials, and previously vals was simply picking up the auth from the az login that's already happened, but that doesn't appear to be the case now.

I've followed the troubleshooting from Microsoft (https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azidentity/TROUBLESHOOTING.md#troubleshoot-defaultazurecredential-authentication-issues) and have confirmed I can retrieve the auth token by hand, I'm not sure though how to further debug why vals can't do so.

[hamid-elaosta]

I have a Go tool which I use to manage secrets in the KeyVault. When using the same package versions that vals is now using, it also fails with the same error.

github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.7.0
github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.1.0

However, using the older packages I was using already, it works as expected:

github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.5.1
github.com/Azure/azure-sdk-for-go/sdk/keyvault/azsecrets v0.12.0

Upgrading only azidentity to v1.7.0 but NOT upgrading azsecrets (leaving it at v0.12.0) also breaks, suggesting the issue is in the azidentity package.

EDIT: v1.6.0 also appears to be broken, while v1.5.2 is the latest working version.

[hamid-elaosta]

The package maintainers have confirmed that this breaking change is expected behaviour; I guess vals will need to change its implementation to support the "easy" setup for AKV it did previously if it wants to use a package version later than v1.5.2.

See the back linked issue I raised the package repo for more info.

[yxxhero]

@hamid-elaosta PR is welcome.

[yxxhero]

@hamid-elaosta I will fix this issue.

[yxxhero]

@hamid-elaosta I have no env to test this issue. maybe we can rollback to v1.5.2. WDYT?

[hamid-elaosta]

I rolled the library back and compiled vals myself and that is working, it's unfortunate as vals won't be able to benefit from changes in the Azure SDK without updating further.

Unfortunately, Azure's decision with the SDK makes auto-config basically impossible; vals would need to take a flag to say which type of environment it's running in now that the fallback that worked before doesn't work any more.

I disagree with the way they've changed the SDK, but it is what it is.

[MattHodge]

I was able to get vals (0.37.8) working by setting the AZURE_ADDITIONALLY_ALLOWED_TENANTS environment variable before running vals.

export AZURE_ADDITIONALLY_ALLOWED_TENANTS="*"

echo "foo: ref+azurekeyvault://my-vault/secret-a" | vals eval -f -

Really annoying (Azure's fault) but least it's an easy work around.

[rdvansloten]

I was able to get vals (0.37.8) working by setting the AZURE_ADDITIONALLY_ALLOWED_TENANTS environment variable before running vals.

export AZURE_ADDITIONALLY_ALLOWED_TENANTS="*"

echo "foo: ref+azurekeyvault://my-vault/secret-a" | vals eval -f -

Really annoying (Azure's fault) but least it's an easy work around.

Brilliant, saved my ass.

[yxxhero]

@rdvansloten we should update the docs.