configure-aws-credentials
configure-aws-credentials copied to clipboard
OIDC Provider with AWS Partitions
Does the ability to make use of the GitHub OIDC Provider to assume AWS roles work with AWS partitions other than the standard aws partition? For example, will this work with the GovCloud partition aws-us-gov?
I tried using the OIDC Provider with a GovCloud account and it resulted in the minimally useful error:
The security token included in the request is invalid
Here is my workflow file:
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Configure AWS Credentials for GovCloud
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::123456789012:role/MyRole
You received that error when you tried to assume the role?
You received that error when you tried to assume the role?
Yes, the action logged that error when it tried to assume the specified role in my GovCloud account.
Here is my complete workflow file:
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
# Test OIDC with commercial account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-west-2
role-to-assume: arn:aws:iam::<ID OMITTED>:role/temp
# Test OIDC with GovCloud account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::<ID OMITTED>:role/temp
Here is a screenshot showing the result:

you're setting the region to us-west-2 in those env variables
Are those env vars being set by the action? You can see my complete workflow in my previous message. I am not setting env vars anywhere.
It appears that if I have this action occurring 2 times in a single workflow then the region set in the first step carries over into the 2nd step. Commenting out my first step causes role assumption to work in my GovCloud account. The resulting workflow is the same as above but with the first assumption step removed:
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
# Test OIDC with GovCloud account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::<ID OMITTED>:role/temp
interesting. I'm taking a look.
This is probably obvious, but I confirmed that if I reverse the ordering of my steps that the same failure occurs in my non-govcloud role assumption.
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
# Test OIDC with GovCloud account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::<ID OMITTED>:role/temp
# Test OIDC with commercial account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-west-2
role-to-assume: arn:aws:iam::<ID OMITTED>:role/temp
I Also tried manually setting the env vars on the step to override what the action is exporting:
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
# Test OIDC with commercial account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-west-2
role-to-assume: arn:aws:iam::<ID OMITTED>:role/temp
# Test OIDC with GovCloud account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
env:
AWS_DEFAULT_REGION: us-gov-east-1
AWS_REGION: us-gov-east-1
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::<ID OMITTED>:role/temp
Surprisingly this did not work. You can see that the env vars are properly set to the govcloud region, but still get the same error:

I don't have gov-cloud access right away, could you try it with two regions in the same partition? if that fails too I can get some kind of patch out tonight, otherwise I'll have to wait until tomorrow where I can start the process to get gov-cloud access.
I just figured out that the region env var has nothing to do with the problem. Nulling out the session and access key env vars causes the error to not occur. Here is my working workflow:
name: "testing oidc"
on:
push:
jobs:
oidc:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Checkout
uses: actions/checkout@v2
# Commercial account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
with:
aws-region: us-west-2
role-to-assume: arn:aws:iam::<ID OMITTED>:role/temp
# GovCloud account
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@master
env:
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:
AWS_SESSION_TOKEN:
with:
aws-region: us-gov-east-1
role-to-assume: arn:aws-us-gov:iam::<ID OMITTED>:role/temp
You can see in this screenshot the region env vars are still set to us-west-2, but the role assumption succeeded. I presume the aws-region input took precedence over the region env vars, which makes sense based upon how this code is written.

this bug is very dumb and is probably going to cause a lot of customer pain. I'll get it fixed.
Thank you for letting us know
Luckily dumb bugs are usually easy to fix 👍
@richardhboyd any updates on getting a fix for this issue?
Is the issue simply that this if statement is not properly checking if an access key is actually set?
Thank you @jwenz723 saved my day!
I'm experiencing the same issue here, ie on the second call with difference AWS keys in a different region it fails with the message:
The security token included in the request is invalid.
The workaround of clearing the env vars is unfortunately not making any difference
Sorry, please ignore me. It's working fine. I had not updated the key values in my secrets :man_facepalming:
@jwenz723 For your OIDC Github and Role setup in gov cloud, did you need to change the clientid and audience to sts.amazonaws-us-gov.com or did you leave it as sts.amazonaws.com?
Update No. you can leave it as sts.amazonaws.com. Works with us-gov-east-1 as the region.
The same problem appears in AWS CN Even though I specified audience field, it still reported me an error
Action process's log
Run aws-actions/configure-aws-credentials@master with: role-to-assume: arn:aws-cn:iam::7NNNNNNNNN6:oidc-provider/token.actions.githubuserpush content.com role-session-name: GitHub-Action-Role aws-region: cn-north-1 audience: sts.cn-north-1.amazonaws.com.cn env: AWS_REGION: cn-north-1 S3BUCKET: ########niywha3y1cnn1b-s3alias Error: Request ARN is invalid
i have to switch back accessId/key mode
Is this still an issue? And by that I mean, is it still required that you wipe your credentials from your environment variables to suit this use case?
Hi, Peter
Sorry, I found I can not access AWS CN service with AWS OIDC authorizate mode. looks like this is a confirmed bug(OIDC Provider with AWS Partitions · Issue #293 · aws-actions/configure-aws-credentials (github.com)https://github.com/aws-actions/configure-aws-credentials/issues/293 [https://opengraph.githubassets.com/db4a866dfb760676cb9139c24278951c0c00b2982490a74b9b0b074e99d96861/aws-actions/configure-aws-credentials/issues/293]https://github.com/aws-actions/configure-aws-credentials/issues/293 OIDC Provider with AWS Partitions · Issue #293 · aws-actions/configure-aws-credentialshttps://github.com/aws-actions/configure-aws-credentials/issues/293 Does the ability to make use of the GitHub OIDC Provider to assume AWS roles work with AWS partitions other than the standard aws partition? For example, will this work with the GovCloud partition ... github.com
so I had to fall back to the traditional secret id/key model
Sorry for the increased security risks
Kind regards,
Steven Jiang
Java Tech Lead
@.@.>
m: +86 135 1218 1811
www.valtech.comhttp://www.valtech.com/
[cid:9a5451db-7af9-4e54-bbe7-499687374a13]https://www.valtech.com/
Suite 1903, Block A, Universal Mansion
172 Yu yuan Rd, Shanghai 200040
From: Peter Woodworth @.> Sent: 21 March 2023 08:41 To: aws-actions/configure-aws-credentials @.> Cc: Steven Jiang @.>; Comment @.> Subject: Re: [aws-actions/configure-aws-credentials] OIDC Provider with AWS Partitions (Issue #293)
CAUTION: This message is from an external sender.
Is this still an issue? And by that I mean, is it still required that you wipe your credentials from your environment variables to suit this use case?
— Reply to this email directly, view it on GitHubhttps://github.com/aws-actions/configure-aws-credentials/issues/293#issuecomment-1477133163, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3TMJFIDOGEK6ENHGNQTKXDW5D2L5ANCNFSM5GNOY5OA. You are receiving this because you commented.Message ID: @.***>
Hey @steven-jiang-valtech,
It looks like based on your previous comment, that your role-to-assume arn may be misconfigured. If you were having an issue with the partition I wouldn't expect the error you receive to be Request ARN is invalid. So I doubt that the partition issue is the issue you're running into here.
Hi, Peter
Thanks for the reminder, I rechecked the relevant CI configuration and found the error
Now the fields related to aws secret have been completely removed from all CI configuration
Thanks again for your help!
Kind Regards,
Steven Jiang Java Tech Lead
@.@.>
m: +86 135 1218 1811
www.valtech.comhttp://www.valtech.com/
[cid:090c07c8-2bf1-46eb-9266-779dddb7aa03]https://www.valtech.com/
Suite 1903, Block A, Universal Mansion
172 Yu yuan Rd, Shanghai 200040
From: Peter Woodworth @.> Sent: 21 March 2023 09:56 To: aws-actions/configure-aws-credentials @.> Cc: Steven Jiang @.>; Mention @.> Subject: Re: [aws-actions/configure-aws-credentials] OIDC Provider with AWS Partitions (Issue #293)
CAUTION: This message is from an external sender.
Hey @steven-jiang-valtechhttps://github.com/steven-jiang-valtech,
It looks like based on your previous comment, that your role-to-assume arn may be misconfigured. If you were having an issue with the partition I wouldn't expect the error you receive to be Request ARN is invalid. So I doubt that the partition issue is the issue you're running into here.
— Reply to this email directly, view it on GitHubhttps://github.com/aws-actions/configure-aws-credentials/issues/293#issuecomment-1477175543, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3TMJFLNITL5QUAFGK47HQTW5EDGHANCNFSM5GNOY5OA. You are receiving this because you were mentioned.Message ID: @.***>
Great to hear @steven-jiang-valtech 🙂
If anyone else runs into the issue, please ping me
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.