-
Notifications
You must be signed in to change notification settings - Fork 879
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
Support specifying Azure auth type #1606
Comments
I have the same issue. We use a VM jumphost inside our private network. This VM has a managed identity but we don't want to authenticate to the Key Vault with this ID. We want to use the users cli identity but there is no way to override the standard order of priority so that the CLI is used. Unless someone knows otherwise? |
I did a bit more digging and I think this used to be supported via the AZURE_AUTH_METHOD env var but was removed here: #1067 |
Same issue her on Jenkins while using a docker in docker build sops is using sometimes the managed identity of the vm and sometimes the information gained after calling az login in the current shell |
For it's even weirder: Within my Jenkins pipeline it takes the managed identity of the build server even though I use az login just before. But that happens only sometimes and I cannot pin down when it uses the identity of the build agent |
Currently the azure authentication flow seems to just pass off the auth options to the azidentity NewDefaultAzureCredential function: https://github.com/getsops/sops/blob/main/azkv/keysource.go#L232 While this does simplify things on sops side, that auth function does not allow fine grained control over what auth type is used. It is structured as a fall through but no ability to override, in my case managed identity and cli auth are populated so since managed identity will always be used even if I would like to use cli auth.
Can sops add some logic to be able to specify/disable certain auth types? (In my case to be able to disable managed identity, but the ability to generally control all auth types is probably ideal) I understand the simplicity of handing the auth flow off to the azure default auth flow, but a lot of control over the auth flow is lost in the process.
The text was updated successfully, but these errors were encountered: