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

Support specifying Azure auth type #1606

Open
nbjohnson opened this issue Sep 10, 2024 · 4 comments
Open

Support specifying Azure auth type #1606

nbjohnson opened this issue Sep 10, 2024 · 4 comments

Comments

@nbjohnson
Copy link

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.

@djw-bsn
Copy link

djw-bsn commented Oct 1, 2024

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?

@djw-bsn
Copy link

djw-bsn commented Oct 1, 2024

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

@hmrc87
Copy link

hmrc87 commented Nov 8, 2024

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

@hmrc87
Copy link

hmrc87 commented Nov 22, 2024

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

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