Skip to main content

Securing Nexus Repository Manager

Below are a few suggestions for making your Nexus Repository instance more secure.

Limit IPs that can be reached from your Nexus Repository Host

Nexus Repository can be configured by an administrator to contact internal and external IPs for various reasons such as retrieving certificates, creating proxy repositories, dispatching events to remote URLs, and so on. You may limit the IPs that can be reached from the host machine running your Nexus Repository instance but note that doing so could block the main use case for some features.

For example, webhooks give administrators a way of integrating Nexus Repository with other systems (e.g. an auditing system, another Nexus Repository instance, or a lightweight listener potentially on the same host), typically in the same data center. Hence, limiting webhook destinations to, for example, IPs external to your data center effectively blocks the main use case for them.

Privileges and Service Account

  • Only assign the least necessary privileges to Nexus Repository users.

  • Create a dedicated operating system service account for running Nexus Repository - do not run as the root user. In addition, the service account must have read/write permissions to the $install-dir and sonatype-work directories and must be able to create a valid shell. See our System Requirements for detailed operating system service account recommendations.

Containerization

Running Nexus Repository in a Docker container may reduce the impact of a successful attack. Without containerisation, if a malicious person successfully exploits a service and gains root access, they could do damage to other services running on the host. On the other hand, containerising means a successful attack on that service is restricted to the container running that service.

The Nexus Repository 3 docker images are found at: https://hub.docker.com/r/sonatype/nexus3/.