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]

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...

[jaredweinfurtner]

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 DId you get an answer?

[mlebkowski]

I know of two ways:

1. Use a deploy key. As far as I know, one deploy key can be assigned only to a single repository, so that wouldn’t be one secret
2. For purposes other than just clonning, one can create a github application.

• One should create & configure a new application, with a special focus on the permissions section. The token you’ll get in the end will have the exact permissions you selected here.
• Then you install the application on your organization. This might require admin privileges or an admin approval. That will get you an installation ID
• Next thing is to generate and fetch a private key for that app. This is the secret part that will allow you to create an JWT token that can be exchanged for an actual access token
• You can use this script (I might have made some typos when creating the gist) to produce the access token: https://gist.github.com/mlebkowski/b872e002d4dd76b53c057054cf945467

[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

[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. 🫶

[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 ❤️

[aw230012]

@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 ❤️

You should consider pivoting. Not only is this a feature that competitors have, but it's also a security risk to create PATs to access. It's a lose/lose for GitHub. If GitHub thinks ternary operators are more important than fixing heavily demanded security issues, GitHub should reevaluate itself.

[nebuk89]

Not that they are more important :) not all our teams are fungible to all areas so it's what can we fit in around the re-architecture work with the skill sets we have free at those times. As it was, we didn't get to ternary operators either last quarter 😞 so watch this space still as we head into this new year of planning

[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 🤷

[jed-exotic]

Deploy keys appear to be a viable solution; however, they cannot be reused across repositories, which does not support a scalable approach. Consider a scenario where you have multiple module repositories and a primary repository that utilizes these modules. The primary repository would require n unique deploy keys to be configured. Additionally, any new modules under development would necessitate the issuance and addition of deploy keys.

I believe this limitation is intentional, which is why I this thread is so popular and is seeking official guidance on this matter.

I am not interested in adopting a community-driven solution for a feature that seems like it should be standard.

[qoomon]

From security perspective they a quite bad, except you rotate them every day or more often.

[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 🥴

[qoomon]

Just to mention it again by using this action https://github.com/qoomon/actions--access-token you don't need pay tokens any more. (You can host the solution your self as well)

[raphasampaio]

+1

[jsebringStrata]

+1

[islu]

+1

[m-guesnon-pvotal]

+1

[jaredweinfurtner]

+1

[acanturk1]

+1

[ported-pw]

Please stop posting "+1". That's what the upvote button is for. Some people like me subscribed to the thread to get updates on this issue / when it's implemented to be able to improve their CI, so I get an email every time you do.

FYI, the GitHub app solution mentioned somewhere above works for the most part and doesn't need any 3rd party solution.

[sawicki-maciej]

+1

[herder]

https://github.com/orgs/community/discussions/46566#discussioncomment-12006734

[rowleya]

I wonder if this is more broken that you might think. In our case, we have been trying out an actions workflow to validate repository branch protection rules. The workflow uses curl to access the rules as follows (where there is an env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}):

curl -s -H "Authorization: token $GH_TOKEN"  -H "Accept: application/vnd.github+json" "https://api.github.com/repos/$OWNER/$REPO/rules/branches/$DEFAULT_BRANCH"

The $OWNER, $REPO and $DEFAULT_BRANCH can be set up to access another repository; in this case they are such that the repository being accessed is a private repository inside an enterprise-owned organisation.

So now the odd part. This works when the action is run from a personally owned public repository where the user is part of the organisation i.e. the GITHUB_TOKEN has the right permission there. When run from within another private repository within the organisation, it doesn't work, and there appears no way to give the token the right permissions. How can the token from a personal repo have more permissions that one inside the same organisation?