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

Env AZURE_CLIENT_ID and CLIENT_SECRET takes precedence over custom variables client_id and client_secret #112

Open
radhika-pr opened this issue Nov 10, 2022 · 2 comments

Comments

@radhika-pr
Copy link

In my vault implementation I have to use the AZURE_CLIENT_ID and AZURE_CLIENT_SECRET variables for unsealing purposes.
The lines here resulted in losing a lot of time troubleshooting why my client_id and client_secret set for the azure_secret_engine doesnt work. The environment variable shouldn't take precedence over the custom value . If there are no value set, then it make sense to take the environment variable. This implementation doesnt allow ( not flexible) to have any other client_id.

@maxcoulombe
Copy link
Contributor

Hey @radhika-pr , thanks for pointing that out and I'm sorry it caused a lot of wasted time.

We talked about this internally with the team. We definitely agree this is an unfortunate implementation and API provided values should take precedence over environment variables. However reversing the priority at this time would be a significant breaking change.

As a short term mitigation solution, I opened a doc PR to put more emphasis on this behavior since it is unintuitive. If this issue gets a lot of traction or we get additional feedback that'd suggest this is a common pitfall, we'll reach back to the wider organisation to go through the breaking change process.

I'll keep the issue open so people can +1 and share their own feedback, but we do not plan to acccept a PR that'd prioritize API-defined client ID & client secret at this stage.

@eplightning
Copy link

eplightning commented Nov 15, 2023

This issue also seems to make it impossible (or at least not very simple) to use both this engine and Azure auto-unseal with workload identity (https://github.com/Azure/azure-workload-identity).

Workload identity relies on injecting environment variables mentioned in this issue, so unless you're using the same client for both this engine and autounseal it won't work.

Only workaround I was able to do is using migration sidecar (https://learn.microsoft.com/en-us/azure/aks/workload-identity-migrate-from-pod-identity).

It would be ideal to at least have an option to disable this behavior.

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

3 participants