Administration Best Practices

Access Control

Avoid using the default Anonymous Role in production

• By default, the Anonymous Role gives read access to all repositories and cannot be edited
• We recommend disabling anonymous access for production instances
• When required, anonymous access should be assigned a custom role to control the allowed repositories

Configure the Default Role for global permissions

• Default Role is automatically granted to all authenticated users
• At a minimum, assign the same privileges as the Anonymous Role

Avoid complicated content selectors

• Content Selectors are best used when designating write access to a namespace for a development team
• Use for partitioning a shared/mono repository
• Use for namespace enforcement on team repositories

Design your repository architecture in terms of granting access rather than restricting it

• Negative/exclusionary content selectors are not performant and are easy to override with other liberal permissions.
• Use team-specific repositories when restricting read access.

Component Repositories

Have your build servers use a group repository as their component registry

• Group repositories give you better control of the components available to your builds
• You will not have to later modify your build environment to manage the used repositories
• Group repositories are the key to maturing into a staging environment

Avoid many remote proxy repositories in a single group

• External requests are made for each remote proxy in the group
• Having a high number of remote proxies will increase latency for every request

Use HTTPS for remote proxies to protect against man-in-the-middle attacks

• Audit your proxies to make sure you are not using HTTP endpoints.

Use routing rules on all of your external proxy repositories

• Limit requests to external repositories to only the artifacts that are needed from that proxy

• Reduce exposure to public ecosystems

• Prevent dependency namespace confusion attacks

• Speed up read access on group repositories by reducing the external calls through the proxies

• Additional information:

• Repository Routing Helps Protect Against Dependency Hijacking Attacks

  • Namespace Confusion: Minimizing Risk with Nexus Repository
  • How to Control Nexus Groups with Effective Routing Rules
  • Routing rules configuration

Use a hosted maven repository for storing any files where you want clear namespacing

• Maven repositories don't limit the types of files which can be stored in the repository
• They have better support for enforcing namespaces over raw repositories when organizing your files

Use a single repository for development over creating a repository for each team

• Creating a repository for each team will lead to repository sprawl
• Many hundreds of repositories will increase management costs and lower performance
• Use Content Selectors to create namespaces for each team
• Use a new repository to lock down access to private artifacts

Content Replication

Use content replication to prefetch artifacts for remote teams

• Deploy components to a centrally hosted repository using proxies to distribute to remote teams
• Very effective for large binaries which may lead to latency and timeouts during remote builds

Content Replication is not a disaster recovery solution

• Configuration and metadata are not replicated so recovery using content replication will be inconsistent
• Content replication is managed through the remote server so there is no way for the central server to ensure transmission

Use content replication to better scale with proxy nodes

• The scaling with proxies model is far more effective with content replication
• The read-only nodes will already contain the content before it is requested

Avoid complicated mesh-like configurations for replication between multiple instances

• Bi-directional replication can become complicated when replicating to more than one node
• Consider using a central hub and spoke model to centralize all of your artifacts
• Deploy to the central hub when possible

Monitor replication log files for performance and consistency

• Use the logging to determine if all the content is being replicated promptly
• Adjust the timing of the scheduled task for content that is not immediately requested

Formats

Use specific maven groups for different policy types (RELEASE or SNAPSHOT)

• Avoid having a single MIXED policy repo housing both release and snapshot artifacts.

Use Nuget v.3 instead of v.2

• version 3 is much more performant than version 2

Use Docker Subdomain Connectors over connector ports

• Docker Subdomain Connectors are far more performant than connector ports

Push images to a Docker group repository

• Push images directly to a group repository
• On the group, you select a Writable Repository in the configuration menu

Cleanup

Control costs by cleaning up unused components from your repositories

• Improves system performance

• Reduces the need for additional system resources

• Reduce the risk of running out of space

• Helps developers find what they need faster

• Reduce backup costs

• Removes vulnerable components from the repository

• Additional Information:

• Staging Concepts

  • Cleanup Policies

Configure cleanup policies on all repositories where you are actively adding components

• Repositories can quickly grow if you are not removing as many components as you are adding
• Review static imported repositories bi-annually to determine if the artifacts should be retained

Balance what you are removing to match as much as you are adding to a repository

• Use component age (in the repository) to remove components roughly as fast as they are added
• Use the last download dates to only keep what is actively being used.
• Determine the optimal "last download" as a bit longer than how frequently you build your applications

Use cleanup to remove components that are no longer being used in your proxies

• Only retain the proxied components that are currently being used
• Cleanup artifacts that have not been downloaded in the last 30 days
• This is the most effective way to remove vulnerable components

Cleanup development artifacts faster than production

• A modern DevOps workflow can lead to a high number of regular builds
• Be aggressive when cleaning up builds that will never be released
• Use staging to make configuring cleanup easier
• Staging Concepts

Storage

Use blob stores to manage attached storage

• Blob stores are a location to store your artifacts, use them to attach additional storage or separate specific environments.

• These tasks are required for each blob store you create and will need to be configured and regularly run to clean up your repository.

• Admin - Cleanup unused asset blobs

  • Admin - Compact blob store
  • Repair - Reconcile component database from blob store

• Additional information

• Storage Planning

  • Blob Store Configuration
  • Blob Store API

Use blob store groups for fast-growing repositories

• Large artifacts in your hosted repositories may quickly use up your available space
• A blob store group is an easy way to add additional storage with any change to your repositories
• Blob store groups support mixed storage types to blend faster disks with slower object storage

Keep staging environments in the same blob store

• Staging moves artifacts from one repository to another
• The staging move action is a fast metadata update when components are in the same blob store
• Components will need to be copied when the staging repos are on different blob stores

Set a quota on your blob store

• Configure notifications when specific quota points are reached
• Regularly monitor your storage usage to avoid running out of space
• Test your notification configuration

Monitoring

Use external tools to monitor the health of your repository

• Monitoring and reporting are expensive operations that can negatively affect your repository
• Offload reporting to external tools to minimize the impact on production servers
• Use these endpoints for the real-time status of the server
• Consider using the Prometheus endpoint as a data source for other tools like Grafana or Elastic

Keep the audit log enabled

• The audit log is to track configuration changes
• This log is useful when troubleshooting/investigating issues

Use a test environment for running reports

• Use a recent backup to avoid putting strain on your production environment

Mine the log files to learn how your repository is being used

• Learn about the Logging options
• Use the nexus and request logs to track activity
• Details about each log file in the Directories documentation

Scripting

Use the inbuilt swagger-ui to test the REST API

• Find it inside the UI under Settings -> System -> API
• Submit API requests to ideas.sonatype.com
• REST API documentation

Avoid using the REST API when existing functionality would do a better job

• Cleanup policies are a scalable way to remove components than using the delete component API
• Native build tools do a better job at dependency resolution than searching the repository

Avoid testing scripts in production

• Use a backup of the server in a testing environment

Avoid using the Groovy scripting engine

• The scripting engine is not fully documented and will eventually be deprecated

• Scripts can cause performance issues and damage the server

• Scripts depend on unpublished internal objects which will change and break your code

• Use the REST API for all supported development

• A detailed article covering this change is here: Nexus Repository

Search results

No results found