multi tenant_id client creation with get_client_from_cli_profile(SubscriptionClient) fails

[kbroughton]

If I have more than one tenant -> many subscriptions, then
client = get_client_from_cli_profile(SubscriptionClient)
will fail if my most recent az login was for the non-subscription account.

Failure error: CLIError: Credentials have expired due to inactivity. Please run 'az login'

Steps to reproduce:
az account clear
az login # for the default subscription account
get_client_from_cli_profile(SubscriptionClient) # success
az login # for a different email with different tenant
get_client_from_cli_profile(SubscriptionClient) # fails
az login # for the default subscription account again
get_client_from_cli_profile(SubscriptionClient) # success

Expected behaviour:
get_client_from_cli_profile should always pull the default subscription client regardless of the last login.

Suggestion:
get_client_from_cli_profile should take a subscription_id argument so that it could be selected from accessTokens.json or some other .azure file.

def get_client_from_cli_profile(SubscriptionClient, subscription_id=None):
'''If subscription_id is supplied, retrieve a client for it, otherwise, get the default subscription client'''

Currently, get_client_from_cli_profile does accept subscription_id as a kwarg, but it does not affect the result.

[lmazuel]

Hi @kbroughton !
That's by design, get_client_from_cli_profile is using the active subscription and tenant, as documented:
https://docs.microsoft.com/python/azure/python-sdk-azure-authenticate?view=azure-python#mgmt-auth-cli

The CLI has not public API in my knowledge to read the configuration file. What you can do is use the the second method get_client_from_auth_file and creates two files for your two configurations.

FYI @yugangw-msft if he has any comments.

[kbroughton]

Thanks for your reply. My particular situation is one where i have login credentials for a readonly account (pen-testing) and do not have privileges to create the service principal required for the auth_file login. I tried the suggestion of using get_client_from_cli_profile and passing in the subscription_id with the code modification

def get_azure_cli_credentials(resource=None, with_tenant=False, subscription_id=None):
    profile = get_cli_profile()
    cred, subscription_id, tenant_id = profile.get_login_credentials(resource=resource, subscription_id=subscription_id)

This worked for me.

My main suggestion is that auth patterns supported by azcli should also work for the python-sdk. Following that, there should be a way to use the profile/subscription_id without having to create service principals, which seems to currently be required for python-sdk.

[donaldguy]

It's a dirty abstraction violation but this seems to work these days:

from azure.cli.core._profile import CredsCache

def get_azure_cli_credentials(resource=None, with_tenant=False, subscription_id=None):
    profile = get_cli_profile()

    # XXX: Abstraction break.
    # Don't use the global creds cache - or we can't manage to have both tenants in effect
    profile._creds_cache = CredsCache(profile.cli_ctx, profile.auth_ctx_factory, async_persist=profile._creds_cache._async_persist)

    cred, subscription_id, tenant_id = profile.get_login_credentials(resource=resource, subscription_id=subscription_id)
    return (cred, subscription_id, tenant_id)

It would be nice if there was a way to ask for this directly via azure.common.credentials. get_azure_cli_credentials or azure.common.credentials import get_cli_profile

[lmazuel]

@yugangw-msft what do you think?

[ghost]

Hi @kbroughton. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!