sonatype / nexus-public

Sonatype Nexus Repository Open-source codebase mirror
https://www.sonatype.com/products/repository-oss-download
Eclipse Public License 1.0
1.96k stars 579 forks source link

Nexus OSS permission nightmare #484

Open Daniel451 opened 1 month ago

Daniel451 commented 1 month ago

At first, I was amazed but the simplicity of Nexus OSS setup via a simple docker compose:

  nexus:
    image: sonatype/nexus3:3.72.0
    volumes:
      - nexus-data:/nexus-data

Really good work (yes, looking at you Harbor!). However, once the application was running, accessible via https-secured connections, the permission nightmares began. Somehow, even when the content selectors actually show me the correct contents in the preview, a content selector based privilege is just doing nothing (i.e., users cannot see anything when they want to browse a repo). Then, after hours of reading documentation, I came up with a wildcard privilege:

nexus:repository-view:docker:testrepo:hello-world:*

...which still doesn't offer the user to browse the testrepo/hello-world, thus I edited to:

nexus:repository-view:docker:testrepo:browse
nexus:repository-view:docker:testrepo:hello-world:*

...then users finally saw some content but somehow the browse privilege simply gives them access to the entirety of testrepo, including viewing stuff in the web-ui (not limited to hello-world, as any reasonable human would expect).

To make matters worse, users were still not able to use a simple docker login command (since ofc we want to hide functionality between multiple different permissions: the more the merrier).

How can something with such a clear and well-documented setup be this user unfriendly and complicated when it comes to permissions? What happened to having a simple UI where you can simply right click on some directory in some repo and simply add users or groups with nice little "view, download, push, delete, ..."-checkboxes? Instead, Nexus ships with close to 300(!) default permissions and I have to create even more content selectors, match these with privileges, match that with user roles, match these with groups, match that with users, and so on to achieve a simple "user xy has access to testrepo/hello-world".

Forgive my rant -- I was very close today to just switch this problem with Harbor's setup process.

Does anyone have any idea why the privileges above are not working as expected?

mrprescott commented 1 month ago

@Daniel451 Thanks for writing in, especially with this level of detail. Yes, the permission space is really large. We've had feedback from users large and small that this is an area that we could improve, and we have a few candidates that we're evaluating on how to do that.

Daniel451 commented 1 month ago

@mrprescott thanks a lot for returning and also replying that fast. I appreciate that as well as considering a simplification of the permission management. I guess the privilege system originates from LDAP / complex systems with multiple registries running for large user groups? I think having the ability to right-click on a registry (or some (sub-)path within a registry) and simply adding users or groups and the backend taking care of creating all the right permissions would already be enough (well, that and including some checkboxes for read, write, create, or something like that).

In the current state - again just personal opinion - it is only usable for use-cases where (a) permissions do not matter and thus you can just give -* to every user or (b) you have the resources to have a dedicated registry admin that pretty much does nothing else but maintaining the server, service, permissions, helping out users, ...

Given Nexus' flexibility to host pretty much any repository imaginable that is quite unfortunate. Low/cheap maintainability (and as self-explanatory as possible for end-users) would - again just personal opinion - enable lots of people to use Nexus.