[BUG] EnvironmentCredential authentication unavailable. Environment variables are not fully configured. For containerized workloads.

[robvet]

Library name and version

DefaultAzureCredential - .NET Core 7

Describe the bug

Customer wants to leverage managed identities. They’re hoping to use the same code to run (1) in Azure and (2) while developing locally (in Visual Studio) using its built-in container features. Believe that’s one of the design goals for the DefaultAzureCredential: Same code block, but pick up the Managed Identity credential in Azure, and the Visual Studio credential when developing locally.

Having an issue making that happen.

When natively running a service locally (non-containerized), I pick up the Default Credential from Visual Studio just fine:

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
           .ConfigureAppConfiguration((hostingContext, configuration) =>
            {
                configuration.AddEnvironmentVariables();
                var settings = configuration.Build();

                var keyVaultEndpoint = new Uri(settings["VaultUri"]);
                var credential = new DefaultAzureCredential(true);
                configuration.AddAzureKeyVault(keyVaultEndpoint, credential);
            })
          .ConfigureWebHostDefaults(webBuilder =>
          {
              webBuilder.UseStartup<Startup>();
          });

However, when I launch the same code in a container, I get an exception and the following error message: EnvironmentCredential authentication unavailable. Environment variables are not fully configured.

Have looked at the John Gallant blog posts, which are highly informative! Believe the problem is the container has limited visibility to the local Visual Studio credentials.

Unfortunately, not finding the right fix. Could you possibility point me in the right direction?

If it helps, here is a repo that produces the problem: robvet/DefaultAzureCredentialContainerWoes (github.com)

Thanks in advance for any guidance you can provide.

Expected behavior

Use the same code block to run (1) in Azure and (2) while developing locally (in Visual Studio) using its built-in container features.

Actual behavior

Cannot obtain an identity when running locally in a container. Exception thrown: EnvironmentCredential authentication unavailable. Environment variables are not fully configured.

Reproduction Steps

Repo that produces the problem: robvet/DefaultAzureCredentialContainerWoes (github.com).

Simply run as a container.

Environment

Visual Studio 2022. .NET Core 7 API. Happens for containerized workloads running locally.

[jsquire]

//cc: @christothes

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist. Please expect delayed responses due to the US holidays.

[robvet]

Not good. Running same code several days later and am getting different exception:

Unable to load shared library 'libsecret-1.so.0' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable: /usr/share/dotnet/shared/Microsoft.NETCore.App/7.0.1/libsecret-1.so.0.so: cannot open shared object file: No such file or directory.

Hmm.... Really need to get this working for a large customer. Can someone please escalate to take a look and provide guidance to get on the right path.

Thanks

[Petermarcu]

The libsecret.so error sounds like you have a partial or misconfigured install of .Net. For the issues using DefaultAzureCredentials, yes, if the environment/secrets aren't properly configured, it will fail in that way. Based on your work flow, it sounds like you are expecting VS to populate the environment with the credentials it needs?

[christothes]

This appears to be a duplicate of https://github.com/Azure/azure-sdk-for-net/issues/19167 . Do any of workarounds mentioned there work for you?

[ghost]

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