如何允许外部访问私有的Azure DevOps NuGet feed

Question

情况如下：

• DevOps Org A 维护一个私有 NuGet feed
• DevOps Org B 需要在其管道中使用来自上述 feed 的包

当前解决方案涉及以下内容：

• 将来自 Org B 的用户 U 作为访客添加到具有利益相关者角色的 Org A DevOps 中
• 为用户 U 在 Org A 中创建 PAT，仅具有 Packaging -> Read 范围
• 使用 PAT 在 Org B 中为 feed 注册服务连接
• 在 NuGetCommand 恢复任务之前，在 Org B 管道中使用 NuGetAuthenticate 任务

问题在于用户 U 可以登录 Org A 的 DevOps 并查看面板、工作项、成员等。

问题是如何限制访问，以便来自 Org B 的任何人只能从 Org A 的 feed 中恢复包，而不能执行其他任何操作？

我已经在 Org A 的 DevOps 中将每个权限都设置为 Deny。

只要我将 View project-level information 设置为 Deny，Org B 管道就会失败，并显示 404（未找到 - VS800075：id 为 'vstfs:///Classification/TeamProject/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' 的项目不存在，或者您没有权限访问它。 错误。

- CyberDude

Answer 1

不需要在Org A DevOps中添加来自Org B的用户U。因为你只需要一个具有Packaging->Read范围的PAT，这个PAT来自于Org A。你可以让Org A中任何具有NuGet feed访问权限的用户为你生成一个PAT。

或者你可以要求Org A的项目集合管理员组中的任何用户创建一个新的普通用户账户作为服务账户。然后你可以要求他们从Org A的这个服务账户生成一个PAT。

通过以上方法，你不必担心来自Org B的用户能够登录到Org A的DevOps。

- Levi Lu-MSFT

---

这就是我们最终采取的做法。我知道有PAT，但我担心这样的PAT会提供与PAT创建者持有的所有权限。因此，即使一个人无法仅使用PAT登录Dev Ops，他们仍然可以使用CLI来提取不需要的数据。 - CyberDude

PAT可以被精确地定制。您可以安全地使用它。如果您创建一个仅具有“Packaging -> Read”范围的PAT，则您的访问仅限于只读取该软件包。它无法用于提取其他数据。您是否接受上述答案？如果您认为其符合要求，谢谢！ - Levi Lu-MSFT

我不建议分享PAT（个人访问令牌）。它们有效地代表着特定身份的密码。它们可以被限制使用，但这个限制只扩展到操作类别，而不是具体资源。如果你必须使用这种策略，请至少使用某种专门用于此特定目的和特定客户的“服务账户”，并且绝对不要使用人类用户的身份。 - Jonathan Myers

是的，这确实感觉像是一个权宜之计。毕竟，P代表个人，所以应该将PAT用于自己的目的，而不是共享。我寻找这些神秘的“服务帐户”，但无法找到实际创建它们的方法（如果可能的话）。 - CyberDude

@CyberDude你是怎么让它工作的？我有同样的情况，简直不敢相信这不能正常运作。 - pantonis

通过使用由托管NuGet feed的组织中的用户生成的PAT。然后，在客户端组织中，您添加一个类型为NuGet的服务连接，使用PAT，然后在管道中使用它。您需要记得在过期之前更新您的PAT，尽管ADO会及时向您发送提醒电子邮件。 - CyberDude

Answer 2

如果两个组织都连接到同一个 Azure Active Directory，则上游源可能会提供您所需的内容。

1. 在 Org A 的源中，将视图设置为对 Azure Active Directory 中的每个人可见（抱歉，这是跨组织上游的最低可见性）。@Local 视图可能是一个不错的选择，因为每个已完全摄取到源中的软件包版本（无论是通过直接推送还是通过从上游下载）都会自动添加到该视图中。

2. 在 Org B 中，创建一个新的源或使用现有源。

3. 确保 Org B 中的源用户具有适当的权限。 "读取者" 只能使用已经完全摄取到源中的软件包版本。 "协作者" 还可以使用和摄取（通过使用）源中存在的软件包版本。

4. 在 Org B 的源中，将上游添加到 Org A 的视图中。

5. 将 Org B 中的客户端设置为从 Org B 的源而不是 Org A 的源还原软件包。

请注意，我们缓存上游信息，因此在发布到 Org A 的源并在 Org B 中可见的软件包之间可能会有多达数小时的延迟。我们计划改进，但目前没有时间表。

- Jonathan Myers

---

不，这两个组织完全独立（不同的公司）。公司A以NuGet包的形式发布库。公司B希望许可该NuGet包以在自己的项目中使用。 - CyberDude

不幸的是，Azure DevOps 安全模型无法支持这种类型的事情。 - Jonathan Myers

@JonathanMyers 这个模型非常基础，为什么不支持呢？我的天啊。我想让一些用户只能访问 nuget 源。在 Azure DevOps 中没有其他的东西。这有多么的不合理啊？这是一个非常常见的场景。当我只需要他访问 nuget feed 时，为什么还要给一个用户访问 Azure DevOps 的权限呢？ - pantonis

由于Azure Artifacts是Azure DevOps的一部分，因此利用了Azure DevOps的身份验证、许可和授权组件。 - Jonathan Myers

Answer 3

你没有提到你是否已经尝试过这个，保留 View project-level information 设置为 deny，你可以尝试将 guest 用户 u 明确添加为 Reader 到 Org A 中的软件包源。

编辑软件包源权限

- Eric Smith

---

我尝试过了，但它不起作用。我认为这是因为在DevOps中安全性的“优先级”中，“拒绝”比“允许”更强。 - CyberDude

Answer 4

我们有一个类似的问题，但也希望将共享的工件限制在特定的反馈视图中。

因此，我们决定创建一个辅助项目，仅包含一个反馈。该反馈是空的，但使用您的原始反馈作为上游源，范围限定在我们想要共享的视图。

辅助项目只有一个用户（服务用户），该用户对辅助反馈具有读取访问权限。我们可以使用服务用户的 PAT 进行共享。

由于辅助项目实际上为空，因此我们不会冒险共享任何不需要的信息（代码、问题等）。

- markus