GitHub: Packages support for fine-grained PATs

https://github.com/github/roadmap/issues/558

21 13 2 years ago

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.

simonw4• 2 years ago

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• 2 years ago

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• 2 years ago

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

simonw4• 2 years ago

(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• 2 years ago

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• 2 years ago

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.

candiddevmike2• 2 years ago

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.

simonw4• 2 years ago

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.

shawabawa3• 2 years ago

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

GitHub: Packages support for fine-grained PATs

Related Stories