Service Principal credential in Azure CLI?

[andreacassioli]

I am running on linux host agents in cloud VSTS some build pipelines where I use Azure CLI tasks to execute some az cli commands. All works fine as we have define some service principal.

However, I also would like to execute a Terraform command (in particular plan), that requires to specify explicitly the service principal credential:

https://www.terraform.io/docs/providers/azurerm/index.html#argument-reference

I have been looking at the env variables that Azure CLI provides and I cannot see those credential. Is there a way to get them somehow in bash?

[andreacassioli]

Just for my understanding: am I missing something?

[amaljg]

@andreacassioli ,

The endpoint authorization parameters (i.e., service principal id, key etc.) are not available as environment variables. I don't think it's recommended to access these directly from the bash script. @TingluoHuang - Please correct me if I'm wrong here.

Regarding your requirement, I can think of two options:

1. You can create a custom task for talking to terraform. In this case, you will have access to the passed service endpoint through task library.
2. You can store the secrets (service principal id, key etc.) as a release variable, which should be available to the script.

[andreacassioli]

@amaljg,

I do not think the options you mentioned are viable, at least from my perspecitve:

1. if I use bash is because I do not want to spend time implementing a custom task! Using bash allows me to run the same script on my machine as well as in the pipeline
2. Why storing release variable should be safer? What if those variables change over time?

It looks to me that no access to the service principal is a serious limitation that reduces the use cases for this task.

[andreacassioli]

Just to put a bit more context: my starting point was

https://open.microsoft.com/2018/05/22/cicd-azure-terraform-ansible-vsts-java-springboot-app/

in which they use bash and store secrets in the release variables as you mentioned. This is quite annoying if you have many pipelines. And I do not see why it is safer.

[oskarm93]

@andreacassioli Being able to pull out service principal credentials from a service connection in Azure CLI would be a security hole. In my company, someone with higher privileges than me sets up the service principal and sets up the service connection. This means I can use it, but I can't just steal credentials and take them home.

However, if you own the credentials and time's of the essence, option 2. is the best one.
You can just inject those secret variables straight into a custom script. If you parameterize your script properly, you can run it on VSTS and locally in the same way.
If your service principal credentials change over time, having them in secret variables or service connection would make no difference. You'd have to make that change regardless. If you have many pipelines, consider using variable groups (even if for 1 variable) or YAML definitions.

[kuvinodms]

@xenalite - Agreed. Thanks for your inputs.
@andreacassioli - Let us know if you have any other queries regarding this.

[andreacassioli]

I see the security concern. My use case is exactly what @xenalite describes. Even though I own the credential (we are a small team, basically we all share the admin burden...) I do not need to see the credential but just use them as secrets. This is what we can do for instance using a quite convenient task that pulls secrets from key vaults.

Anyway, it seems I will have to define variables...

Thank you for the feedback guys.

[kuvinodms]

@andreacassioli
Have a look at this https://docs.microsoft.com/en-us/azure/devops/pipelines/release/variables?view=vsts&tabs=batch#custom-variables

You can store sensitive values in a way that they cannot be seen or changed by users of the release pipelines. Please try this functionality, hope this will fulfill the requirements here.

[sachinma]

#8819 is trying to fix this issue

[andreacassioli]

@sachinma awesome! when is it planned to be released?

[sachinma]

We will start rolling it out this week and should reach all accounts in around 2-3 weeks.

[vineetmimrot]

The fix has been rolled out. Please let us know if you are still facing the issue.

[oskarm93]

@vineetmimrot So you approved a change that would expose credentials even though it was explicitly mentioned that it would be security role?

[rhummelmose]

@vineetmimrot So you approved a change that would expose credentials even though it was explicitly mentioned that it would be security role?

It is not a security hole. If you can use the service connection, you can do whatever and that is with the same identity as if you took the credentials elsewhere and used them.

[oskarm93]

@rhummelmose Let me refer you to my previous reply.

@andreacassioli Being able to pull out service principal credentials from a service connection in Azure CLI would be a security hole. In my company, someone with higher privileges than me sets up the service principal and sets up the service connection. This means I can use it, but I can't just steal credentials and take them home.