[FEATURE REQ] DefaultAzureCredential for local docker testing

[et1975]

Azure.Identity
Testing code that uses DefaultAzureCredential in a container locally seems to require a lot of effort, unless one is willing to supply username/password into the environment.
Creating a service principal and supplying the clientID + Secret is not much better, but also requires a whole lot of additional effort - like setting up the SP, granting the permissions that the developer account already has, etc.

There should be a way to use VS/VSCode/CLI tokens simply by mounting ~/.azure into /root/.azure of the container, unfortunately this does not work today. #12749 mentions installation of the CLI as a working solution, but I just tried this on Alpine and
a) it's a hassle - installing all that stuff on Alpine is error-prone experience and takes a long time (on each build!)
b) it doesn't work, as I still get the exception

SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details
---> Azure.Identity.AuthenticationFailedException: SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details
---> Microsoft.Identity.Client.Extensions.Msal.MsalCachePersistenceException: Persistence check failed. Inspect inner exception for details
---> System.DllNotFoundException: Unable to load shared library 'libsecret-1.so.0' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library liblibsecret-1.so.0: No such file or directory
at Microsoft.Identity.Client.Extensions.Msal.Libsecret.secret_schema_new(String name, Int32 flags, String attribute1, Int32 attribute1Type, String attribute2, Int32 attribute2Type, IntPtr end)
at Microsoft.Identity.Client.Extensions.Msal.LinuxKeyringAccessor.GetLibsecretSchema()
at Microsoft.Identity.Client.Extensions.Msal.LinuxKeyringAccessor.Write(Byte[] data)
at Microsoft.Identity.Client.Extensions.Msal.MsalCacheStorage.VerifyPersistence()
--- End of inner exception stack trace ---
at Microsoft.Identity.Client.Extensions.Msal.MsalCacheStorage.VerifyPersistence()
at Microsoft.Identity.Client.Extensions.Msal.MsalCacheHelper.VerifyPersistence()
at Azure.Identity.MsalClientBase1.GetClientAsync(Boolean async, CancellationToken cancellationToken) at Azure.Identity.MsalClientBase1.GetClientAsync(Boolean async, CancellationToken cancellationToken)
at Azure.Identity.MsalPublicClient.GetAccountsAsync(Boolean async, CancellationToken cancellationToken)
at Azure.Identity.SharedTokenCacheCredential.GetAccountAsync(Boolean async, CancellationToken cancellationToken)
at Azure.Identity.SharedTokenCacheCredential.GetTokenImplAsync(Boolean async, TokenRequestContext requestContext, CancellationToken cancellationToken)

[et1975]

I figured a workaround just now:

• have a Dockerfile just for running stuff locally (not a great start, but easier than the alternatives)
• that uses mcr.microsoft.com/azure-cli as the base image and
• in docker-compose has:

volumes:
 - ~/.azure:/root/.azure 

And in the code sets up the auth chain:

ChainedTokenCredential(ManagedIdentityCredential() or EnvironmentCredential(), AzureCliCredential())

This works, but would be great if we didn't need az cli in the first place.

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jongio]

See here for how I do it, which is the same as you, but checkout the CLI install script in my dev container, it's a one liner.

RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash

VIDEO: https://youtu.be/oDNGs7B2g1A
CODE: https://github.com/jongio/azureclicredentialcontainer

The only thing better than this would be local ManagedIdentity, but that isn't available right now. We have discussed it, but it opens issues that need to be fleshed out.

[nhart12]

Agreed, to be able use/mount IDE azure credentials when local testing would be awesome. Azure CLI bloats images by almost a gig

[jdthorpe]

See here for how I do it, which is the same as you, but checkout the CLI install script in my dev container, it's a one liner.

RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash

VIDEO: https://youtu.be/oDNGs7B2g1A CODE: https://github.com/jongio/azureclicredentialcontainer

The only thing better than this would be local ManagedIdentity, but that isn't available right now. We have discussed it, but it opens issues that need to be fleshed out.

Jon Gallant (@jongio), This worked for me up until I upgraded my Azure CLI to 2.33. Now it seems the windows host machine encrypts the tokens in a .bin file, but the linux azure CLI inside the container expects the unencrypted .json file, so I get a message inside the container stating Please run 'az login' from a command prompt to authenticate before using this credential. inside the container, but the same code running on the windows host fetches an access token without issue.

[philipwolfe]

Eugene Tolmachev (@et1975) Jason Thorpe (@jdthorpe) Jon Gallant (@jongio) Christopher Scott (@christothes) I am running into this too. Here is what I came up with. We too need ways for a container running on a QA engineer machine to authenticate to Azure without checking credentials into SCC in a YAML file. Would love some feedback. My goal is to take the access token from the engineer and use it for this session...doesn't need to be long term like the EnvironmentCredential.
philipwolfe@5dff08d
based on ideas from: https://stackoverflow.com/a/61498506/13122820