Maven Virtual Registry: Permissions policy

🔭 Issues plan

1. Maven Virtual Registry: Database models (#467972 - closed).
2. Maven Virtual Registry: Permissions policy (#467977 - closed). 👈 You're here.
3. Maven Virtual Registry: Registry models API (#467979 - closed).
4. Maven Virtual Registry: Maven API endpoint (#467982 - closed).
5. Maven Virtual Registry: Cache logic (#467983 - closed).
6. Maven Registry: Cached responses destruction (#468113 - closed).
7. Improve workhorse dependencyproxy logic (#461561 - closed).
8. Maven Virtual Registry: Documentation (#468115 - closed).
9. Maven Virtual Registry: Performance review (#468116 - closed).
10. Maven Virtual Registry: feature flag cleanup (#468117).

🗒 Description

The Maven virtual registry will need a new set of permissions.

The target will be an instance of VirtualRegistries::Packages::Maven::Registry but we will need to leverage the group policy to apply the rules:

• read_virtual_registry
  • For Users
    • Authenticated users only. Anonymous users should not have any permission.
    • Must have read_group on the target (root) Group.
  • For DeployToken
    • Must have the read_virtual_registry scope. This is a new scope to introduce.
• create_virtual_registry, update_virtual_registry, destroy_virtual_registry.
  • For Users, granted to direct maintainer+ users of the target (root) Group.

🔮 Alternatives to explore

It might be more efficient to have a wrapper class around Group (Example). Because we always require a (root) Group, we should be able to create that wrapper and because it's a new wrapper, we can have a policy from scratch (but still reference the Group policy to reference the read_group permission).

Objects below the (root) Group, such as the Upstream can simply delegate to the parent level up to Registry, where we can instantiate the wrapper class on the (root) Group and delegate to that.