OIDC Token claims issue in AWS if we have environments in GitHub repo

[venkyio]

At the moment, this action sends subject claim for the AWS and we use this as the trust.
If we want to create an IAM role for main branch and one role for all other branches.

The way to do this is via condition in IAM role as specified here

For Main

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/main"
  }
}

For All Branches

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
  }
}

but the issue occurs when we use environment in GitHub repo.
In this case the subject is sent as repo:<orgName/repoName>:environment:<environmentName> example
repo:octo-org/octo-repo:environment:Production as specified here

Because of this we cannot specify the main branch in the condition . We can fix issue if we add the following ref claim to the condition

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
    "token.actions.githubusercontent.com:ref": "refs/heads/main"

  }
}

but above is not working as the ref claim is not sent to aws

[venkyio]

I have the same issue. Any workaround?
Nothing I know of

[venkyio]

I think its a limitation of assumeRoleWithWebIdentity https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/STS.html#assumeRoleWithWebIdentity-property

[gsuess]

I would have thought that this is what include_claim_keys is for, but I couldn't get it to work.

[peterwoodworth]

There are a few things going on here.

First, the subject claim will be the environment if one is specified, so you cannot filter by branch through sub if environment is specified

Second, AWS doesn't currently support the ref claim, meaning you cannot specify this in your trust policy for this use case.

Third, to my knowledge, Github does not support custom claims. Here are the listed supported claims. It doesn't seem to me that the API mentioned above would help out here, though I would be happy to be wrong. If Github supported custom claims, we'd be able to encode them in the jwt for AWS to parse

So at the moment, this unfortunately seems impossible to specify in the trust policy when using OIDC. However if AWS supports more claims, or if Github allows to specify custom claims, then this would be possible.

I'll keep this issue open for visibility, and in case anyone has additional info which may help us find a workaround I'm unaware of. Thanks everyone for the discussion here!

[robgott]

@venkyio I was able to get it working after customizing the OIDC subject claim, for some reason though the org level is not working so had to do it on a per-repo basis, and to be clear it is just the subject claim that you are customizing, as @peterwoodworth mentioned other claims are not supported by AWS.

example:

gh api /repos/org_name/repo_name/actions/oidc/customization/sub -H "Accept: application/vnd.github+json" -X PUT --input claim.json

claims.json example contents:

{"include_claim_keys":["repo","context","workflow","job_workflow_ref","repository_visibility"],"use_default":false}

If you check your CloudTrail logs you should see AssumeRoleWithWebIdentity events where the username is the subject eg:
repo:org_name/repo_name:pull_request:workflow:workflow_name:job_workflow_ref:org_name/repo_name/.github/workflows/workflow.yaml@refs/pull/xxx/merge:repository_visibility:private

So an example policy for this custom claim template could be:

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxx:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:org_name/repo_name:pull_request:workflow:workflow_name:job_workflow_ref:*:repository_visibility:private"
                }
            }
        }
    ]
}

From what I can tell all the claims listed here are supported so you could try adding ref / ref_type / head_ref etc to get a merge to master type restriction in place.

[kchandra548]

Hello @robgott, could you please elaborate?

for some reason though the org level is not working

I hope you have attempted to opt-in at the repo level after setting a custom template at the org level. It is turned off by default.

[tristansirrico]

I hope you have attempted to opt-in at the repo level after setting a custom template at the org level. It is turned off by default.

@kchandra548 - where do you configure that setting?

To add on to the post above yours, I also tried configuring the default sub claim on the org level via API. However, the same claims are being sent with the token- e.g. sending the environment instead of the ref which I specified.

[robgott]

@kchandra548 I'm not exactly sure how I opt-in after reading the relevant docs and API reference but I have certainly tried setting use_default to true on a repo level and noticed that it still doesn't work, incidentally when I query any repo in our org it's also returns this value which made me think that I would not need to manually opt-in every repo in our org.

{
  "use_default": true
}

[kchandra548]

Maybe the default term is confusing.

Set Custom template at the Org level using API.

By default, this will not be used at the repo level. To use the custom template set by the org, the repo needs to opt-in using this API.
So to Opt-in Org template, use the following JSON as the payload {"use_default":false}.

[kchandra548]

@kchandra548 I'm not exactly sure how I opt-in after reading the relevant docs and API reference but I have certainly tried setting use_default to true on a repo level and noticed that it still doesn't work, incidentally when I query any repo in our org it's also returns this value which made me think that I would not need to manually opt-in every repo in our org.

{
  "use_default": true
}

use_default:true means It will not use the org's customized template.

[robgott]

@kchandra548 thanks for clarifying that behavior, have tested and works 🥳

[robgott]

@venkyio as discussed above I think you can achieve what you want by customizing the subject claim and including some combination of ref / ref_type / head_ref - the default subject claim repo,context is useful however as described in the documentation the context value will change depending if an environment was set, if it was a merge or a PR whereas in your case you want the ref value to always be present.

[humbertoc-silva]

Hi guys,

I have a similar problem. I am trying to customize the sub claim of a public repository using de API, I got a 201 response code but when I check my ID token the claim does not have the value that I expected.

This is my request body:

{
    "use_default": false,
    "include_claim_keys": [
       "job_workflow_ref"
    ]
}

I am not using orgs, any idea?

[humbertoc-silva]

Hi guys,

I have a similar problem. I am trying to customize the sub claim of a public repository using de API, I got a 201 response code but when I check my ID token the claim does not have the value that I expected.

This is my request body:

{
    "use_default": false,
    "include_claim_keys": [
       "job_workflow_ref"
    ]
}

I am not using orgs, any idea?

Hi,

I found the problem, I was using a personal access token to invoke the OIDC REST API with the repo scope. I changed the token by one with full access and now I could change the sub claim.

Maybe the GitHub documentation needs an update to clarify which scope is needed to invoke the OIDC API.

[venkyio]

@venkyio as discussed above I think you can achieve what you want by customizing the subject claim and including some combination of ref / ref_type / head_ref - the default subject claim repo,context is useful however as described in the documentation the context value will change depending if an environment was set, if it was a merge or a PR whereas in your case you want the ref value to always be present.

@robgott Thank you . Does this work with environments configured for GitHub repo ? is it possible paste TrustPolicies you used for Main Branch and other branches based on this ?

[peterwoodworth]

These quirks are now documented in the README https://github.com/aws-actions/configure-aws-credentials#claims-and-scoping-permissions

[github-actions]

** Note **
Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.