Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DefaultAzureCredential authentication failed #441

Open
hamid-elaosta opened this issue Jun 26, 2024 · 6 comments
Open

DefaultAzureCredential authentication failed #441

hamid-elaosta opened this issue Jun 26, 2024 · 6 comments
Assignees

Comments

@hamid-elaosta
Copy link

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
Copy link
Author

hamid-elaosta commented Jun 26, 2024

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
Copy link
Author

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
Copy link
Member

yxxhero commented Jun 26, 2024

@hamid-elaosta PR is welcome.

@yxxhero
Copy link
Member

yxxhero commented Jul 26, 2024

@hamid-elaosta I will fix this issue.

@yxxhero yxxhero self-assigned this Jul 26, 2024
@yxxhero
Copy link
Member

yxxhero commented Jul 26, 2024

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

@hamid-elaosta
Copy link
Author

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.

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

No branches or pull requests

2 participants