GITHUB_TOKEN does not have permissions to read other private repos in the same organization

[jabalsad]

Select Topic Area

Product Feedback

Body

Hello,

It appears that the GITHUB_TOKEN secret that is available in Github Actions environments does not have the ability to be configured to read private repositories within the same organization. The only workaround right now is to create permissive PATs that allow this. It seems strange that a PAT is required to read a repository, but not a private package in the github package repository.

Should this be a feature request on the permissions available to GITHUB_TOKEN?

[ilmax]

I also second this, it would be nice if we can define in the permissions configuration section which other repos that belongs to the same organization the GITHUB_TOKEN has access to.

The use case for me is consuming shared terraform modules defined in a standalone repo, e.g. 1 repo for shared infra, several repos consuming the shared infra. As of now to get terraform init work correctly we have to go through several unpleasant hops like creating a PAT and updating git config.
It would be nice if we could get this working OOB with a simple permissions change in the workflow and probably a flag on a repo level to allow actions running from other repos to interact with it

[qoomon]

probably the closest solution => https://github.com/orgs/community/discussions/46566#discussioncomment-9638833

[dennysis]

It not working properly , it still has an error

[landsman]

we need official solution, not 3rd-party

[asbjornu]

+1 from me as well. My use case are:

1. Having a central key repository which is accessed by other repositories' GitHub Actions during builds and releases to Apple TestFlight and App Store (for use with Fastlane specifically).
2. Private repositories as Git submodules. The workaround of creating a GitHub App which has read-access to the required repositories as proposed in Support private repositories and private submodules actions/checkout#287 (comment) works, but feels like a massive hack.

[qoomon]

Maybe my action could be useful for your use case https://github.com/qoomon/actions--access-token

[prabhat-sc]

+1 looks like there is no option other than defining a an organization level secret as a token.

[probitdavid]

It would be nice to have a setting that is all private action runners can access all packages in this org.
This would remove the need for PAT as a secret and also make dependabot updates MUCH simpler as there would be no need to add tokens to that world too

[babu-izhan-5001312]

Hi, I am working on adding dependabot in my repos, but the github actions are failing as it does not have access to other private repos. How are you currently giving the github action that was triggered by dependabot access to private repos ?

[KT-Anja]

I have just been able to solve the problem in our repo. There is an option in the package settings to give certain repositories within the same organization access from the Github Actions. https://github.com/orgs/XXorgaXX/packages/npm/XXrepoXX/settings.

Additionally, I had to add the registry URL in the setup-node step:

uses: actions/setup-node@v3
    with:
        registry-url: https://npm.pkg.github.com 
        scope: "@XYZ"

[giner]

This only works for GitHub Packages which belong to other repositories but not other repositories themselves. Also it doesn't work for Maven repositories (not related to question in the topic though).

[wlandau]

It appears that the GITHUB_TOKEN secret that is available in Github Actions environments does not have the ability to be configured to read private repositories within the same organization. The only workaround right now is to create permissive PATs that allow this. It seems strange that a PAT is required to read a repository, but not a private package in the github package repository.

My colleagues and I maintain internal R packages in GitHub repos (not the same "GitHub Packages", which we don't use). We want to have an ecosystem of R packages that depend on one another, and the checks in https://github.com/r-lib/actions rely on the ability of every internal R package to be installed from every internal GitHub Actions repo. To make this work, every user needs to create their own personal access token, which is painful for experienced developers and utterly confusing for new users.

@github, would you please allow GITHUB_TOKEN to have read access to internal repositories within the same organization? This is absolutely critical for what so many of us are trying to do (related: https://github.com/orgs/community/discussions/46566), and it will be more secure than PATs because GITHUB_TOKEN is a temporary one-time token.

[wlandau]

An update: my organization somehow created an org-level secret that members can successfully use as if it were a PAT for the purpose of cloning other internal repositories inside GitHub Actions workflows. I will try to find out how they did that and then report back.

[wlandau]

Could be a while before I hear back, but let's remember here that GITHUB_TOKEN would be much more secure than a custom org-level token because the former is short-lived and gets a new value for every workflow run.

[MC-Dave]

I second this. It would not only be convenient to have, but it would also allow for a more secure development and deployment workflow.

For example, python's pip allows for ENV variable expansion in requirements.txt files. In order to install from a private github repo, an access token must be provided in the requirements.txt file in the form of an ENV variable. This flow would work seamlessly in github actions with the GITHUB_TOKEN IFF one could give org-level read permissions to said token.

[landsman]

Yes! Critical thing to have and GitHub do not care at all...

[vgpastor]

Same issue when i try to access terraform modules inside an action, terraform init can't access private repos in the same organization.

Please @github any secure solution?

[air3ijai]

Did you try to use a solution with GitHub Apps from comment above?

[landsman]

Yes pls!

[alona-shevliakova]

+1

[mvarchdev]

+1!

[nassorh]

+1

[cvicenti]

+1, we run a git clone of another repo within the same org as part of one of our workflows and this would be way better than using a user-tied PAT

[dspv]

Have the same issue. Tried with another org and it works good. Magic

[earlye]

Yup. Necessary to avoid having long-lived PATs as secrets.

[danielbressan]

+1 would love to have this

[DavidPriceNBS]

+1

[valentin-mogenius]

+1

[b44rawat]

My use-case:

• Trigger workflow present on different repository from the repository workflow present on the same organisation and gather metadata of workflow accordingly.

NOTE: I achieved using fine grained or classic token but looking for streamline solution where i don't have to create my own token and manage.

+1

[qoomon]

https://github.com/qoomon/actions--access-token

[landsman]

Official solution when?

[pansachin]

+1

[NicolasA-arch]

Is someone from GH / MS caring about that request ?

[ilmax]

Clearly not, there are a couple of annoying little things that have been open for years without any answer from GitHub. At times it's a bit frustrating...

[NicolasA-arch]

The PAT solution is half baked in the sense that it needs to be attached to a user, with all the attached issues coming with it.
The same way you allow people certain access, we could/should be able to allow repos/orgs certain access to a repo (with limits to keep it secure, like readonly max to Organization etc ...).

[mundiir]

+1

[matiaslauriti]

[matiaslauriti]

I fix it...

I was previously using uses: organization-name/repo/.github/actions/action-name/action.yml@master, when it should have been uses: organization-name/repo/.github/actions/action-name@master...

And I also did not reference the internal actions globally, so it fails to find action.yml on the repo (instead of the remote action repo).

The documentation is not clear about this usage

[landsman]

What was your use-case in general?

[matiaslauriti]

I have a Satis service (private composer system) so I can have private repos internally.

When a repo (package) needs to be updated, a command needs to be run, so instead of copy-pasting a worfklow that triggers that action, on each repo, I wanted to re-use the action and I was not being able to expose the action as you do with a reusable workflow. I was just wrongly targeting the action

[landsman]

This? https://github.blog/developer-skills/github/using-reusable-workflows-github-actions/

[matiaslauriti]

Yeah, you can see that it does not mention how to reuse an action, there is no example, and if you check the docs (instead of the blog), is the same.

When you target a workflow, you must do ORG/REPO/.github/workflows/name.yml@master for example, but there is no example for actions, it should be ORG/REPO/.github/actions/folder-name@master and inside folder-name, you should have a normal action structure, and then it works even for private actions (private repos exposing actions and workflows)

[landsman]

Please, check this @mariorod

[lkfortuna]

Hi @landsman - Please note, contacting any member of GitHub Staff via unsolicited mentions or pings is strongly discouraged and may be considered a violation of our prohibition against harassment. Please review our Code of Conduct for more information.

[NicolasA-arch]

This is fully understandable and it is good to enforce staff protection.
This being said, we are merely asking for a professional solution to a problem that most your competitors have solved elegantly and that have been raised 18 months ago.
Here @landsman just wanted to warn the CPO about his product, I guess. Merely harassment ....

[landsman]

@lkfortuna gosh, sorry. So please can you lift up this topic and write some official reply?

So I sent Contact form to support.

[ported-pw]

Isn't the UI for a basic version of this kind of already there?

This could be extended to mean (or, if necessary with another radio button) to allow access to other repository contents using the GITHUB_TOKEN as well.
Seconding that this is a basic feature that competitors like GitLab have an elegant solution for since a long time.

[landsman]

Yeah, but it don't work. It's a bug from my POV.

[ported-pw]

I mean, it is clearly described as just being for accessing reusable workflows and actions. I'm just suggesting an MVP.

[gregory-lai]

+100 please and thank you

[nebuk89]

Hey, thanks for all the engagement on this one. Having a hard look at the token and how we enable better multi-repo workflows is on our mind but nothing something we are going to get to this calendar year :(

The solutions presented between either Apps or PATs work, but I totally appreciate the pain and lack of satisfaction with both.

This is something we know we need to look at, and we will get there in the long run. Thank you for continuing to provide feedback and input <3 Your engagement does guide where we are looking to spend our time and please keep talking to us all. 🫶

[Cube707]

this seems like a good spot for it: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[Cube707]

this seems like a good spot for it: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

it might also make sense to add a paragraph there how one should go about implementing inter-orga access for actions that need it.

[NicolasA-arch]

Thx for dropping a word @nebuk89 , it's good to know GH is aware that this isn't satisfactory.
Is there a clear roadmap we can access ? Is there a way customers can influence priorities ?

[landsman]

Thank you for your attention and official reply from the product. It was time.

[nebuk89]

@NicolasA-arch our public roadmap is due to an update just after GitHub Universe. Though I don't think we will have this formally on it at this point and smaller ships (I know this matters, but in the context of releasing Copilot vs this 🥲 this ship would be a smaller one) don't always make it on.

In regardless to influence, the fact that we have as many engagements on this issue as we do will influence the roadmap. We want to double down on community raised issues over the next 9 months. We are though, in the middle of a large investment to re-architect some of our backend to improve availability. This means that we aren't doing many of these items this calendar year.

We have a couple coming (hopefully!) like the run_id on workflow dispatch https://github.com/orgs/community/discussions/9752
and
ternary operators
https://github.com/orgs/community/discussions/75928

(these are up next, but roadmaps are hard and it's always a tricky time with the holiday season looming, so I won't put hard dates against these right now.. but watch this space)

Why these is always a good question :) where we are doing our re-architecture we are trying to pick items that don't end up needing to be 'implement twice' or cause the systems to diverge while we migrate. And, we are after the quicker wins right now.

I hope that is at least some idea of how we are looking at this. Overall influence is just keep engaging, keep explaining the needs and keep sharing. GitHub's Product team are here to listen and learn from you all ❤️

[birjj]

Just because nobody else has mentioned them: an alternative for some use cases is deploy keys, which are SSH keys that are bound directly to a repository, not a user. If your use case is reading or writing to/from a specific private repository then those can allow it.

If you need something other than reading/writing then you'll still need a whole GitHub Apps setup, but 🤷

[joyartoun]

+1

[supervanya]

We were really surprised to learn that GITHUB_TOKEN didn't let us read pull requests in another repo within our org, and found no way to configure it. We have relied on PATs in the past and it totally led to a disaster when a person left the company and forgot to switch his PAT to someone else in a critical workflow 🥴