Same Github Action works on push but not on pull_request_review

[spring1843]

I have an action that runs on both push into main and pull_request_review.

The problem I'm seeing is that configure-aws-credentials works on push events but fails when triggered by pull_request_review with the message Error: Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers.

I have also seen it not working with:

on:
  push:
    tags: ['v*']

I'm not seeing any specific errors anywhere, on the AWS side I see:
2022-05-13T21:40:01Z 7a625f11-6f05-4634-976d-b5a5cc9f62ff sts.amazonaws.com AssumeRoleWithWebIdentity AccessDenied An unknown error occurred

Here's what the Github Action looks like:

name: TestAction
on:
  push:
    branches: [ main ]
  pull_request_review:
    types: [ submitted ]
permissions:
  id-token: write
  contents: write
jobs:
  testaction:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: arn:aws:iam::***********:role/Github
          aws-region: us-east-1

The trust relationship for the role looks like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::**********: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/Repo:*"
                }
            }
        }
    ]
}

[kellertk]

Hi there @spring1843, I tested this out in a private repo and it's working for me. Here's my configuration:

name: TestAction
on:
  push:
    branches: [ main ]
  pull_request_review:
    types: [ submitted ]
permissions:
  id-token: write
  contents: write
jobs:
  testaction:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: aws-actions/[email protected]
        with:
          role-to-assume: arn:aws:iam::***********:role/testOIDC-Role-ZKGEP6WFYGSY	
          aws-region: us-west-2
      - run: env

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::**********:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:kellertk/test-configure-aws-credentials:*"
                }
            }
        }
    ]
}

I tested this on both push and pull_request_review: [ submitted ] events and got back my credentials as environment variables properly. A couple of things I noticed:

• You have both a StringEquals and StringLike condition in your trust relationship. The current documented CloudFormation template only has the StringLike condition. Then again, I tested adding both conditions in the trust policy and it still worked fine.
• Make sure that your StringLike condition is correct - If repo:Org/Repo:* isn't a obfuscation it should be your actual org and repo :)

[kellertk]

Some more info: Error: Credentials could not be loaded, please check your action inputs: appears as a result of the validateCredentials function, which is only called if we're running in a self-hosted runner (GITHUB_ACTIONS=true is not in the environment), or if you're not using the GH OIDC provider (role-to-assume is set, process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN is in the environment, access-key-id is NOT set, and web-identity-token-file is NOT set). Here's a pseudo-code way to explain this:

if env['GITHUB_ACTIONS'] is not true:
  selfHostedRunner = true
  validateCredentials()
else
  if role-to-asume is not undefined
     AND env['ACTIONS_ID_TOKEN_REQUEST_TOKEN'] is not undefined 
     AND aws-access-key-id is undefined
     AND web-identity-token-file is undefined:
    usingGitHubOIDC = false
    validateCredentials()

Basically you shouldn't be hitting the code that's outputting this error if your environment is what we expect.

[kellertk]

After further digging, it looks like GitHub simply doesn't populate the environment variables necessary to do OIDC authentication if the GitHub actions token running the job doesn't have the correct permissions to write to the JWT. GitHub's documentation says that in order to perform OIDC, the id-token: write permissions must be set - and note that even in the default "permissive" action setting, this permission is set to none. You have to explicitly set id-token: write for OIDC to work.

Note that this also means that OIDC cannot work on forks (see #373). The id-token is artificially limited to read permissions on forks regardless of the configuration.

[spring1843]

I'm now realizing that in my use case where PRs are made to the main repo from a fork (because the main repo does not allow contributors to push branches to the main repo which is a common practice many projects) and where the workflow is triggered on pull_request_review, Github will not populate the environment variables and setting id-token:write makes no difference. For such cases therefore OIDC authentication is not an option.

[spring1843]

Our work around for this was to use a secondary Github Action Workflow that is triggered on workflow_run. This second GA will authenticate properly however it will not have access to the event data from the first workflow such as PR number or tag.

In case the second workflow needs to have that data then the first workflow can package and upload it as an artifact and the second workflow will be able to download and use it.

[github-actions]

⚠️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.