-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manually managing GitHub PATs is challenging and fragmented #194
Comments
Bitwarden have a tool called Secrets Manager which may make some of this management easier. |
Additional context: Following the revocation of my admin permissions on the Nice footgun that I shot myself with |
Another option to evaluate/consider: https://cloud.google.com/secret-manager/docs/overview |
is this a duplicate of #67 ? (the upshot of which is - create a machine user & generate a PAT from that?) |
I think it is. I didn't have visibility of the previous (quite revealing!) Slack thread as it was a |
This issue is related. |
Also related to this issue: opensafely-core/interactive-templates#118 (comment) GitHub's recommendation is to use GitHub Apps, but I don't know how viable that is for these use cases:
|
Instead of having interactive-templates create a PR when a new release is available, check from within this repository on a regular basis. Having this be triggered as a "pull" notification rather than a "push" notification is not quite as refined in terms of getting updates. However, it removes the use of a personal access token. Generally, we're finding those unwieldy to manage as an organisation: see ebmdatalab/metrics#194. See opensafely-core/interactive-templates#118 and opensafely-core/interactive-templates#377 (where this workflow was almost working in interactive-templates, except for requiring a new personal access token).
For what it's worth, because I mentioned this to Lucy after encountering an expired PAT in the interactive-templates repository, the This does require another action on top to generate the token, and I don't know if this satisfies all use cases here (if we need PATs where applications are running), but it might be worth testing out, at least in the case of using GitHub Actions. While I'm here, Pygithub can manage GitHub App tokens as well. |
It would also probably be useful to have a full list of where we're using PATs, if we don't already. I suspect the most important ones are already listed in the team manual, but I don't think it's exhaustive. |
Currently, metrics requires three GitHub PATs across three organisations:
opensafely
,opensafely-core
, andebmdatalab
.There are other bennett projects which require GitHub PATs to work, e.g. job-server.
AIUI the current process is for the developer that is working on a change that adds the need for a PAT to generate the required PAT in their own account (with a long expiry date) and to add it to the right place(s) to make things work in production.
Additional to this, the PATs for
ebmdatalab
require admin approval.A recent change removed widespread admin permissions from developers and broke this process.
Having these important tokens scattered across potentially multiple developer accounts feels fragile, especially if those accounts are disabled/the owner leaves the Bennett institute.
Should we manage these centrally/generally better?
The text was updated successfully, but these errors were encountered: