I am an administrator of an Azure DevOps Organization and have the following projects:
- InnerSource
- Foo
- Bar
I'd like the YAML pipelines of Foo
and Bar
to have read access to the private Git repositories in InnerSource
. This I got working by disabling the "Limit job authorization scope to current project" option for my organization and the respective projects. To my understanding, this lets the pipelines run under the Project Collection Build Service ({OrgName})
identity instead of the {ProjectName} Build Service ({OrgName})
identity.
Now I want to prevent pipelines in Foo
from accessing Bar
or vice versa. The info box on Understand job access tokens - Azure Pipelines | Microsoft Docs
reads like this isn't possible. However, there is also the section about "Managing build service account permissions", which reads differnt.
Also Default permissions and access quick reference - Azure DevOps | Microsoft Docs states:
By default, the Project Collection Build Service can read from all repositories. Any pipeline which runs within the project collection scope can potentially read any repository in the organization or collection. To remove this permission for a repository, change the Read permission to Deny for the Project Collection Build Service.
However, I do not find the Project Collection Build Service ({OrgName})
user in any security settings dialog. Also searching for it does not present me any results.
I tried to restrict permissions of [{OrgName}]\Project Collection Build Service Accounts
but this does not seem to have any effect. The repository can still be read from pipelines of a different project.
Here is a screenshot of the Repository Security configuration of Project Foo
. Pipelines from other projects running under the Project Collection Build Service
still can access the repository, though:
Any clues what I am doing wrong here? Is this possible at all?
foo
andbar
to accessInnerSource
while - at the same time - preventfoo
from accessing accessingbar
or vice versa. So far, I only have figured out to configure the both extremes: Limit access to the current project or open access to all resources within the organization... – Schwarzzz