[Feedback tracking] Fine-grained personal access tokens #36441
Replies: 194 comments 310 replies
-
I'm wondering, is there/will there be a way to create a fine-grained token for a repository one has collaborator permissions on? Such repositories don't seem to appear in the repository list, and no separate entries on the resource owners list are shown for such repositories. |
Beta Was this translation helpful? Give feedback.
-
Could this be extended to SSH keys as well? My work keys don't really need access to my personal repositories, and vice versa. I'd also like the ability to use GnuPG authentication subkeys for SSH without adding them separately, but that's another issue. Scoping them on a subkey-by-subkey basis would still be an improvement. |
Beta Was this translation helpful? Give feedback.
-
Will there be a way to create tokens that don't expire for CI? |
Beta Was this translation helpful? Give feedback.
-
Is there an API for creating these access tokens? Been playing with Hashicorp Vault and would love to use these tokens to build a Vault Secrets Engine plugin. |
Beta Was this translation helpful? Give feedback.
-
Expiry means I can't set it and forget it, and that's the entire point of granular access tokens - namely, the risk is zero because the permissions are tightly scoped. Forced expiry also means folks will just come up with trivial ways to reissue new ones, which will defeat the purpose anyways. It's like a forced password reuse policy - it seems like it helps security, but it actually harms it. I hope you'll reconsider forced expiry. |
Beta Was this translation helpful? Give feedback.
-
In order to facilitate transitioning between classic PATs and fine-grained, will it be possible to enable classic PAT functionality for specific users, but disable them for all others? It makes the transition a lot more manageable from a security perspective if organizations could disable classic PATs for standard users, but keep them enabled for users that have tokens created that are integrated into automated systems that will take time to migrate. |
Beta Was this translation helpful? Give feedback.
-
Loving the feature 🎉 Of the listed things on the roadmap, multi-org support and packages (GHCR) API would be very useful! Regarding the token expiry, is there some way to get notified ahead of time? |
Beta Was this translation helpful? Give feedback.
-
Ahhh I just spent half of my day trying to use a fine-grained token to download a private package; I overlooked the note with the list of unsupported API endpoints in this section of the documentation. I didn't figure it out until I saw the bullet points at the end of this thread! That was pretty clearly user error, but I'm posting this to see if this was a common mistake others encountered, in which case it could be useful for User Experience to take another look and see if this info could be made more prevalent. For example, maybe it could be presented outside of a box or in a red "warning" box. Or the bullet point could be less verbose (separate out the link to the supported endpoints); or the sub-list items could exclude the extra words "REST API to manage", making them easier to process. But I think my main source of confusion was that when I was reading too quickly and I saw "only work with personal access tokens (classic)", I thought it was going to be a list of things that only work with PATs. So it might be clearer to frame it instead as things that "are not supported for fine-grained personal access tokens". |
Beta Was this translation helpful? Give feedback.
-
according to https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/
However on the organization page, this seems to be a mismatch? am I reading this wrong? |
Beta Was this translation helpful? Give feedback.
-
Will be nice to have source IP restriction on GH token similar to AWS IAM Roles (https://aws.amazon.com/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/) |
Beta Was this translation helpful? Give feedback.
-
The mandatory expiration makes sense for human-oriented use cases - e.g. testing some scripts, locally running programs which interact with GitHub API etc. I have had a number of tokens I created in the past which I only discovered as still active some months or years later. However, for tokens which are used by machines - such as in a CI - the manual rotation seems like unnecessary overhead, as was already mentioned. Contrary to some suggestions made here though, I would say that instead of just allowing no expiry, it would make sense to somehow allow establishment of a trust relationship, such that GitHub backend does the token rotation and humans don't even need to ever see the token, let alone copy and paste it - hence further decreasing the chance of leaks. This would make sense IMO at least for the common case when the token is used within GitHub Actions. GitHub already essentially does that with the default I don't know what the best UX for cross-org and cross-repo tokens is, but perhaps there's some inspiration to take from impersonation mechanisms in GCP, AWS or HashiCorp Vault? Active trust relationships is probably something users would still need to be reminded of regularly, but at least it takes a lot of the overhead away and arguably makes it safer by not exposing the token to humans. |
Beta Was this translation helpful? Give feedback.
-
A missing feature for me is being able to authenticate against GitHub packages. Currently (buried in the docs for packages):
https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages This is compounded by the fact that apps also can't install packages. And also by the confusing UI whereby we can add a package scope to ☝️ That text sounds like you you can authenticate against GitHub packages! This is overall a great change and thanks for your hard work getting it into beta! 🚀 |
Beta Was this translation helpful? Give feedback.
-
Hello, PS Am I "blind" to find and it is in place? |
Beta Was this translation helpful? Give feedback.
-
Seems like a great feature! However, I can't seem to generate a token which accesses specific repositories? Not sure if I'm totally missing something here. |
Beta Was this translation helpful? Give feedback.
-
Will there be a way to associate fine-grained token with team? For example, I am a member of some teams named |
Beta Was this translation helpful? Give feedback.
-
It would be useful to be able to provide an email address to send new PAT request notifications to, so that they can be funnelled into a ticketing system/workflow for auditing etc, rather than just Owner mailboxes. |
Beta Was this translation helpful? Give feedback.
-
Since PATs are one of the primary ways to authenticate to github now (and are in fact required if connecting from an environment that blocks ssh to github), it's become incredibly annoying to have them buried in a submenu of a submenu. To manage my PATs, I have to:
I'd recommend reorganizing the menu as such:
|
Beta Was this translation helpful? Give feedback.
-
Currently, you can check the permissions of a classic token via the REST api or |
Beta Was this translation helpful? Give feedback.
-
I'm wanting to automate the creation of repositories, however the permission required also allows for deletion. This unfortunately means I cannot use the API. In the event someone got hold of the token they would be able to do serious damage. Can I request the permission for repositories is split into creation, update and delete? |
Beta Was this translation helpful? Give feedback.
-
I'm looking to give write permissions on check runs. However it does not appear in the list of permissions I can assign to a token. Am I missing something? |
Beta Was this translation helpful? Give feedback.
-
I'm facing some counter intuitive behavior when trying to create a fine grained access token for a user that is part of our organization and is able to view and clone "internal" repositories within our github enterprise. If the user has no explicit "read" permission within the repository that I want to grant read access to via the fine grained access token, I get an error message "Repositories one or more requested are not accessible to you": If the user is given explicit read access to the repository I'm able to create the token. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
Still no support for packages? More than 1.5 years passed... |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
Currently, I can not use Fine-grained personal access tokens to access repositories under the organization I work for, even if I have been granted all permission. |
Beta Was this translation helpful? Give feedback.
-
Hi, is there a way to create a fine-grainer PAT with read-only access to all the repos, instead of the actual access. The user might have access to all repos read/write, but I want to generate a PAT with read-only access to all repos. |
Beta Was this translation helpful? Give feedback.
-
Could the [PUT / DELETE] |
Beta Was this translation helpful? Give feedback.
-
Please add a "read-only for everything" preset, otherwise you have to select "Read-only" again and again from over 30 separate dropdowns next to each sub-item under 'Repository permissions' and 'Account permissions'. I can see an argument for making you think about each one, but a 'read only for everything' button would be pretty clear in what it does. |
Beta Was this translation helpful? Give feedback.
-
I have a fine grained PAT with all the required access
The documentation mentions that it should work with fine grained PAT but apparently this is not working |
Beta Was this translation helpful? Give feedback.
-
Email notifications for PAT requests should come out immediately and not a daily digest. Additionally we should be able to set the email to be notified. This is typically an admin duty and not an account owner duty. Having a daily digest means that requests are not realized for up to 24 hours. Engineers shouldn't have to wait this long and setting up a webhook should not be required for this basic functionality. Requests should be handled similar to PR notifications. |
Beta Was this translation helpful? Give feedback.
-
This topic serves as an area for feedback and discussion on the new fine-grained personal access tokens format, launched on October 18th. It includes more permissions, mandatory expirations, and organization + repository scoping. You can find more details in the blog post and the documentation.
There are some limits to fine-grained PATs that we'll be addressing in the coming months:
Recently, we've added:
There are also some APIs that do not yet support the fine-grained permission model, that we'll be adding support for in time:
Please let us know what you'd love to see in this new token type, what worked for you, and what didn't. Thank you!
Beta Was this translation helpful? Give feedback.
All reactions