How to safely put credentials in a custom Azure DevOps task?

1
votes

We provide a library of custom Azure DevOps tasks (Azure DevOps extensions provided through a private Visual Studio Marketplace) to our stakeholders in order to provision resources to Azure. Many times we need to switch an elevated service account to perform operations that are not allowed by the service principal of the Azure service connection, e.g. adding users to groups, or reading secrets from a central key vault.

What is the best way to establish this security context securely? Currently we have the credentials of this elevation service principal hard coded in our task code. Unfortunately this is easily retrieved by our stakeholders because the code is readable within the same Azure DevOps job context, so it is not safe.

Does Azure DevOps provide a special task context that we can utilize to encrypt the service principal credentials somehow? Are there any other routes to securily perform operations from a centralized security principal from within these custom tasks of ours?

2
azureazure-devopsazure-pipelinesazure-pipelines-build-task
docs.microsoft.com/en-us/azure/key-vault/secrets/… – Alexan
The problem is: the service principal of the service connection is not allowed to read from the central key vault. We have set up a central "elevation" service principal that is granted this access. We need to find a way to establish this security context from within the custom task without the user being able to reproduce it themselves. If I were to design this, I would add a mechanism to the marketplace in order to share a private token to the scope of the task. – Carl in 't Veld

2 Answers

0
votes

If you're using classic Releases you can define variables that you can reference in your steps with the syntax $(variableName). Variables can be made secret, so it's not possible to retrieve them.

enter image description here

Alternatively, if you're using yaml multi-stage pipelines then variables can be defined directly in the yaml. In this case you'll probably what to use a variable group so that you define the secrets either directly in the variable group or link to a key vault.

For the requirement of not allowing new pipelines to be set up to use variable groups you could investigate the Library assets security roles and / or putting your pipelines in a separate Azure Devops project within your organisation.

Depending on what your tasks are doing you might be able to rewrite them to use a task that makes use of the built in Azure Resource Manager service connection, for example the AzurePowerShell@4 task, rather than using your own service principal credentials, as another solution entirely.

0
votes

First thought is that as soon as pipelines are capable of accessing the secrets then we are bad.

Not sure if I understand you well. But if you don't want those stakeholders to access the secrets in your task context within some specific pipelines, you can consider combining the Variable Group and Pipeline Security.

1.For Library(Variable Group): Store the secrets here and enable Change variable type to secret. Then manage its security here:

enter image description here

Normally the stackholders can't access the variable group unless you grant access to them. I suggest you create a group to manage the permissions of those stackholders.

2.For pipelines: You can limit the view/edit related permissions in pipelines' security:

For all pipelines: enter image description here

For one specific pipeline: enter image description here

You can deny the View/Edit related permissions and only allow Queue build permission so that the stackholders can run your build but not see details about how you define the task context:

enter image description here

Hope it helps :)