DefaultAzureCredential prints libsecret errors in linux container from SharedTokenCacheCredential

[xinyi-joffre]

• Package Name: azure.identity
• Package Version: 1.6.0
• Operating System: Linux debian (the python:3.7-slim-buster image)
• Python Version: 3.7

Describe the bug
When using DefaultAzureCredential() in a jupyter notebook in a linux docker container, it dumps either pyobject or libsecret errors from the SharedTokenCacheCredential, which is confusing to users

To Reproduce
Steps to reproduce the behavior:

1. docker run -it python:3.7-slim-buster /bin/bash
2. run:

   > apt install libgirepository1.0-dev libcairo2-dev python3-dev gir1.2-secret-1
   > pip install pygobject
   > pip install azure-identity
   > python
   > from azure.identity import DefaultAzureCredential
   > DefaultAzureCredential().get_token("https://quantum.microsoft.com/.default")

3. See libsecret errors when trying SharedTokenCacheCredential:

libsecret did not perform properly.
* If you encountered error "Remote error from secret service:
  org.freedesktop.DBus.Error.ServiceUnknown",
  you may need to install gnome-keyring package.
* Headless mode (such as in an ssh session) is not supported.
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/msal_extensions/libsecret.py", line 126, in trial_run
    agent.save(payload)  # It would fail when running inside an SSH session
  File "/usr/local/lib/python3.7/site-packages/msal_extensions/libsecret.py", line 103, in save
    data, None)
gi.repository.GLib.GError: g-io-error-quark: Cannot autolaunch D-Bus without X11 $DISPLAY (0)
libsecret did not perform properly.
* If you encountered error "Remote error from secret service:
  org.freedesktop.DBus.Error.ServiceUnknown",
  you may need to install gnome-keyring package.
* Headless mode (such as in an ssh session) is not supported.

Expected behavior
DefaultAzureCredential should hide or suppress libsecret errors for SharedTokenCacheCredential.

It also looks like DotNet Azure.Identity excludes SharedTokenCacheCredential by default. For consistency across SDKs, it would also be great if azure-sdk-for-python similarly excluded SharedTokenCacheCredential from DefaultAzureCredential, since it really only works on Windows, and seems to cause issues on other systems.

For consistency, can the azure-identity package also set exclude_shared_token_cache_credential=True by default?

Merged PR for azure-sdk-for-net to remove SharedTokenCacheCredential from default: Azure/azure-sdk-for-net#16615
Related Issue: Azure/azure-sdk-for-net#17052

Screenshots

[chlowell]

Although SharedTokenCacheCredential is rather limited on Linux, it does work in some Linux scenarios, and on macOS. I'm reluctant to remove it from DefaultAzureCredential because doing so would break any applications relying on it. You can disable it through configuration though: DefaultAzureCredential(exclude_shared_token_cache_credential=True). However, the credentials which follow it in the DefaultAzureCredential chain typically fail in containers as well, so it's probably better to use a more specific credential type or verify that your container has the configuration you expect. What kind of identity do you intend to authenticate?

[xinyi-joffre]

@chlowell, we are using azure-identity as part of Jupyter Notebook samples that run in either user's local machine OR in a container, so that's why we don't choose just a specific type that only works in containers--the lib should choose the best mechanism based on where the user is using it. The root issue we run into is that the DefaultAzureCredential logs a lot of error messages for SharedTokenCacheCredential when it should really just log that it's unavailable like the other types of authentication. SharedTokenCacheCredential is the only authentication method that dumps many lines of extra logs.

The main point about setting it to default excluded was more just around consistency across SDKs for azure-identity, since right now if you use python vs dotnet you will get different default behavior. If the consistency is not important, it would still be great if someone could take a look at suppressing the extra log dumps from SharedTokenCacheCredential (both pyobject errors as well as libsecret errors), since the logs cause confusion around what actually happened during authentication, and that those errors are not the root of why authentication may have failed (since it tries other types of auth as well).

[chlowell]

DefaultAzureCredential is usually the best choice for a sample because it has a simple API and the best chance of succeeding in an arbitrary development environment, allowing your sample to focus on your library code instead of authentication trivia. But it doesn't work in all environments (no credential type does) and will usually require configuration to function in a container.

About suppressing log output, I merged #19283 today to reduce the volume of DefaultAzureCredential logging. The credential will still log, because its messages are important for diagnosing failures and applications which don't want to see them can control them with Python's logging library. Messages about PyGObject and libsecret are actually logged by the msal-extensions library; I opened AzureAD/microsoft-authentication-extensions-for-python/issues/92 to suggest a workaround that would enable azure-identity to avoid triggering those messages.

[github-actions]

Hi @xinyi-joffre, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.