aws-actions/configure-aws-credentials
1
0
Fork 0
mirror of synced 2026-06-05 14:58:19 +00:00
Code Issues Projects Releases Packages Wiki Activity

chore: update README for additional claim support (#1779)

Browse source 
* chore: update README for additional claim support

* chore: lint fix (whitespace)
This commit is contained in:
Tom Keller 2026-05-14 14:50:49 -07:00 • committed by GitHub
commit 713aaabfec
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 26 additions and 26 deletions
Download patch file Download diff file Expand all files Collapse all files

50
README.md
View file

@ -571,42 +571,42 @@ aws iam create-open-id-connect-provider \
### Claims and scoping permissions ### Claims and scoping permissions
To align with the Amazon IAM best practice of [granting least To align with the Amazon IAM best practice of [granting least
privilege][least-privilege], privilege][least-privilege], the assume role policy document should contain a
[`Condition`](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
that restricts which workflows can assume the role. Without any condition, any
GitHub user or repository could potentially assume the role.
GitHub provides a number of additional claims in the OIDC token that you can use
in your IAM policies to scope down permissions. Early versions of this action
only supported the `sub` and `aud` claims, but AWS IAM and GitHub have since
added support for `sub` claim customization and a variety of additional
claims ([1][gh-blog-oidc], [2][sub-claim-custom]).
> **Warning:** Avoid `ForAllValues:` in `Allow` statements. These operators
> return true when the claim is absent or misspelled, which can lead to
> uninended access. Instead, use `StringEquals` or `StringLike` operators to
> check for specific claim values.
[least-privilege]: [least-privilege]:
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege
[gh-blog-oidc]:
https://aws.amazon.com/about-aws/whats-new/2026/01/aws-sts-supports-validation-identity-provider-claims/
[sub-claim-custom]:
https://docs.github.com/en/rest/actions/oidc?apiVersion=2026-03-10
the assume role policy document should contain a #### Inspecting the token
[`Condition`](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
that specifies a subject (`sub`) allowed to assume the role.
[GitHub also recommends](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims)
filtering for the correct audience (`aud`). See
[AWS IAM documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif)
on which claims you can filter for in your trust policies.
Without a subject (`sub`) condition, any GitHub user or repository could If you aren't sure what claim values your workflow is producing, the
potentially assume the role. The subject can be scoped to a GitHub organization
and repository as shown in the CloudFormation template. However, scoping it down
to your org and repo may cause the role assumption to fail in some cases. See
[Example subject claims](https://docs.github.com/en/actions/reference/security/oidc#example-subject-claims)
for specific details on what the subject value will be depending on your
workflow. You can also
[customize your subject claim](https://docs.github.com/en/actions/reference/security/oidc#customizing-the-token-claims)
if you want full control over the information you can filter for in your trust
policy. If you aren't sure what your subject (`sub`) key is, you can add the
[`actions-oidc-debugger`](https://github.com/github/actions-oidc-debugger) [`actions-oidc-debugger`](https://github.com/github/actions-oidc-debugger)
action to your workflow to see the value of the subject (`sub`) key, as well as action will print the decoded JWT payload. Run it in a private repository
other claims. only — the token itself is short-lived but the claim values may be sensitive.
Additional claim conditions can be added for higher specificity as explained in See the GitHub [security-hardening guide][gh-oidc-hardening] for further
the [GitHub documentation][gh-oidc-hardening]. discussion of trust conditions and threat modeling.
[gh-oidc-hardening]: [gh-oidc-hardening]:
https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
Due to implementation details, not every OIDC claim is presently supported by
IAM.
### Further information about OIDC ### Further information about OIDC
For further information on OIDC and GitHub Actions, please see: For further information on OIDC and GitHub Actions, please see: