CODEWITHSUNDEEP
gitazureazure-devopsterraform
Neil
Neil

Reputation: 93

Cannot access Azure Devops Git repo from release pipeline using Service Principal

We're creating Terraform modules for Azure resources; we've given each it's own repo within a project, but when trying to call the module in the release pipeline, we get a time out, or an error 128.

This works outside the pipeline as a user with rights to deploy, however we're using a service principal to deploy within the release pipeline, which also has the correct rights; It looks like the issue is that Service Principals have no rights in Azure DevOps.

We've tried initially on a hosted build agent, but have just deployed our own private agent should we need to store any permanent information.

module "rg" { source = "git::https://dev.azure.com/*****/Terraform/_git/azmodresourcegroup//module?ref=v1.0" }

it looks like a rights issue, but can anyone point me at a workaround for this?

The error is either : C:\Program Files\Git\bin\git.exe exited with 128: Cloning into '.terraform\modules\

or a lengthy (30 mins) timeout.

Upvotes: 3

Views: 2063

Answers (4)

James G
James G

Reputation: 2914

As commented on the accepted answer, service principals CAN as of 2023 now clone Azure Repositories. The solution is detailed here - https://stackoverflow.com/a/76464678/1196415

Upvotes: 1

hansmbakker
hansmbakker

Reputation: 1234

You could consider using System.AccessToken. This predefined variable contains the access token of the build pipeline, and is not linked to a user.

You can read the token during a build.

Upvotes: 0

jorgeregula
jorgeregula

Reputation: 41

Just to spell it out a bit more, to reference a terraform module hosted in a private AzureDevOps repository / authenticating using a Personal Access Token.

module "example_module" {
    source = "git::https://INSERT_ORG_NAME:[email protected]/INSERT_ORG_NAME/terraform_module/_git/terraform_module?ref=INSERT_TAG"
}

Upvotes: 3

Neil
Neil

Reputation: 93

For anyone else facing this, the only way we could fix it was to use PAT from a user account; the Service Principal is still used for the build but adding a PAT from a user account with rights over the Project got around the issue, then we just used token replacement to ensure the PAT didn't end up in code.

Upvotes: 1

Related Questions