Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

[mattrw-wageloch]

Describe the bug

As of the 27th of December, 2023, our GitHub Actions workflow is unable to successfully assume the role with OIDC, with the error message Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity.

Our last successful execution of the workflow with the aws-actions/configure-aws-credentials@v4 action was approximately December 20th, 2023, however I cannot confirm when exactly this issue began occurring.

In trying to troubleshoot the issue, we have tried the following:

• Recreating the role and associated trust policy in AWS (both with the same name and different name)
• Replaced the roles to be assumed in our repository secrets with newly created ones
• Verified that our TrustPolicy is formatted correctly and contains the right details.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNTNUMBER:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/testing"
                },
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

• Recreated the identity provider for GitHub to reobtain the thumbprint (no change in string)

The job in our workflow that uses the aws-actions/configure-aws-credentials@v4 is our deploy job.

  Deploy:
    # Deploys to a specific AWS S3 Bucket where AWS CodePipeline will pick up the changes and deploy automatically (if configured to do so).
    needs: Test
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Configure Required AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.TEST_AWS_IAM_ROLE }}
          aws-region: ${{ vars.AWS_REGION }}
      - name: Create Artifact Store
        shell: pwsh
        run: |
          $filepath = "${{ github.workspace }}/Builds/"
          if (-not (Test-Path $filepath)) {
            New-Item -Type Directory -Path $filepath
          }
      - name: Download Build Archive
        uses: actions/download-artifact@v3
        with:
          name: build-artifact
          path: ${{ github.workspace }}/Builds/
      - name: Transfer Archive to AWS S3 Bucket
        shell: pwsh
        run: |
          Set-Location ${{ github.workspace }}/Builds/
           aws s3 cp BuildArchive.zip ${{ secrets.TEST_S3_BUCKET_AP }}

As noted above, beyond minor formatting or value changes, our working configuration remains unchanged. We have also looked for any possible notices by GitHub or AWS where there may have been a recent change that relates to the issue, but have not found anything.

Expected Behavior

Authenticate correctly with the OICD as it has done previously in the past week or so.

Current Behavior

When the action is run and gets to the aws-actions/configure-aws-credentials@v4, it attempts to run and loops through attempts until it fails, subsequently failing the job.

Run aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ***
aws-region: ap-southeast-2
audience: sts.amazonaws.com
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

Reproduction Steps

Have attempted to re-run the jobs with the minor alterations as noted above.

Possible Solution

No response

Additional Information/Context

No response

[tim-finnigan]

Hi @mattrw-wageloch thanks for reaching out. I think that this may be a permissions issue. Did you make any changes to your account/role or policies? Is this issue intermittent or consistent? It doesn't seem like any changes merged in December would have caused this, and I'd expect more reports if there were a larger scale issue here. Please let us know if you have any updates on your end.

[mattrw-wageloch]

Hi @tim-finnigan,

Thanks for the reply.

Yeah, I checked out configuration and nothing had changed from before the issue popped up. Some minor alterations to formatting of the trustpolicy were made (originally had both the sub/aud in the same condition but split them out to like/equals and no change) and recreation of the role with various name changes (and updated in our workflow) upon reading another issue lodged in the last couple of weeks - but beyond that, no other significant changes.

The issue has been constant, and we have not had a successful authentication attempt since we noticed the issue.

[mattrw-wageloch]

Update on this one.

I re-created my OICD provider information and created a new role with it with a different name (previous name had GitHubActions in it) and now it's able to authenticate.

[github-actions]

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.