Update GHA token permissions for generic container workflow

[ianlewis]

Fixes #1256
Fixes #1257
Updates #547

1. Sets top level token permissions for the container generator workflow.
2. Updates container generator workflow to no longer require package: write permissions on the GHA token. Instead we require users of ghcr.io to login using a PAT.

[laurentsimon]

Note that it's debatable that long-lived PAT tokens are a more secure option to ephemeral GITHUB_TOKEN. But we can't have both. Starting as you suggest in this PR means we can later add a package:write if needed.
We need to follow-up whether they can compute the permissions for a reusable workflow dynamically at runtime - instead of statically.

[ianlewis]

Note that it's debatable that long-lived PAT tokens are a more secure option to ephemeral GITHUB_TOKEN. But we can't have both. Starting as you suggest in this PR means we can later add a package:write if needed. We need to follow-up whether they can compute the permissions for a reusable workflow dynamically at runtime - instead of statically.

Yeah, I understand that. This at least makes it so you don't have to give packages: write permissions even if you're using a repository other than ghcr.io. Hopefully this will be fixed by the more granular PAT tokens that are in beta. I'm pretty sure permissions can't be computed dynamically.

[ianlewis]

BTW, I tried to pass the GITHUB_TOKEN with package:write permission to the workflow as an input, basically giving the token more permissions than the workflow asked for, but that didn't seem to work. It still required the workflow to request packages:write for it to work.

[laurentsimon]

Hopefully this will be fixed by the more granular PAT tokens that are in beta.

the fine-grained tokens seem to be scoped in time and always expire (at least in the beta), which makes them unsuitable for workflows. (We can't expect uses to update PATs every month or so)

I'm pretty sure permissions can't be computed dynamically.

I just meant that GH should be able to check the permissions given by the caller at runtime on access to actions that need these permissions. Technically they should be able to do that, without doing a validation statically.

[ianlewis]

the fine-grained tokens seem to be scoped in time and always expire (at least in the beta), which makes them unsuitable for workflows. (We can't expect uses to update PATs every month or so)

Yeah, that seems odd if they allow more granular scopes, users should be more comfortable with having long-term tokens. Maybe that's some feedback for GitHub...

I just meant that GH should be able to check the permissions given by the caller at runtime on access to actions that need these permissions. Technically they should be able to do that, without doing a validation statically.

Yeah, I explicitly tried that and it didn't seem to work. I set package: write on the call to the reusable workflow and passed the GITHUB_TOKEN as an input, but still got permissions errors. It worked when the re-usable workflow requested packages: write so it seems like the workflow needs to request all the permissions it needs to run in all cases, even if it uses only a subset.

The only solution I can think of is to make a separate workflow just for ghcr.io that requests packages: write but that feels like overkill...