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 Servicestill can access the repository, though:
Any clues what I am doing wrong here? Is this possible at all?



fooandbarto accessInnerSourcewhile - at the same time - preventfoofrom accessing accessingbaror 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