Private packages access permissions per repository or organisation

[ben-bourdin451]

Packages

Question: Is there a way to give read access to packages at a repository level or enable all packages to access other packages inside the organisation regardless of which repository it's in?

Body

Context:

We are publishing a lot of npm packages via a monorepo setup (a single private repo). These packages can end up being used by other repositories, in completely different contexts. We therefore need to give permissions from other repositories to access these packages.

I couldn't find anything relating to this in the public docs or in this community. Currently it only seems to be possible to manage npm package access individually in its settings: https://github.com/orgs/{org}/packages/npm/{package}/settings.

Why?

To solve the above we have to manually edit permissions for every single package. This gets exponentially worse if we increase the number of repositories that require access.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[ben-bourdin451]

To be honest this is currently the single biggest problem that is making me question whether or not to use github packages and switch to another provider

[gregsienkiewicz]

The fact that we have to explicitly go in an add each repository via the Manage Actions access is painful. Also, problematic as we need to do so for every new repository created.

Has anyone found a way to grant this at the Organization level? It'd be great if we can just say trust all repositories in our Organization to have access.

[vit0rrr]

I'm Brazilian, so please excuse the grammar mistakes

1. Use a Private Package Registry
   A robust solution is to use a private package registry that offers granular access control. Some popular options include:

GitHub Packages: Since you mentioned using GitHub, you can use GitHub Packages in conjunction with GitHub Actions to automate publishing and access control. Set up a private registry on GitHub and use permissions policies to manage access.

Nexus Repository Manager: This is a tool that can be used to manage npm package repositories, with fine-grained access controls.

Verdaccio: A local npm registry that allows you to configure access permissions on a per-package basis.

2. Configure Permissions in GitHub Packages
   In GitHub Packages, you can configure access permissions directly at the organization level. To allow all repositories in the organization to access packages, follow these steps:

Configure an Authentication Token:

Create a personal access token with appropriate permissions for reading packages.

Add Settings to .npmrc:

In the .npmrc file of the repositories that need access to the packages, add the settings to use the authentication token. For example:
ini
Copy code
//npm.pkg.github.com/:_authToken=YOUR_TOKEN
@your-org:registry=https://npm.pkg.github.com
Set Permissions on GitHub:

In each package's settings, you can set permissions for the entire organization, allowing any repository in the organization to have read access.
3. Automate Permissions Configuration
To avoid manually setting permissions for each package, you can automate this process using the GitHub API or scripts that interact with your package registry.

Using the GitHub API:
Generate an Access Token:
Generate an access token with permissions to manage packages.
Use Scripts to Set Permissions:

Use scripts that call the GitHub API to set read permissions on all packages at once. For example, a Node.js script using axios to call the API:

javascript
Copy code
const axios = require('axios');

const GITHUB_TOKEN = 'YOUR_TOKEN'; const ORG_NAME = 'your-org';

async function setPackagePermissions(packageName) {
const url = https://api.github.com/orgs/${ORG_NAME}/packages/npm/${packageName}/permissions; const config = {
headers: {
Authorization: token ${GITHUB_TOKEN},
Accept: 'application/vnd.github.v3+json'
}
}; const data = {
permissions: {
read: true
}
}; await axios.put(url, data, config); }

async function main() {
const packages = ['package1', 'package2']; // List of packages
for (const pkg of packages) {
await setPackagePermissions(pkg); }
console.log('Permissions configured successfully.'); }

main().catch(console.error);

[ben-bourdin451]

Funnily enough chatGPT gave me a very similar answer.

It's true that it can be automated but I don't think this is an elegant solution when the access token used to pull the NPM package has access to those repositories already but is still denied unless this setting is enabled.

IMO this should be made possible from within GitHub organisation settings to prevent having to spend time, effort and pay for GH actions minutes to circumvent the issue.

[gregsienkiewicz]

Hi, thanks for the suggestions.

Controlling access with a personal access token (PAT) is certainly a solution; especially for package repositories that have inherited access enabled this is quite simple. Our challenge is that PATs are inherently problematic to secure. With classic PAT there is no audit trail nor inventory at the Organization level as to what access is being granted and used by these.

This is why we want to completely stop the usage of classic PATs in our environment. With the Workflows, the GITHUB_TOKEN is generated automatically for each workflow job. This is a short lived token - ephemeral. So if it leaks or a bad actor exfiltrates the token, the probability of compromise via this credentials is lower as it likely will expire before they are able to do anything malicious. We can also restrict easily at workflow design what permissions the token will have - for instance packages: read only to follow the principle of least privilage.

With the Manage Actions access at the package repository level we are able to specify which repositories can access the package - for instance ghcr for containers. The issue is that we have a lot of repositories and new ones are added on a regular basis. Having the ability to grant all our repositories - current and future - access to the package repo would reduce the overhead on our SCM admin team. Especially for shared resources, such as our base container image.

Cheers.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬