azblob: change in behaviour for falling back to `az login` credentials
tgummerer opened this issue · comments
Describe the bug
Sometime between v0.27 and v0.36 there seems to be a change in behaviour for what happens when two alternative login methods to azblob backends are set. In v0.27, when AZURE_KEYVAULT_AUTH_VIA_CLI=true
is set, and the user is logged in to azure using the az login
CLI, it seems like gocloud.dev falls back to using those credentials, even when AZURE_CLIENT_ID
and AZURE_CLIENT_SECRET
are set, but don't have permissions for the particular backend (or are plain wrong).
In v0.36 the login will simply fail if the AZURE_CLIENT_*
environment variables do not allow the login.
To Reproduce
Run az login
and set AZURE_KEYVAULT_AUTH_VIA_CLI=true
. Also set AZURE_CLIENT_ID
and AZURE_CLIENT_SECRET
to something that doesn't have access to an azblob container. Then try to access the container. It will succeed with 0.27, but fail with 0.36
Expected behavior
The login should fall back to the credentials obtained from az login
.
Version
0.36
Additional context
This came to my attention in the investigation in pulumi/pulumi#15786 (comment).
It's not obvious to me that the old/fallback behavior is better than the new one. It seems like an explicit failure is better...? Otherwise the fallback could lead to quite surprising results.
I'm a bit torn on the issue tbh. It's something that did work before, so the change in behaviour is surprising. E.g. in the linked issue the user is logged in, so accessing the azblob storage should work, even if they are using different credentials for setting up other resources. But I can see how the explicit failure is better in some cases.
Yea, I think this new behavior is more clear (although it wasn't on purpose). Given that nobody else has complained, the change in behavior doesn't appear to have been too disruptive, let's stick with it.