A recent customer question highlighted a couple important points:
- Developers will unknowingly, or knowingly, end up working around any blockers to getting their job done. To all my friends managing Nexus Repository and Nexus IQ Server, as SDLC Tools service providers, we need to make it easy for our users, the developers, to onboard and comply with usage policies.
- OSS controls that exist within your repositories (source control and binary artifact) are only effective when your build and deployment pipelines are forced to download and upload from the repository
While working with our customers, our Customer Success team gets asked this question a lot: “How do I enforce usage of Nexus Repository Manager?” I could have created this post in the Nexus Repo topic, but I have chosen to post it here because, in most cases, the ultimate goal of enforcing usage is to provide some additional visibility and control over the components that are entering your software supply chain via your build and repository systems.
Lesson Learned
Restrict outbound network access on your build servers and monitor your build configurations for proxy server configuration
Use Case
I’ll start this story by saying that we discovered this by accident.
A ticket came in to Sonatype’s awesome support team describing a scenario where a Jenkins build was failing because download requests to Nexus Repository Manager (NXRM) were failing. With the context from the introduction above, this seems like the development team is trying to do the right thing and use NXRM. Upon debugging and checking the request.log for NXRM, we discovered that the requests from the Jenkins build agent were not making their way to NXRM; something else was causing them to fail.
When requests are being made but not being received by the application, especially if some Jenkins builds are working but others are not, that typically means that there is a “http proxy” configured for that build environment. This can be set many ways. The most common, for this case, is Maven’s settings.xml or via various Java -D command line arguments. While searching through the Jenkins log, we found the build step with the “mvn clean package” command, to which the developer had added the proxy settings via the command line. This explained why it was only this one job out of thousands per day that were failing.
Many HTTP proxies are configured in such a way that this is not a problem. But in this case, and others that I have worked with, the HTTP proxy is set up so that it allows requests from inside the network to go out to the Internet, but will block requests from inside the network from going to other hosts that are also inside the network. This is one of the reasons for the “nonProxyHosts” setting that you may see in the examples above.
Recommendation
If our only goal were to get the Jenkins build working, one solution to this use case would be to set the “nonProxyHosts”. However, I would advise against this due to our original problem statement: we want to enforce usage of Nexus Repository Manager.
By setting the nonProxyHost, thus retaining the HTTP proxy configuration, we would continue to allow the build to go directly to the Internet to download dependencies wild-west style.
A better solution is to work with the development team to understand why they have inserted this configuration into their build command. Most likely, they were trying something new and unaware of the other services available and this just happened to be the thing that worked. In that case, a simple conversation about the Nexus Repository Manager service and proper configuration without using the additional settings is all that is needed. Occasionally, something new is being used from the Internet, perhaps part of a new experimental application being developed. In this case, as an admin and owner of Nexus Repository Manager, you need to provide a process so that the development team can, for example, onboard a new proxy repository and safely experiment with new OSS components.
Happy Building!