Installing a private GitHub NPM Package in the same org

Background

I have a GitHub organization.

I have a (1) private repository in the org that has an NPM package published using GitHub Packages.

I have second (2) repository that I would like to use that package.

The Issue

When trying to run npm install inside GitHub Actions on (2) I get an error. It appears that the GITHUB_TOKEN doesn’t allow access to packages in other repositories in the same org.

The documentation from GitHub isn’t clear on what to do.

The only suggestion I’ve found is to use a PAT in that has access to do this. But that would mean that I’m giving my entire company access to my own personal GitHub account.

I’m hoping that isn’t the “correct” way, because that’s an SecOps nightmare for me. How would you offboard someone who’s PAT is used by an automated service? How do I prevent people from using my PAT to access my personal GitHub?

Can someone point me to a more secure and reliable way to do this?

Here’s my steps. You can see I’ve tried a few ways to do this with little success.

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
          registry-url: https://npm.pkg.github.com/
          scope: '@tailwind'
      - name: Cache node modules
        uses: actions/cache@v2
        env:
          cache-name: tailwind-node-modules-v2
        with:
          # npm cache files are stored in `~/.npm` on Linux/macOS
          path: node_modules
          key: ${{ runner.os }}-${{ env.cache-name }}-${{ matrix.node-version }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-${{ env.cache-name }}-${{ matrix.node-version }}-
            ${{ runner.os }}-${{ env.cache-name }}-
      - name: Authenticate with GitHub package registry
        run: echo "//npm.pkg.github.com/:_authToken=${{ secrets.GITHUB_TOKEN }}" > ~/.npmrc
      - run: npm install
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
      - run: npm run tsc
      - run: ./bin/ci/test_js

@mckalexee ,

Normally, the permissions of GITHUB_TOKEN are limited to the repository that contains your workflow.

  1. The GITHUB_TOKEN has the “read & write” access for some permissions in the repository that contains your workflow.

  2. The GITHUB_TOKEN has the “read” access for some permissions in other public repositories.

    • When downloading a public package from another repository, you can use GITHUB_TOKEN to access and download it in your workflow.

    • When downloading a private package from another repository, the GITHUB_TOKEN can’t access the private package. In this situation, you need to create a personal access token (PAT) that contains the “read:packages” permission.
      pat-access


About the security of the token in the workflow:

  1. The GITHUB_TOKEN is automatically created by GitHub when before each job begins in the workflow. We can’t customize the permissions of this token.
    Any users (include the external users) who can trigger workflows in your repository, they can use the GITHUB_TOKEN to do any thing (read & write) allowed by the permissions of the token in the workflow. In the workflow triggered from the forked repository, the GITHUB_TOKEN only has the “read” access for the allowed permissions.

  2. If you want the token only can read packages from GitHub Packages in the workflow, you can create a PAT that only contains the “read:packages” permission. In this way, users can only use this PAT to download packages, and can’t do other things.

  3. According above two points, I think extending the permissions of GITHUB_TOKEN may bring more security risk. Creating a PAT, you can customize and limit the permissions of the token so that other users can’t use this PAT to do some things you don’t want them do.

1 Like

According above two points, I think extending the permissions of GITHUB_TOKEN may bring more security risk. Creating a PAT, you can customize and limit the permissions of the token so that other users can’t use this PAT to do some things you don’t want them do.

I’m going to have to disagree here. Using a personal token that cannot be scoped to an org and that is dependent on one person is a not insignificant issue for us.

Now anyone working on an action has access to packages in other orgs that I’m a part of. And if I ever leave the company we have to create a new PAT, which means we have to track of what PATs we’re using and who they’re issued to and modify our offboarding process.

The solutions that I was hoping existed, and I’m surprised doesn’t, is either:

  1. the ability to issue a “Org Access Token” that allows certain tasks within the org,
  2. or the ability to control the permissions that actions have. Similar to AWS roles.

This isn’t a major issue, but it’s for sure an OPS headache.

I strongly concur, and it’s been raised before (I commented in this post why it doesn’t make sense that a GITHUB_TOKEN can’t access other repo packages in an organization - think multi-repo vs mono-repo setups).

I would love this to be addressed.

1 Like

@mckalexee ,

The solutions that I was hoping existed, and I’m surprised doesn’t, is either:

  1. the ability to issue a “Org Access Token” that allows certain tasks within the org,
  2. or the ability to control the permissions that actions have. Similar to AWS roles.

If you really need the features, I recommend that you can directly report a feature request here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

@mckalexee I’d love it if you could submit a feature request as @brightran suggested, since you’ve succinctly described the issue in this ticket.

I will also create one so at least GitHub can see there are several people interested in this. Based on that I would recommend anyone inhibited by this issue to do the same so there’s a better understanding of how many people this affects.

After more research I found that we are far from the only ones struggling with this, and lots of people have been struggling with it for a long long time.

That’s really disappointing because GitHub and Microsoft certainly have the resources to fix this problem if there was a desire to.

The fact that we still have to keep repeating the same reasons in the various community posts I’ve since found (but hadn’t realised existed before), and also a GitHub issue referenced below, about why a PAT is inadequate and unsafe, is also quite exasperating.

Reference: