You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See https://mikhail.io/2019/07/how-azure-cli-manages-access-tokens/ for where azure puts the goods after az login. We can make the ~/.azure/* dir one of the credentials, instead of passing in a service principal and then that inside the bundle to allow az to authenticate without requiring people to run az login manually in each action.
Note that the bundle consumer would need to run az login before executing the bundle. Long term plugins could have a hook before bundles run to help out with stuff like that.
It is up to the bundle author if they prefer that style of credential over service principals.
The text was updated successfully, but these errors were encountered:
Please add this enhancement, many of us that have Azure subscriptions managed through large corporate IT providers are blocked by policy from access to service principal accounts.
I was digging around to see if it's possible to "chain" your az login information somehow so that link was enlightening. Curious that you can't request an id and key from your logged in account. Looks like copying the user's profile.json file into the environment should make work. Similar to using a kubeconfig for the kubernetes plugin.
It seems to be possible to use the azidentity.NewDefaultAzureCredential to pick up the credentials, should be able to use both the azcli credentials, managed identities, and service principles from build agents in Azure DevOps and Github runners.
Looking a bit deeper in the docs it only seems to back this up. I don't personally have experience in go, but i'll add my 2 cents :)
See https://mikhail.io/2019/07/how-azure-cli-manages-access-tokens/ for where azure puts the goods after
az login
. We can make the~/.azure/*
dir one of the credentials, instead of passing in a service principal and then that inside the bundle to allow az to authenticate without requiring people to runaz login
manually in each action.Note that the bundle consumer would need to run
az login
before executing the bundle. Long term plugins could have a hook before bundles run to help out with stuff like that.It is up to the bundle author if they prefer that style of credential over service principals.
The text was updated successfully, but these errors were encountered: