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

[radhika-pr]

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]

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]

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.