Terraform-provider-azuredevops: Azure DevOps PATs for CI

[FernandoMiguel]

Is there a pattern for issuing and using PATs in CI/azure devops pipelines?

I need to auth against Azure DevOps pipelines.
the provider https://registry.terraform.io/providers/microsoft/azuredevops/latest/docs only talks about Personal Tokens (PATs) 

what’s the approach here? create an AD user to create this PAT?
I don't want to use one associated with my corporate account

Can a PAT be issued for a Service Principal account?

[xuzhang3]

Hi @FernandoMiguel You can create PAT with any account as long as this account have the access permission to your Azure DevOps ORG. https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page

[FernandoMiguel]

But how do I invite a service principal, for example?
I tried with the ID with no luck.

Is there a way to authenticate against Azure devops resources (for example agent pool data source) without a PAT being provided in the terraform provider config block?

[xuzhang3]

Every operation need granted permissions. In ADO provider, you cannot manage the resources without PAT. A workaround in your scenario:

1. Create a new account in AAD
2. Add this account as the admin of your organization
3. Create a PAT for the new AAD account.

[FernandoMiguel]

Yeah that seems to be the way around this, which prevents this from being deployed at scale in a programmatically way.

Is there a restriction for ADO to only use PAT?

From the link you provided, other methods of auth are available.

[whiskeysierra]

Can't you just use the build service identity that executes your pipeline? We assigned that one all the permissions it needs.

[FernandoMiguel]

@whiskeysierra care to explain that a little better?
the docs say the provider needs a PAT to authenticate to ADO https://registry.terraform.io/providers/microsoft/azuredevops/latest/docs

org_service_url - (Required) This is the Azure DevOps organization url. It can also be sourced from the AZDO_ORG_SERVICE_URL environment variable.

personal_access_token - (Required) This is the Azure DevOps organization personal access token. The account corresponding to the token will need "owner" privileges for this organization. It can also be sourced from the AZDO_PERSONAL_ACCESS_TOKEN environment variable.

I already have a service principal, and use that for the AzureRM provider

[whiskeysierra]

You can pass the $(System.AccessToken) pipeline variable. It doesn't have to be a personal access token. No need to have a service principal for DevOps.

[whiskeysierra]

env:
  AZDO_PERSONAL_ACCESS_TOKEN: $(System.AccessToken)

You need to set that on your pipeline task that executes terraform.

[FernandoMiguel]

Thank you. I'll give it a try tomorrow.

[FernandoMiguel]

that was an awesome tip @whiskeysierra
i hadnt seen anywhere refer that.
can you provide me with some more context of how it works?

can i use that identity to also access a storage account without having to use a service principal or a storage account principal access key?

[whiskeysierra]

that was an awesome tip

Happy to help 🎉

i hadnt seen anywhere refer that.

I just tried it and it worked. I think it's just an unfortunate naming in the terraform devops provider. If it would be called access token and you can either pass a personal or a system one, that would be easier to understand.

can you provide me with some more context of how it works?

They way I understand it is, that there are two kinds of identities in DevOps:

1. Normal (usually human) users
2. Build service identities

The build service identities are managed by DevOps itself, so you can't use them to login for example. But apart from that they are both identities that can have permissions and tokens to authenticate against the API.

can i use that identity to also access a storage account without having to use a service principal or a storage account principal access key?

I don't think so, no. While I do believe that DevOps uses Azure Active Directory under the hood to implement Build Service Identities, they don't expose this or allow you to use those identities outside of DevOps. For anything outside of DevOps I usually use a Service Principal and a service connection (of type Azure Resource Manager) to interact with Azure itself.