Public secrets exposure leads to supply chain attack on GitHub CodeQL

Slightly disagree at least for GCP. It will error with a detailed permission, but you're not just going to add that -- you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need. But also, those (standard) roles have many permissions in one, so you likely overprovision (though presumably by just a bit).

...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

The problem with that is that it can be difficult to know what you need, and it may be impossible to simulate in any practical sense. Like, sure, I can stand up a pair of test systems and fabricate every scenario I can possibly imagine, but my employer does want me to do other things this month. And what happens when one of the systems involves a third party?

Really, the need is to be able to provision access after the relationship is established. It's weird that you need a completely new secret to change access. Imagine if this were Linux and in order to access a directory you had to provision a new user to do it? How narrow do you really think user security access would be in practical terms then?

> you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need

Which is terrible btw. You dont "technicall" have to do that, you really cannot add roles to custom roles, you can only add permissions to custom roles. Which makes it really hard to maintain the correctness of custom roles since their permissions can and do change.

> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

GCP even has something like that, but I honestly think that standard roles are usually fine. Sometimes making things too fine grained is not good either. Semantics matter.

> the need is to be able to provision access after the relationship is established

Could you go into more detail? At a base level interpretation, this is how it works already (you need a principal to provision access for...), but you presumably mean something more interesting?

With token-based access, you typically assign the role when the token is created. The access level the token has is typically locked at that point. If you're generating an API access token, you might specify the token is read-only. If you later decide that read/write access is needed, you need to generate a new token with the new access level and replace the token id and value in the client system.

It's not difficult, but it's a much bigger pain in the ass than just changing access or changing role on a user.