3

The situation is as follows:

  • DevOps Org A maintains a private NuGet feed
  • DevOps Org B needs to use packages from the above feed within its Pipelines

Current solution involves:

  • adding a user U from Org B as a guest in Org A DevOps with Stakeholder role
  • creating PAT for user U in Org A with just Packaging -> Read scope
  • using the PAT to register a service connection for the feed in Org B
  • using NuGetAuthenticate task in Org B Pipeline before the NuGetCommand restore task

The issue is that user U can log in to Org A's DevOps and view boards, work items, members, etc

The question is how to restrict access so that the only thing that anyone from Org B can do is restore packages from Org A's feed and nothing else?

I have set every permission to Deny on user U's Permissions screen in Org A's DevOps.

As soon as I set View project-level information to Deny, the pipeline in Org B fails with a 404 (Not Found - VS800075: The project with id 'vstfs:///Classification/TeamProject/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not exist, or you do not have permission to access it. error.

CyberDude
  • 8,541
  • 5
  • 29
  • 47

4 Answers4

2

There is no need to add a user U from Org B in Org A DevOps. Since you only need a PAT with Packaging -> Read scope from Org A. You can just have any user in Org A(who has the access the permission to the NuGet feed) generate a PAT for you.

Or yon can ask any user in Project Collection Administrators group of Org A to create a new normal user account as a service account. And then you can ask them to generate a PAT from this service account of Org A.

In above ways, You donot need to wrong about users of Org B can log in to Org A's DevOps.

Levi Lu-MSFT
  • 27,483
  • 2
  • 31
  • 43
  • This is what we eventually ended up doing. I knew about PAT's but I was wary that such a PAT would offer all the permissions that the PAT creator holds. So even if one could not log into Dev Ops with just the PAT, they could still use it with CLI to extract unwanted data. – CyberDude May 25 '20 at 12:26
  • The PAT can be precisely tailored. You can use it securely. if you create a PAT with only `Packaging -> Read` scope, then your access is limited to read the package only. It cannot be used to extract other data. Can you accept above answer? if you think it qualifies as the answer. Thanks! – Levi Lu-MSFT May 26 '20 at 01:37
  • I cannot recommend the sharing of PATs. They are effectively passwords representing a particular identity. They can be scoped, but that scoping only extends to categories of operations, not particular resources. If you must use this strategy, *please* at least use some sort of "service account" specifically dedicated to this particular purpose and this particular customer, and *definitely do not* use a human user's identity.. – Jonathan Myers May 26 '20 at 15:22
  • Yes, it does feel like just a workaround. After all the P stands for Personal, so one should use the PATs for their own purposes, not for sharing. I looked around for these mythical 'service accounts' but couldn't find an actual way to create one (if it's even possible). – CyberDude May 27 '20 at 12:17
  • @CyberDude how did you manage to get it work. I have the same scenario and I cannot believe that this is not working. – pantonis Apr 04 '22 at 12:24
  • By using a PAT generated by a user in the org that hosts the NuGet feed. Then, in the client org, you add a Service Connection of type NuGet using the PAT and then you use this in your pipelines. You need to remember to renew your PAT before it expires, though ADO is kind enough to send you a reminder email in time. – CyberDude Apr 05 '22 at 09:53
0

If both orgs are connected to the same Azure Active Directory, upstream sources may get you what you want.

  1. In the feed in Org A, set a view to be visible to everyone in your Azure Active Directory (sorry, that's the minimum visibility for cross-org upstreams). The @Local view is probably a good choice, because every package version that is fully ingested into the feed (whether by a direct push or by downloading through an upstream) is automatically added to that view.
  2. In Org B, create a new feed or use an existing one.
  3. Make sure users of the feed in Org B have appropriate permissions. "Readers" can only use package versions that have already been fully ingested into the feed. "Collaborators" can additionally use and ingest (by using) package versions that exist in the feed's upstreams
  4. In the feed in Org B, add an upstream to the view in Org A.
  5. Set your clients in Org B to restore packages from the feed in Org B instead of the feed in org A.

Note that we cache upstream information, so there may be a delay of up to several hours between publishing to the feed in Org A and the package being visible in Org B. Improvements are planned, but I don't have a timeline I can share at this time.

Jonathan Myers
  • 789
  • 4
  • 12
  • No, the two orgs are completely separate (different companies). Company A publishes a library in the form of a NuGet package. Company B wants to license that NuGet package for use in its own project. – CyberDude May 22 '20 at 19:37
  • Unfortunately, the Azure DevOps security model isn't set up to support that kind of thing. – Jonathan Myers May 26 '20 at 15:25
  • @JonathanMyers this model is a very very basic one. How can it not be supported? For gods sake. I want to have some users only having access to nuget feeds. nothing else in the azure dev ops. How illogical can this be? A very ver common scenario. why should I give access to a user to azure devops when only I need him to access the nuget feed – pantonis Apr 04 '22 at 12:21
  • Because Azure Artifacts is a part of Azure DevOps, and thus leverages Azure DevOps's identity, licensing and authorization components. – Jonathan Myers Apr 06 '22 at 14:39
0

You don't mention if you tried this yet, preserving the View project-level information set to deny, how about you explicitly add the guest user u as a Reader to the package feed in Org A.

Editing permissions for a feed

Eric Smith
  • 2,340
  • 12
  • 16
  • I tried this, it doesn't work. I think because the security "precedence" in DevOps is "deny" is stronger than "allow". – CyberDude May 25 '20 at 12:28
0

We have a similar problem, but also wanted to limit the shared artifacts to a certain feed view.

Therefore, we decided to create a helper-project that only holds one feed. This feed is empty but uses your original feed as an upstream source scoped to the view that we want to share.

The helper project has only one user (a service user) that has read-access on the helper-feed. We can use the service user's PAT for sharing.

As the helper project is practically empty, we do not risk to share any unwanted information (code, issues etc.)

markus
  • 511
  • 1
  • 4
  • 15