Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS cannot filter for many claim keys in trust policies #306

Open
tve opened this issue Nov 4, 2021 · 36 comments
Open

AWS cannot filter for many claim keys in trust policies #306

tve opened this issue Nov 4, 2021 · 36 comments
Labels
p2 service-limitation This is not currently supported by Github or AWS

Comments

@tve
Copy link

tve commented Nov 4, 2021

I'm trying to match the GITHUB_ACTOR in my IAM trust relationship policy and cannot make it work. Is this supposed to work? The trust policy I have is:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::00000000:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:actor": "tve",
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

The error I get is:

Run aws-actions/configure-aws-credentials@master
Error: Not authorized to perform sts:AssumeRoleWithWebIdentity

In my workflow I print ${{ github.actor }} and it matches what I have in the trust policy. Is there a way to get a log of the actual JWT token that IAM receives?

@mikeviviani
Copy link

mikeviviani commented Nov 4, 2021

Hi,
Looking at your IAM role, I do think your aud is not the correct one.
Based on the documentation ### (https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) aud contains your GH Org

"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "https://github.com/octo-org",
"token.actions.githubusercontent.com:sub": "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"

Mike

@tve tve changed the title Cannot match actor tagwhen using OIDC Cannot match actor tag when using OIDC Nov 4, 2021
@tve
Copy link
Author

tve commented Nov 4, 2021

@mikeviviani yeah, except that documentation is completely wrong... If I remove the "actor" match in my policy and just leave the "aud" match it works (just is insecure). The "sub" match in that documentation isn't even valid json...
(I don't remember where I got the aud match for sts.amazonaws.com from Edit: the "sts.amazonaws.com" aud match comes from #280 (comment))

@yotixify
Copy link

yotixify commented Nov 17, 2021

I am having the same issue as well when adding a conditional for the actor tag. When I remove the actor tag I have no issues and the sub conditional works fine, when the actor tag is added into the conditional I get the following error:

Run aws-actions/configure-aws-credentials@master
Error: Not authorized to perform sts:AssumeRoleWithWebIdentity

Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::000000000000:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:actor": "yotixify",
          "token.actions.githubusercontent.com:sub": "repo:orgname/zz-*"
        }
      }
    }
  ]
}

@yotixify
Copy link

Update

After some more testing it looks like the token.actions.githubusercontent.com:actor key is either missing or null in the policy condition. I dumped a jwt token from the OIDC connector to verify that the actor tag was in the jwt from the provider so it is getting passed into aws. However when I change the conditional to a Null action with a value of true instead of a StringLike the condition passes and github actions is able to assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::000000000000:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:orgname/zz-*"
        },
        "Null": {
          "token.actions.githubusercontent.com:actor": "true"
        }
      }
    }
  ]
}

Is there something on the AWS side that is dropping that value?

@CallumHibbert
Copy link

@yotixify I can't even get the token.actions.githubusercontent.com:sub condition to work.

My solution works without any conditions (big security hole) but as soon as I add a condition on token.actions.githubusercontent.com:sub it fails (I'm very sure I have the test value correct).

Which version of aws-actions/configure-aws-credentials are you referencing? I'm referencing @master, do you have something else?

Thanks.

@yotixify
Copy link

Im currently referencing master, I am not at my computer but i can provide a cloudformation template example that limits it by repostory name. Not ideal for scalability but works in a pinch. I plan to open a ticket with AWS on this issue in Monday related to the '''actor''' tag.

@CallumHibbert
Copy link

Thanks for coming back to me. Interesting that you are using @master too.

Do you happen to know if repo:my-org-name-here/* is valid to restrict by Org as a proof of concept (agree that tigher restrictions might make sense in a production implementation)?

As far as I can tell that is a valid test value for token.actions.githubusercontent.com:sub but it won't work for me.

Thanks.

@CallumHibbert
Copy link

OK, so its case sensitive and that was the problem all along. Thanks.

@tve
Copy link
Author

tve commented Nov 21, 2021

so its case sensitive and that was the problem all along

What is case-sensitive? Did you get the actor match to work?

@CallumHibbert
Copy link

Sorry, I should have been clearer, case sensitivity on the token.actions.githubusercontent.com:sub match in the AWS conditions that I was having trouble with (bringing me to this thread originally).

@martijngastkemper
Copy link

I mixed up StringEquals and StringLike

Doesn't work:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:*"
  }
}

Works:

"Condition": {
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:*"
  }
}

@rsclarke-vgw
Copy link
Contributor

Was there further guidance on getting the actor conditional claim to work? I'm equally trying with workflow to no avail.

@mungojam
Copy link

Was there further guidance on getting the actor conditional claim to work? I'm equally trying with workflow to no avail.

I'm having the same problem with token.actions.githubusercontent.com:repository_owner. To me it seems that it's a bug in AWS itself. I can see the property in the token itself when I decode it, but IAM doesn't appear to think it exists. You can verify that by changing the condition to StringEqualsIfExists which then passes because IAM doesn't see it for some reason.

@mungojam
Copy link

I've found some evidence here that custom claims aren't supported in AssumeRoleWithWebIdentity, at least they weren't in 2019.

I've seen similar when I tried to set SourceIdentity through a JWT, which appeared to be possible but never made it to the resultant role.

@mungojam
Copy link

I think this covers the supported token fields:

https://docs.aws.amazon.com/en_en/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-wif

@ianling
Copy link

ianling commented Feb 17, 2022

In the example given in the Github Actions docs:

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

Notice that "StringEquals" has changed to "ForAllValues:StringEquals. This fixed it for me. I can use the custom claims now.

@mungojam
Copy link

In the example given in the Github Actions docs:

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

Notice that "StringEquals" has changed to "ForAllValues:StringEquals. This fixed it for me. I can use the custom claims now.

aud and sub are both listed as supported in the AWS docs, so that explains why it works. Unfortunately none of the custom claims like actor or repository_owner are supported. For repository_owner it's simple to use a StringLike with sub to achieve the same effect, but not for actor which doesn't appear in any of the standard claims.

@ianling
Copy link

ianling commented Feb 17, 2022

I am using repository_owner and it is working.

@mungojam
Copy link

I am using repository_owner and it is working.

with AWS? Could you post an example please?

@ianling
Copy link

ianling commented Feb 17, 2022

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::[xxxxxxx]:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "token.actions.githubusercontent.com:repository_owner": "ianling",
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Works for me!

@mungojam
Copy link

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::[xxxxxxx]:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "token.actions.githubusercontent.com:repository_owner": "ianling",
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Works for me!

I think it isn't doing what you think it is. Try changing the owner condition to something random and it will still let you in (so you are currently very insecure).

From the AWS Docs:

ForAllValues – Tests whether the value of every member of the request set is a subset of the condition key set. The condition returns true if every key value in the request matches at least one value in the policy. It also returns true if there are no keys in the request, or if the key values resolve to a null data set, such as an empty string.

I think it is for testing a different type of request that has multiple sets of key/values in. The name seems really confusing.

@ianling
Copy link

ianling commented Feb 18, 2022

Woops, you are correct! ForAllValues behaves as you said.

After testing more thoroughly, I could not find a way to make it work correctly with repository_owner. I ended up having to switch to using StringLike with the sub claim. There is definitely something wrong here.

@wzyboy
Copy link

wzyboy commented Apr 16, 2022

Google brought me here. Thanks @mungojam for finding the AWS documentation on a list of supported claims.

The GitHub doc should be improved because ForAllValues:StringEquals is an insecure operator for Allow statements. A non-existent / non-supported key (such as repository_owner) always evaulates to true. This makes ALL GitHub users be able to assume your IAM role.

One should always use StringEquals or StringLike. This way, even they accidentally specified an unsupported key, they will immediately find that out, instead of thinking "it works", while actually letting everyone in.

rtyley added a commit to guardian/facia-scala-client that referenced this issue Jun 24, 2022
Note that I seem to be having to abuse the `repositories` field a bit (is
this field badly named?) in order to get this
`repo:guardian/facia-scala-client:*` value:

```
          - Action: sts:AssumeRoleWithWebIdentity
            Condition:
              StringLike:
                token.actions.githubusercontent.com:sub: repo:guardian/facia-scala-client:*

```

...which is apparently the format required:

aws-actions/configure-aws-credentials#306 (comment)
rtyley added a commit to guardian/facia-scala-client that referenced this issue Jun 24, 2022
Running the tests for this project requires read access to
s3://facia-tool-store/DEV/, so we need to provide the GitHub Action
with AWS credentials for a AWS role that allows that.

We're using https://github.com/aws-actions/configure-aws-credentials
to grant the credentials, and https://github.com/guardian/cdk to
create the AWS Role (as we're adding cdk, we get half a dozen new files
in the new `cdk` folder!).

Specific IAM permissions required
---------------------------------

Even though all the FAPI client does, in terms of S3 API calls,
is call `getObject`, we need more than the `s3:GetObject`
permission. We also need `s3:ListBucket` because FAPI sometimes
has to request objects that don't exist ...and without
`s3:ListBucket`, S3 will throw a `AccessDenied` error even tho'
you're possess the `s3:GetObject permission`:

https://stackoverflow.com/a/56027548/438886

Abusing the repositories field
------------------------------

Try to be specific to grant just this repo permissions

Note that I seem to be having to abuse the `repositories` field a bit (is
this field badly named?) in order to get this
`repo:guardian/facia-scala-client:*` value:

```
          - Action: sts:AssumeRoleWithWebIdentity
            Condition:
              StringLike:
                token.actions.githubusercontent.com:sub: repo:guardian/facia-scala-client:*

```

...which is apparently the format required:

aws-actions/configure-aws-credentials#306 (comment)

Co-authored-by: Akash Askoolum <[email protected]>
rtyley added a commit to guardian/facia-scala-client that referenced this issue Jun 24, 2022
Running the tests for this project requires read access to
s3://facia-tool-store/DEV/, so we need to provide the GitHub Action
with AWS credentials for a AWS role that allows that.

We're using https://github.com/aws-actions/configure-aws-credentials
to grant the credentials, and https://github.com/guardian/cdk to
create the AWS Role (as we're adding cdk, we get half a dozen new files
in the new `cdk` folder!).

Specific IAM permissions required
---------------------------------

Even though all the FAPI client does, in terms of S3 API calls,
is call `getObject`, we need more than the `s3:GetObject`
permission. We also need `s3:ListBucket` because FAPI sometimes
has to request objects that don't exist ...and without
`s3:ListBucket`, S3 will throw a `AccessDenied` error even tho'
you're possess the `s3:GetObject permission`:

https://stackoverflow.com/a/56027548/438886

Abusing the repositories field
------------------------------

Try to be specific to grant just this repo permissions

Note that I seem to be having to abuse the `repositories` field a bit (is
this field badly named?) in order to get this
`repo:guardian/facia-scala-client:*` value:

```
          - Action: sts:AssumeRoleWithWebIdentity
            Condition:
              StringLike:
                token.actions.githubusercontent.com:sub: repo:guardian/facia-scala-client:*

```

...which is apparently the format required:

aws-actions/configure-aws-credentials#306 (comment)

Co-authored-by: Akash Askoolum <[email protected]>
rtyley added a commit to guardian/facia-scala-client that referenced this issue Jun 24, 2022
Running the tests for this project requires read access to
s3://facia-tool-store/DEV/, so we need to provide the GitHub Action
with AWS credentials for a AWS role that allows that.

We're using https://github.com/aws-actions/configure-aws-credentials
to grant the credentials, and https://github.com/guardian/cdk to
create the AWS Role (as we're adding cdk, we get half a dozen new files
in the new `cdk` folder!).

Specific IAM permissions required
---------------------------------

Even though all the FAPI client does, in terms of S3 API calls,
is call `getObject`, we need more than the `s3:GetObject`
permission. We also need `s3:ListBucket` because FAPI sometimes
has to request objects that don't exist ...and without
`s3:ListBucket`, S3 will throw a `AccessDenied` error even tho'
you're possess the `s3:GetObject permission`:

https://stackoverflow.com/a/56027548/438886

Abusing the repositories field
------------------------------

Try to be specific to grant just this repo permissions

Note that I seem to be having to abuse the `repositories` field a bit (is
this field badly named?) in order to get this
`repo:guardian/facia-scala-client:*` value:

```
          - Action: sts:AssumeRoleWithWebIdentity
            Condition:
              StringLike:
                token.actions.githubusercontent.com:sub: repo:guardian/facia-scala-client:*

```

...which is apparently the format required:

aws-actions/configure-aws-credentials#306 (comment)

Co-authored-by: Akash Askoolum <[email protected]>
@peterwoodworth peterwoodworth added needs-triage This issue still needs to be triaged and removed needs-triage This issue still needs to be triaged labels Oct 4, 2022
@peterwoodworth
Copy link
Contributor

Thanks for all your help in this thread @mungojam, it's much appreciated!

To recap, AWS docs suggest that this is an AWS limitation in not checking the actor key. Hopefully they will be able to support this someday 🙂

@github-actions
Copy link

github-actions bot commented Oct 8, 2022

⚠️Comment Visibility Warning⚠️

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.

@peterwoodworth peterwoodworth added the service-limitation This is not currently supported by Github or AWS label Oct 8, 2022
@peterwoodworth
Copy link
Contributor

Reopening for visibility, but more importantly to track that this issue is related to a limitation in AWS (maybe we can push this internally)

@peterwoodworth peterwoodworth reopened this Oct 8, 2022
@SwiftEngineer
Copy link

SwiftEngineer commented Dec 17, 2022

Hi y'all 👋 Just wanted to let y'all know there's a workaround for this issue, but it comes with some big caveats, namely, the fact that you'll need to utilize AWS Cognito rather than STS directly, which means it would almost certainly require some changes to this project in order to get working (disclaimer: I don't actually use this Github Action, I was just pointed here by an altruistic coworker).

In a nutshell, the idea is this:

  1. Create a Cognito Identity Pool and connect it to the AWS IAM Open ID Connect Provider you are using now (i.e. arn:aws:iam::00000000:oidc-provider/token.actions.githubusercontent.com)
  2. Create a role mapping rule that checks whatever claim you would like to verify and assigns the role you'd like based on that value
  3. Modify the trust policy of the role you want to assume so that it can be assumed via role mapping, or better yet, create a whole new one so you don't break your existing stuff
  4. Congrats. You now have a Cognito Identity Pool that you can fetch temporary credentials from that checks the value of custom claims before allowing users to assume a role 🎉

Now you'll have to actually interface with AWS Cognito instead of just straight up going straight to STS. It's a quick 1-2 punch that goes like this:

  1. Use your AWS account ID, the ID of the Cognito Identity Pool, and the OIDC token from Github Actions to get an ID
  2. Use the ID you got from the previous step, the ID of the Cognito Identity Pool, and the same OIDC token from Github Actions you used in the previous step to get credentials for that ID

Again, this would almost certainly require changes to this project, but I thought it'd be worth offering up as a potential workaround if anyone felt particularly ambitious! I tested to make sure all of this works using the AWS CLI and I can confirm that it does, albeit with a bit of additional cost to the user.

@JMoserCricut
Copy link

As an alternative to @SwiftEngineer 's workaround, Github does have docs suggesting that for providers that only look at certain wellknown claims for authorization, that we can modify what is passed in the sub claim with some of the other custom claims. This does however seem quite complicated to get setup, and as such I've not tested it myself.

@Onderkuru
Copy link

Arkadaşlar siz uçmuşssunuz bilmiyorum sizi yakalayabilirmiyimde inanın doktorların yazdığı reçete gibi konuşuyorsunuz. Hiç bir kelimenizi anlayamıyorum. Bari konudan bahsederken ne işe yaradığını düzeltme veya kodu yazınca nasıldı hangi işi pratikte görebileceğini bunlarıda açıklarsanız inanın sevinirim.

@unfor19
Copy link

unfor19 commented May 12, 2023

@JMoserCricut I tried what you offered, and it seems to be working 😄

Here's my setup-

  1. Created AWS S3 Bucket - unfor19-gha-play-private
  2. Created AWS IAM OIDC Provider
    • Provider URL: token.actions.githubusercontent.com
    • Provider aud: sts.amazonaws.com
  3. Created IAM Policy - unfor19-gha-play-private-policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::unfor19-gha-play-private/*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        }
    ]
}
  1. Created IAM Role (unfor19-gha-play-private-role) with the following trust relationship and assigned the above IAM Policy to it
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012: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:unfor19/gha-play-private:actor:unfor19"
                }
            }
        }
    ]
}
  1. Updated custom subject OIDC claims with GitHub CLI

Created input file for PUT request body -.input.json

{
    "use_default": false,
    "include_claim_keys": ["repo", "actor"]
}

Used GitHub REST API to PUT custom subject OIDC claims

gh api -X PUT repos/unfor19/gha-play-private/actions/oidc/customization/sub --input .input.json

Used GitHub REST API to get GET custom subject OIDC claims (to verify)

gh api -X GET repos/unfor19/gha-play-private/actions/oidc/customization/sub

Response:

{
  "use_default": false,
  "include_claim_keys": [
    "repo",
    "actor"
  ]
}

So far, I'm all set; now it's time to set the workflow-

.github/workflows/oidc.yml

name: AWS example workflow
on:
    workflow_dispatch: {}
env:
  BUCKET_NAME: unfor19-gha-play-private
  AWS_REGION: eu-west-1
  ROLE_TO_ASSUME_ARN: arn:aws:iam::123456789012:role/unfor19-gha-play-private-role

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout
jobs:
  S3PackageUpload:
    runs-on: ubuntu-latest
    steps:
      - name: Git clone the repository
        uses: actions/checkout@v3
      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ env.ROLE_TO_ASSUME_ARN }}
          role-session-name: samplerolesession
          aws-region: ${{ env.AWS_REGION }}
      # Upload a file to AWS s3
      - name: Copy index.html to s3
        run: |
          date > index.html
          aws s3 cp ./index.html s3://${{ env.BUCKET_NAME }}/

The above setup works; @lukas-hetzenecker, thanks for the tip!

@lukas-hetzenecker
Copy link

@unfor19 I've noticed that your include_claim_keys are: "include_claim_keys": ["repo", "context", "actor"]
But in your "token.actions.githubusercontent.com:sub" you are only specifying repo and actor, you're missing the context part here.

So I think the solution would be to either remove context from include_claim_keys, or change your sub comparison to include the context, like (untested):

  "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:unfor19/gha-play-private:ref:refs/heads/main:actor:unfor19"
  }

for workflows running from the main branch

@unfor19
Copy link

unfor19 commented May 12, 2023

@lukas-hetzenecker - I think that it means I'm just sending "extra info" from GitHub to AWS; so I'm sending the extra context field, though, in AWS Trust Relationship, I'm not filtering by context so it's like "any context is ok", and I'm filtering requests only by repo and actor, so I think it's ok

@lukas-hetzenecker
Copy link

All of the extra information is always part of the JSON Web Token, it is just the AWS does not support custom claims, and therefore cannot use any of that extra attributes (actor, etc.). AWS only allows you to use the sub field in your trust relationship for the role.

With include_claim_keys you then configure what your sub field looks like. This is why "token.actions.githubusercontent.com:sub" is expected to look like "repo:<repo>:<context>:actor:<actor>" with your configuration. This is also why putting a wildcard ("*") in the place where context is fixes the issue.

@unfor19
Copy link

unfor19 commented May 12, 2023

@lukas-hetzenecker You are right! I've just tested the following-

.input.json

{
    "use_default": false,
    "include_claim_keys": ["repo", "actor"]
}

And AWS Trust Relationship - repo:unfor19/gha-play-private:actor:unfor19

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012: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:unfor19/gha-play-private:actor:unfor19"
                }
            }
        }
    ]
}

Thanks for the tip, updated my solution

@mungojam
Copy link

mungojam commented May 14, 2023

This snippet might be useful for anyone getting this working. It will print out all the info in the token. Just use it in a private repo and not in a live setting though

    steps:     
      - uses: actions/github-script@v6
        with:
          script: |
            const token = await core.getIDToken("hello");
            const [, payloadB64] = token.split('.');
            const payloadJson = atob(payloadB64);
            const payload = JSON.parse(payloadJson);
            console.log(`issuer is ${payload.iss}`);
            console.log(payload);
``

@peterwoodworth
Copy link
Contributor

We now have a section in our docs with what's now the most up-to-date information on the topic. Being able to customize the sub claim key should be able to help with most customization needs

@peterwoodworth peterwoodworth changed the title Cannot match actor tag when using OIDC AWS cannot filter for many claim keys in trust policies Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2 service-limitation This is not currently supported by Github or AWS
Projects
None yet
Development

No branches or pull requests