Allow for "internal" packages accessible to any action within an org without having to specify consuming repos

[neil-morrison44]

Select Topic Area

Product Feedback

Body

Somewhat similar to: https://github.com/orgs/community/discussions/66098 but the answer there suggests making the repo public which isn't a valid solution for our use case.

Within our org we have around 20 packages being consumed both by each other & by around 30-40 apps. For obvious reasons this makes the current Manage Actions access workflow (where you have to specifically allow consuming repos) untenable.

Ideally we'd like an org-level option which says "all repos can read all packages" since we (and likely others) are small enough that we have no intra-organisation privacy concerns.

Failing that, an option on each package which specifies that all organisation repos can read it using actions would work - ideally that'd inherit from internal repos.

As workarounds we've had to generate PAT tokens which has never felt like a great solution & presents its own issues.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[victormoni]

Hi @neil-morrison44

This use-case makes a lot of sense. We have a similar setup (dozens of internal packages consumed by many apps), and the per-repo “Manage Actions access” allow-list doesn’t scale.

What you can do today (without making anything public):

1. If you’re using GitHub Container Registry (GHCR)

Publish images under the org namespace and set them to Internal (ghcr.io//).
Then any repo in the org can pull with its workflow GITHUB_TOKEN (ephemeral, least-privilege) as long as the job grants package read permission:

permissions:
  contents: read
  packages: read

steps:
  - name: Authenticate to GHCR
    run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin

  - name: Pull image
    run: docker pull ghcr.io/<org>/<image>:<tag>

This avoids per-repo allow-listing and keeps access org-scoped.

2. For non-container package registries (npm/Maven/NuGet/RubyGems) where cross-repo reads still require explicit access

Use a GitHub App installed at org scope with read:packages (and only what else you need). In workflows, mint a short-lived installation token and use it as the package auth token:

permissions:
  contents: read

steps:
  - id: app-token
    uses: actions/create-github-app-token@v1
    with:
      app-id: ${{ secrets.ORG_APP_ID }}
      private-key: ${{ secrets.ORG_APP_PRIVATE_KEY }}
      owner: <your-org>

  # npm example
  - name: Configure npm for GitHub Packages
    run: echo "//npm.pkg.github.com/:_authToken=\${NODE_AUTH_TOKEN}" > ~/.npmrc

  - name: Install deps from GitHub Packages
    run: npm ci
    env:
      NODE_AUTH_TOKEN: ${{ steps.app-token.outputs.token }}

This scales better than long-lived PATs, rotates automatically, and can be installed for “All repositories” in the org.

3. Last resort (what you’re doing today): a fine-grained PAT

Works, but it’s long-lived and has more risk/overhead. If you must use it, store it as an org secret and standardize on a single env var name across repos (e.g., NODE_AUTH_TOKEN, MAVEN_GH_TOKEN, etc.).

Why an org-level option would help (feature request):

• Less toil: no more per-repo allow-lists for dozens of consumers.
• Security: prefer ephemeral GITHUB_TOKEN or GitHub App tokens; avoid static PATs.
• Clarity: one toggle in Org Settings → Packages: “Allow all repositories to read internal packages in this organization.”
• Per-package override: a checkbox “Allow all org repositories to read this package from Actions,” inheriting from internal visibility.

Acceptance criteria (what would solve this for us):

• A single org-wide control that lets any workflow in the org read internal packages (containers and non-containers) with just permissions: packages: read.
• No per-consumer repository configuration required.
• Auditable in org logs (who pulled what, from where).
• Still compatible with package-level teams/overrides where tighter access is needed.

Migration tips that helped us:

• Use an org namespace for packages and avoid tying the package to a single “source” repository when possible.
• Standardize auth across ecosystems (e.g., .npmrc, settings.xml, nuget.config) to read the token from an env var.
• Prefer GitHub App tokens for non-container ecosystems; prefer GITHUB_TOKEN for GHCR.

Until there’s a first-class org-wide toggle, option (1) for GHCR and (2) with a GitHub App have been the most maintainable/secure paths for us.