Hello All, Hoping someone may have some insight on strange behavior surrounding authentication. It consistently fails, even when environment variables are populated with valid values. • Using Azure Native to create CDNs in a CI pipeline • Service principal authentication works fine via

az login

• Per the docs, we should be able to use the following environment variables for authentication:

ARM_CLIENT_ID
ARM_CLIENT_SECRET
ARM_TENANT_ID
ARM_SUBSCRIPTION_ID
ARM_LOCATION_NAME

• After setting them with the same values as

az login

, this error arises:

azure.identity._exceptions.CredentialUnavailableError: Please run 'az login' to set up an account

• Setting

-v=9

, reveals this to be the culprit, but I'm unsure how to ensure that the environment variables are used to authenticate prior to execution of the command.

subprocess.CalledProcessError: Command '['/bin/sh', '-c', 'az account get-access-token --output json --resource <https://management.azure.com>']' returned non-zero exit status 1.

• Ironically, another error specifying that service principal credentials should be supplied via configurations/environment variables is thrown when

az login

is used. • Just tried setting values in the the config file and the same behavior is exhibited.... What in the world am I overlooking!??!

Seems strange! What CI system are you using? Are you also able to share how you're setting those env vars? The linked doc also mentions that using the

az

CLI in a CI scenario is not recommended; have you tried using one of the alternatives?

In the image above, a container with all the dependencies installed is being used. I removed the CI from the equation, which is Gitlab, just for troubleshooting shenanigans....because it's weird at times, too. The issue has persisted unfortunately. AFAIK, I think

az

itself is used by the Azure Native library. I could be mistaken about that. The following bash snippet is used to set the environment variables by reading them from a JSON document procured from HCP Vault:

SECRETS=/tmp/secrets.json
vault kv get -mount="$VAULT_SECRET_MOUNT" \
  -format=json "$VAULT_SECRET_NAME" | jq ".data.data" > $SECRETS
for KEY in $(jq -r "keys[]" $SECRETS); do
    echo "Setting Environment Variable: $KEY";
    VALUE=$(jq -r ".${KEY}" $SECRETS);
    eval "export ${KEY}=${VALUE@Q}";
done
rm $SECRETS

I can confirm this approach works and that the values are valid as has been consistently effective for other providers like AWS, Fastly, and DigitalOcean.

My only guess on this one would be that

eval

is creating those variables in a child process, which are not getting propagated to the parent and thus not propagated to subsequent CI steps. Perhaps you could try removing

eval

? Maybe something as simple as

export ${KEY}=${VALUE@Q}

? Or, if

eval

must be present, you could try

export ${KEY}=$(eval ${VALUE@Q})

No problem! I appreciate the extra eyes! We can use this syntax to ensure the variables are exported in the current process:

. set_vars.sh

I actually have guard rails in the Pulumi program to ensure that the environment variables are present, otherwise it throws an error. They're definitely there 😄

Oh goodness! Hopefully that solves it

Dyslexia be damned -- I misread the operator, which is actually

>=

.

2.6.0

is currently installed. Upgrading to

2.8.0

now. Maybe that'll help.

To remove the shell as a possible culprit, perhaps you could try setting the values within the pulumi config during the CI run as demonstrated in the doc page: https://www.pulumi.com/registry/packages/azure-native/installation-configuration/#set-configuration-using-pulumi-config

Yep, the outcome was the same. Tried that just a second ago, along with expressly instantiating a provider. I actually missed this log event while using the environment variables until just now. It seems to claim that it's using "Client Secret for Authentication" as configured. Three things are interesting: 1. It confirms use of "Service Principal / Client Secret for Authentication" 2. It's getting an OAuth config, but it isn't expressly configured to use OAuth 3. We know that the account has permissions to retrieve the token because the

az account access

command runs fine after using

az login

Starting to wonder if there's a misconfiguration with the service principal/app.

Fascinating... could a service principal client secret be lurking somewhere in your Vault?

Good observation! You're def right (shiv code haha). Luckily, HCP Vault's interface makes it easy to inspect by sorting the keys. No duplicates in sight.

I'm glad you found the issue! 😄