search

helmfile / vals

Helm-like configuration values loader with support for various sources
Apache License 2.0
485 stars 67 forks source link

DefaultAzureCredential authentication failed #441

Open hamid-elaosta opened 3 weeks ago

hamid-elaosta commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

@hamid-elaosta PR is welcome.