Allow audience to be explicitly specified #285
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes:
Allow the audience to be configured instead of defaulting to 'sigstore'.
It's desirable to be able to use different audiences to ensure that changes aren't enabled on the wrong location -- for example, you can use an audience of 'prod' in the production accounts and 'dev' in the development accounts. This is a parameter that's passed to the
ACTIONS_ID_TOKEN_REQUEST_URL
already, but it is hard-coded.By adding
audience
as an argument to the job, you can set a specific parameter in thewith
block, and the example has been updated to reflect this.(You could, for example, us
sts.amazonaws.com
as the default argument in the examples shown while still allowing thesigstore
default to be used if people desire.)This approach should also be usable with the (recently backed-out #280) approach, except by decoupling what the audience is with what the hard-coded default is, you won't break other usages of it.
By the way, it's possible to configure both the role and the OICD provider with an 'either' clause, so you can use
sigstore
orsts.amazonaws.com
-- but that somewhat defeats the point of using a non-default value :)Furthermore this approach allows you to use the audience to allow for different sets roles to be enabled; you could have a
dev
audience that is only trusted by theGitHubDev
role, and aprod
audience that is only trusted by theGitHubProd
role. The OICD audience could have both, but you'd then guarantee that thedev
audience couldn't assume theGitHubProd
role (and vice versa).The equivalent post a78fcb0 change would be:
By the way, It think the reason that a78fcb0 had to be rolled back wasn't because the new token was the wrong way of doing it, but because the default audience changed from sigstore to sts.amazonaws.com without letting others update their OIDC providers. I think the new code would work as is if the 'sigstore' was still the default -- but with this PR, you could allow people to specify what they want.
I'd personally suggest, after merging this PR, you could look at re-reverting a78fcb0 (except change the line as above) and update the documentation/README to say 'audience: sts.amazonaws.com' but have the code default to 'sigstore' if the audience: field is not present. Then you wouldn't break existing users while encouraging them to use the new audience instead.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.