Restricting Access with Authenticated Repositories

By the end of this lesson, you will be able to:

  • Explain why an organization would restrict access to specific repositories
  • Describe how token-based authentication controls repository access in Package Manager
  • Identify the components a user needs to consume an authenticated repository
  • Recognize the role of a date-based (snapshot) CRAN source

Introduction

Many customers have multiple teams or instances of Posit products sharing a single Package Manager instance. This often creates a need to restrict particular repositories so they are available only to particular teams or instances. Package Manager supports this through authenticated repositories.

For example, a team of package developers might need a repository containing packages still in development and not ready for production use. By marking that repository as authenticated and issuing read tokens to the people and systems that should reach it, you ensure that only that team can install those packages. The same pattern applies to regulated development environments where access to certain packages must be limited to specific teams or users.

This lesson explains how authenticated repositories work. The accompanying lab has you create a date-based CRAN source, expose it through an authenticated repository, generate a read token, and configure a user to consume it.

NoteTimings for this chapter
  • Reading time: 10 minutes
  • Documentation reading time: 10 minutes
  • Hands-on exercise time: 15 minutes
TipRequired Reading

How Authenticated Repositories Work

By default, repositories in Package Manager are open: anyone who can reach the instance can install from them. Marking a repository as authenticated changes that, requiring callers to present a valid token before they can read from it.

Access is granted by issuing tokens scoped to specific repositories and permissions. A token created with the repos:read scope for a given repository allows reading (installing) from that repository and nothing more. Because access is controlled by who holds the token, distributing the token only to the intended team or instance is what enforces the restriction. Tokens should therefore be treated as secrets and stored securely, for example in a password manager.

What the User Needs to Consume It

To access an authenticated repository, users must configure their client to present the token. The exact mechanism differs by language, but in both cases the token is the credential that proves the caller is allowed to read the repository.

R

For R users, three pieces work together:

  • A .netrc file holding the credentials (the literal login __token__ and the token as the password), permissioned so that only the user can read it.
  • An .Rprofile that adds the authenticated repository to the repos option and configures R to download using curl with the .netrc file.
  • The repository URL, which points at the specific authenticated repository on the Package Manager instance.

With these in place, R installs packages from the authenticated repository transparently, and you can confirm it is working by checking where an installed package came from.

Python

Python clients present the same token, embedded in the repository’s index URL as the user __token__ (for example, https://__token__@packagemanager.example.com/pypi/latest/simple/):

  • pip reads the index URL from PIP_INDEX_URL, from pip config, or from a configuration file, and resolves the matching token from a .netrc file.
  • uv reads the index URL from UV_INDEX or uv.toml, and likewise resolves the token from .netrc.

A single .netrc file can therefore serve both R and Python clients on the same machine. See Configuring authenticated repositories for Python users for the full details.