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 creating an authenticated repository and sharing the access token only with that team, you ensure that only that team can reach 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 also configure their client to present the token. 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.