Restrict development staff from downloading artifacts from Internet

I am using Nexus 3.29.2 OSS. I have a particular scenario where I do not want development staff to be able to download artifacts from maven central (internet). They should only be able to use what already exists in that repository.
A specific admin role should be able to fetch/download artifacts from maven central, which can then be used by other staff.
Is it possible to configure user permissions/privileges like this ?

It sounds like you’re trying to build a golden repo which is considered an anti-pattern. We recommend using Nexus Firewall to prevent undesired packages from entering your repositories, or Nexus Lifecycle to keep you protected through complete software development lifecycle.
However, if you insist on building your golden repo, you will not be able to accomplish this using proxy repository, because there is no granular permission that would allow user to only download pre-existing content and prevent from downloading new content. You can restrict what content can be served (and downloaded from remote) based on their path using either Routing Rules or Content Selectors, but this will require you to write down all allowed paths manually.
If you really have to restrict your users to be able to download only the pre-approved components, you would have to use a hosted repository where you manually upload your approved content. Please believe us, this is truly terrible, terrible idea.

Thanks Dawid for your response. I understand trying to create a golden repo is a bad idea, and I am not trying to build such. In my current config, I have maven-proxy and maven-hosted both in a group and Maven settings.xml is using group repo, which means both repos are available for downloads. And by setting the order, I am able to tell Maven/Nexus to serve contents from hosted repo first (if it exists), and if not go to proxy and get it.

However, problem is that I do not want entire development staff to be able to download contents from maven central (i.e. they should not be able to use maven proxy). An admin role should first be adding dependency to pom from a specific machine, such that those dependencies reach maven-proxy and then become available for entire development staff. Is it possible to configure this ? I have not been able to do it. Either maven-proxy needs to be in group (which means it is available for all), or it is not in group (which means no-one will be able to use it).

On your above note regarding Nexus Firewall, I am wondering how will this work. Assume that I want to use Maven compiler plugin version 3.8.0, which has a dependency on X. If Nexus Firewall believes X has a vulnerability, it might try to block X from being downloaded, and if that is the case, how will Maven compiler version 3.8.0 work at all ?

The only way to achieve something like this is to have the admin download the component, then upload it into a hosted repository. This is what we call a golden repository. Please check out The Golden Repo is NOT the Answer, the Golden Policy is for why we think this is an anti-pattern.

With Nexus Firewall, the firewall actually only blocks new components from entering your repository. So if you previously approved the compiler plugin version 3.8.0, it will still be in your repository to allow your existing builds to continue working. Of course this means that you can continue to use things even after your policy no longer allows for it. This is where Nexus Lifecycle comes in. It allows your developers to continue working with the contents of the repository, but once they go to do a production build/deploy we block it from proceeding until/unless the problem is fixed or an exception to the policy is granted. (This is just my quick explanation, our sales team would be happy to explain further and to do a trial with you if you are interested in exploring our paid solutions further.)

1 Like

We’re taking a similar approach to what you’ve described. We had to prevent developers from downloading artifacts at the firewall (network firewall, not Nexus Firewall) and then had them all configure their IDEs and projects to exclusively use Nexus. We are still allowing them to use Nexus as they had previously used Maven Central directly but require all builds be scanned by Nexus IQ. We’ll be moving toward Lifecycle & Firewall to make that process a little easier and catch components at the IDE.