GitHub Community
Limiting scope of a PAT to a single repository #21999
-
|
I’m currently using TravisCI in our team to build private NPM packages and publish them to Github packages. I have created a bot account, added it to our team and using its PAT in Travis. Now let’s say John has access to repository A but doesn’t have access to repository B. Problem is because of the bot account PAT having access to both repositories, John can edit “.travis.yml” file in repository A and therefore gaining access to repository B. My first thought was to create a bot account per repository, Unfortunately that is not going to work because I need to pay $9 for each of them. Is there any way to limit the scope of a PAT to a specific repository? or something that will fix this? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 3 replies
-
There’s not a way to limit the scope of a personal access token to a specific repository. We understand that you don’t want to grant applications permissions they don’t need, and these applications probably don’t even want to ask you for these permissions. In some cases, this might even prevent you from using an application. It’s a very important topic and we’re glad you’re bringing it up with us. Providing more granular OAuth scopes is already the biggest blip on the API team’s radar and it’s something we’d love to do. However, we can’t make promises about if and when the scopes you wished for might be available – the API team is rolling out additional scopes as they are completed. The best way to keep track of changes is to follow the API blog, and ping us if you have any questions about the available scopes: Improving this situation about scopes is something the team has been working on. You might want to check out the GitHub Apps features: GitHub Apps allow per-repository access and more finely-grained scopes. One appropach you could take is creating a GitHub App whose sole responsibility is to manage a single file in any of the repositories its installed to:
From there, you could install that GitHub App to the relevant repositories. Creating and using a GitHub App wouldn’t require you to buy another seat. In fact, you can create as many GitHub Apps as you need to perform these sort of programmatic and administrative operations that would have normally been delegated to another person on your team. We hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
This is a very clear answer, thanks. PAT's for single repositories in the future would be great. Would be even better if this could be created and managed within the repository's settings, rather than the PAT coming from a specific user. My immediate use case is that we want to add a button to our existing web app that triggers a specific GitHub action. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the solution. We ended up using GitHub App installation tokens with limited access to specific repositories. From what I learnt from my testings, GitHub Packages don’t work with GitHub App installation tokens. Is that right or I’m missing something? |
Beta Was this translation helpful? Give feedback.
-
|
I can’t understand why it doesn’t have a feature yet. I think it should add the per-repository limit feature as soon as possible. Permissions are more intertwined than you might think. Currently, It need to create an account on github to configure the above features.
If I use Enterprise, I have to pay extra. Most importantly, changing the keys is inconvenient and this has a negative impact on security. Also, having to form a private access token on the CI server or development server is terrible. |
Beta Was this translation helpful? Give feedback.
-
|
mo-harris:
@mo-harris - My apologies for not catching your question the first time around! 😱 Our Authentication in a workflow’s section, Permissions for the
DingGGu:
👋 @DingGGu , hey there, and welcome to our GitHub Support Community! I acknowledge where you’re coming from and think the best place to share that feedback is with our product team through this official feedback form. If you’re interested in learning what our team is working on next, we suggest checking out our GitHub Roadmap FAQs for the latest.
DingGGu:
I see where you’re coming from. Granular permissions came top of mind for the team who initially developed GitHub Apps, and in my earlier reply, I mentioned the approach of using GitHub Apps as an alternative from machine users. If you’ve tried GitHub Apps already and found that feature doesn’t meet your specific need, I’d be curious to learn more about what specific advantages you’ve found a machine user to have. That additional context would help me understand where you’re coming from and I can check on our end to see if there are other alternatives that might be of interest! |
Beta Was this translation helpful? Give feedback.
-
|
Let me add some content to my question. One way to get authorize when pulling Docker images using GHCR is to use PAT. Therefore, I need to register my Github PAT on the CI server or Kubernetes on Docker Credential. I’m worried about this, and I’m looking for another way. I think a great way to do this is to let Github create tokens that give you GHCR-per-container image-specific access. In the current situation, I understand that even though the authority of Source and GHCR (which was added this time) are separated on Github, each team must have a different authority system, which creates N additional enterprise accounts and creates non-centralized tokens. It means you have to manage it individually. Thanks for responding. |
Beta Was this translation helpful? Give feedback.
-
|
@DingGGu - Thanks for sharing that context with me. I’m going to look into this with one of my colleagues this week and see if there might be an alternative approach that could be useful. I’ll follow up by Friday with my findings (wherever I land). |
Beta Was this translation helpful? Give feedback.
-
|
If I may add a different use case. |
Beta Was this translation helpful? Give feedback.
-
|
Alas 2 more years have passed and there still seems to be no way 😦 Just to raise the question again: Is there still no hope on getting more granular PAT control? |
Beta Was this translation helpful? Give feedback.
-
|
It is currently listed in the “Future” section of GitHub’s Public Roadmap and not include in any of the next 4 quarters. |
Beta Was this translation helpful? Give feedback.
-
|
2 years later and no progress on this issue with huge security impact...? |
Beta Was this translation helpful? Give feedback.
-
|
Any update on topic ? |
Beta Was this translation helpful? Give feedback.
-
|
For those that asked, when searching for solution, I stumbled on this thread. The issue linked by @byrneh (thanks) has been recently updated. |
Beta Was this translation helpful? Give feedback.
-
|
It is in Beta now |
Beta Was this translation helpful? Give feedback.
-
|
It's so fine grained that the ppl ask an external community for explanation what to select to use a simple push permission: https://stackoverflow.com/questions/75128935/what-permissions-should-i-choose-for-github-fine-grained-personal-tokens |
Beta Was this translation helpful? Give feedback.
-
|
Can we get this feature for organizations? I don't see PATs as an option in the developer settings of my org. And when I got o my personal settings, it only shows repositories owned under my username's namespace. My use case applies to a public repository owned by an organization. |
Beta Was this translation helpful? Give feedback.
There’s not a way to limit the scope of a personal access token to a specific repository. We understand that you don’t want to grant applications permissions they don’t need, and these applications probably don’t even want to ask you for these permissions. In some cases, this might even prevent you from using an application.
It’s a very important topic and we’re glad you’re bringing it up with us. Providing more granular OAuth scopes is already the biggest blip on the API team’s radar and it’s something we’d love to do. However, we can’t make promises …