Search code examples
azureazure-devopsazure-pipelinesazure-pipelines-yamlpipeline-security

Should I Remove the Build Service User in Azure DevOps and Manually Manage Access to Service Connections?


I'm working on a project in Azure DevOps, and I’m trying to figure out the best way to manage access to my service connections (like Azure Container Registry). By default, Azure DevOps uses the Build Service User to handle access to these service connections, which works fine for most pipelines. However, I wanted tighter control, so I removed the Build Service User and instead added my username manually to manage access.

Here's what I did:

  1. I went to Project Settings > Service Connections and removed the Build Service User from the security settings.
  2. I added my username, so now the pipeline uses my credentials instead of the build service user.
  3. Under Pipeline Permissions, I manually added the YAML pipelines that should use the service connection.

After doing this, I got a message saying: "The following YAML pipelines are allowed to use this resource. YAML pipelines from other projects are not shown in this list. All Classic pipelines can use this resource."

So now I’m wondering:

  • Is this the right approach for managing access, or am I overcomplicating things by not just letting the Build Service User handle it?
  • Has anyone else done something similar, and how did it work for you?
  • Would you recommend sticking with the Build Service User, or does manually managing permissions give you better control?

I feel like managing the Build Service User might be simpler in the long run, especially if we add more pipelines. But at the same time, I want to make sure only the right pipelines (or users) are interacting with the service connection. Has anyone had direct experience with this kind of setup and can share any pros/cons?


Solution

  • According to your description, there seems to be some misunderstandings on how pipeline build service accounts are used.

    You probably created a docker registry service connection that should authenticate access to ACR against an underlying service principal (app registration) in your Microsoft Entra ID (formerly AAD). When your pipeline task like Docker@2 consumes this service connection, it will use the credentials of this underlying service principal to pull/push images from/onto your ACR, instead of using your personal account credentials.

    Pipeline runs authenticate as pipeline build service accounts to access only Azure DevOps resources like Azure Repos, Artifacts, environments, variable groups and service connections etc.

    If you removed the pipeline build service account from the security settings of your ACR service connection, the pipeline runs will be unable to consume this service connection.

    With those being said, please review if you have to prevent pipeline build service accounts from accessing the service connection resource, since the pipeline build service accounts don't access your ACR directly and your user account credentials are not used by default, either.

    See more details on Understand job access tokens - Azure Pipelines | Microsoft Learn.