[HN Gopher] GitHub: Packages support for fine-grained PATs
___________________________________________________________________
GitHub: Packages support for fine-grained PATs
Author : CaliforniaKarl
Score : 20 points
Date : 2024-04-25 23:13 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| candiddevmike wrote:
| This is such a pain in the ass/security nightmare because without
| this you have to grant full read/write on your repositories using
| classic tokens.
| simonw wrote:
| Presumably this means the new finely-grained PATs?
| https://docs.github.com/en/authentication/keeping-your-accou...
|
| The annoying thing about those is that they force you to set an
| expiration date, with a maximum of one year from today.
|
| For most of the things I need a PAT for this is a big
| frustration. I want to set up things like cron jobs that access
| specific data from specific repos - but I really don't want to
| have to remember to go and grant them a new token every 365 days.
|
| Older PATs don't have this problem, which means I'm incentivized
| to continue using those even though they are much less secure
| because they grant a wider scope.
|
| I want unlimited expiration on finely grained tokens.
|
| My ideal implementation would include both easy revocation and
| good audit logging - I want to know when the token was last used,
| but ideally I'd like to know what it was used for and have
| details of where that request came from (I guess IP address would
| have to do for that). That way if my token leaks I can revoke it
| and analyze what happened using the audit log.
|
| I just found this roadmap item relating to this:
| https://github.com/github/roadmap/issues/599 - "Fine-grained PAT
| expiry policies for organizations"
|
| It talks about letting organizations set a policy saying "no
| token lasts more than X months" - I'd love it if this could
| expand to "... or set a policy that says unlimited tokens are
| allowed", since then I could set that for my own organizations
| and stop complaining about this!
| cqqxo4zV46cp wrote:
| That's a lot of words to say "I want to continue shooting
| myself in the foot, please!" Your complaining makes out like
| you're powerless to stop yourself from using legacy PATs.
| You're not. You could just suck it up and spend the time doing
| the very low effort high reward activity of rotating your keys.
| There's a reason why every security posture determination
| questionnaire under the sun asks about key rotation. It's
| because old keys lingering around is a very material security
| issue in practice. GitHub emails you when a fine-grained PAT is
| about to expire. Repeatedly. If you forget, then presumably
| your actual automations are going to stop working. And to be
| blunt, if it gets to that point (e.g. you don't act on repeated
| emails, or your cron monitoring isn't such that you're told
| about about things failing) then it sounds like you have bigger
| problems. You long for increased audit logging (have you
| actually looked at what's already available!?). Audit logging
| is only so useful because it tells you what already happened,
| and you have to actually either notice that your key has been
| compromised, or be proactively monitoring your audit logs. Are
| you telling me that you've managed to carve out the time in
| your day for this, but you can't rotate your keys once a year?
|
| I have great sympathy for GitHub's position and have been in
| similar ones. Your customer's security is always, to varying
| degrees, your problem. I've got no doubt that this explicit
| design choice is in response to support requests, and that it
| informed by their real-world experiences re attack vectors
| related to PATs. The problem is that every developer always
| wants to hit the "no, I'm special, let me do this" button.
| sunshowers wrote:
| I have too many things to do in my life and too little time
| to do it in. For my personal stuff, I'm fine with fully
| automated key rotation but I'm not going to do it manually,
| just as I don't rotate my SSH keys. (For businesses, yes, it
| makes sense.)
| gladwindos wrote:
| I fully agree! I know the risks, but for personal projects
| I really don't want to think about having to rotate my
| keys.
| simonw wrote:
| (I found this comment useful, thanks.)
|
| This is why I'd like this to be an organizational setting.
|
| When I'm working in a business setting I'm fine with
| operational overhead like having to rotate keys.
|
| For personal projects I want to be able to set something up
| with the minimum scoped permissions possible and then leave
| it running.
| hobofan wrote:
| I am part of a few projects where for organizational reasons
| (e.g. corporate-community partnerships), we use
| `repository_dispatch` to trigger builds across repositories.
| PATs are great here, as they can be scoped down to single
| repos and permissions.
|
| There is a miniscule attack vector from using PATs here
| (maximum someone could do is trigger many GH Actions builds,
| but they also could do that otherwise), and to rotate the
| PAT, two people have to coordinate (as the origin repo has
| tighter permissions), and even though docs exist in the repo
| for how to rotate them, as it's a rare task people didn't
| find them the first year (second year is still coming up).
| For that use-case I'd greatly appreciate if PATs would exist
| that have a longer/no expiry.
| jupp0r wrote:
| The gold standard is to have these tokens be emphermal and have
| them be issued my something like
| https://github.com/martinbaillie/vault-plugin-secrets-github.
| You should never rely on manually rotating tokens, it's 2024
| and we have decades of production outages due to expired certs
| to prove that this stuff needs to be automated. Having
| mandatory expiration is a great way to incentivize users to do
| the right thing here.
| candiddevmike wrote:
| IMO, the right way is for GitHub to allow for JWT/OIDC
| federation, ideally allowing custom public keys to be
| uploaded, so I can issue my own tokens from a secure crypto
| source. With the GitHub app, you're still copying/pasting
| long lived tokens during the setup phase.
| simonw wrote:
| If I want my random DigitalOcean VPS to have access to an
| account elsewhere, it's going to need a secret of some sort.
| If it gets issued ephemeral secrets from something like Vault
| it still needs to be able to identify itself to Vault as "I'm
| DigitalOcean VPS ID=32443 and I need a 1 hour secret to
| access this GitHub repo".
|
| Eventually, something needs to have a non-expiring secret to
| help identify it.
|
| The more complicated we make this stuff the more chance
| someone will make a mistake in configuring it and open
| themselves up to a breach.
| zshev wrote:
| I'm not familiar with DO but one approach to the secret
| zero thing that works elsewhere is the VPS gets assigned an
| OIDC identity by the provider (or the VPS has access to one
| if it asks). That identity is in turn used to sign in to
| Vault.
| shawabawa3 wrote:
| I'm not sure why this was posted, but I assumed that it's because
| it's a very basic feature that's been on the roadmap for over 2
| years with no progress?
|
| Is there a new update? Has it been shipped? It doesn't look like
| it
___________________________________________________________________
(page generated 2024-04-28 23:02 UTC)