Bitbucket secured env variables not being passed into windows runner

[Nathan Zipf]

Hi guys, i am struggling with implementation of a windows private runner for deployment of azure resources. 

The runner is configured per the bitbucket documentation and the pipeline connects to it fine.

I have 3 environment variables that I use to connect to azure via cli: 

AZURE_APP_ID

AZURE_PASSWORD -- secured env variable

AZURE_TENANT_ID

When i run the command to connect to azure via cli, it fails because the AZURE_PASSWORD is empty: 

az login --service-principal --username=$env:AZURE_APP_ID --password=$env:AZURE_PASSWORD --tenant=$env:AZURE_TENANT_ID

When i write the output of the variables, it seems to confirm this. 

Write-Output $env:AZURE_APP_ID -- displays variable correctly

Write-Output $env:AZURE_PASSWORD -- displays $echo:AZURE_PASSWORD, indicating it is null

Write-Output $env:AZURE_TENANT_ID -- displays variable correctly

When i run the command directly within the windows VM, it works properly. 

Please advise, is there anything else i can do to test whether the secured variable is actually passed into the private runner? I am ok to echo to log if required - i will use a test secret.

[Patrik S]

Hey @Nathan Zipf ,

and welcome to the Community!

In order to protect the value of Secure variables from being shown in the logs, Pipelines automatically masks secure variable values from the logs: 

If a value matching a secured variable appears in the logs, Pipelines will replace it with $VARIABLE_NAME.

Reference: Secured-variable-masking 

This would explain why when you tried to print the secure variable value, it just printed the variable name instead. This does not mean the variable is empty, it's just the masking pipeline is executing to hide the actual value from the logs.

The issue in this case might be the token is not valid, or if you copy/pasted the value into the variable, it may contain a trailing/leading space that is making it invalid.

As you mentioned using a test token to confirm if the value is correct and if it's being passed to the pipeline, I would create that same variable again without using the Secure option and then print it in the logs. 

You can then check if the value is correct and if the azure commands succeeds. Once that is confirmed, you can rotate your token and create a new secure variable with the new value.

I hope that information helps! Let us know in case you have any questions.

Thank you, @Nathan Zipf !

Patrik S