Output aws-account-id Wrong with role-chaining: true

[eabrouwer3]

Describe the bug

We have a custom action in our private org to get AWS creds for any of our AWS accounts. We first assume the primary role with all permissions and then we use that role to assume a role in the specific account to run code deploys. It looks like this:

name: 'Configure AWS for Deploy'
description: 'Authenticate to the Deployment role for a given AWS account'
inputs:
  target-account:
    description: 'Target AWS account to use'
    required: true
outputs:
  aws-account-id:
    description: 'The AWS account ID of the target account'
    value: ${{ steps.second-auth.outputs.aws-account-id }}
runs:
  using: "composite"
  steps:
    - name: Get Target Account Details
      id: aws-deets
      uses: private-org/get-aws-account-details-action@v1
      with:
        account-name: ${{ inputs.target-account }}
    - name: OIDC to AWS
      uses: aws-actions/configure-aws-credentials@v4
      id: first-auth
      with:
        role-to-assume: 'arn:aws:iam::123456789012:role/gha_oidc_assume_role'
        aws-region: us-east-1
    - name: DEBUG BEFORE
      run: echo "AWS Account: ${{ steps.first-auth.outputs.aws-account-id }}"  # "AWS Account: 123456789012"
      shell: bash
    - name: Assume deployment role for account
      uses: aws-actions/configure-aws-credentials@v4
      id: second-auth
      with:
        aws-region: us-east-1
        role-to-assume: arn:aws:iam::${{ steps.aws-deets.outputs.accountId }}:role/deployment-role
        role-chaining: true
        role-skip-session-tagging: true
        role-duration-seconds: 3600
    - name: DEBUG AFTER
      run: echo "AWS Account: ${{ steps.second-auth.outputs.aws-account-id }}"  # "AWS Account: 123456789012" <-- Expected ${{ steps.aws-deets.outputs.accountId }}
      shell: bash

Expected Behavior

The "DEBUG AFTER" should print out the account ID of the deployment role. And the action output aws-account-id should match that role's account.

Current Behavior

The "DEBUG AFTER" prints out the account id of the gha oidc role. The same thing that the "DEBUG BEFORE" step prints out. And the aws-account-id output from the action matches that first account ID.

Reproduction Steps

on: push

jobs:
  auth-with-account:
    runs-on: ubuntu-latest
    permissions:
      id-token: write

    steps:
      - name: OIDC to AWS
        uses: aws-actions/configure-aws-credentials@v4
        id: first-auth
        with:
          aws-region: us-east-1
          role-to-assume: 'arn:aws:iam::123456789012:role/gha_oidc_assume_role'
      - name: DEBUG BEFORE
        run: echo "AWS Account: ${{ steps.first-auth.outputs.aws-account-id }}"  # "AWS Account: 123456789012"
      - name: Assume deployment role for account
        uses: aws-actions/configure-aws-credentials@v4
        id: second-auth
        with:
          aws-region: us-east-1
          role-to-assume: arn:aws:iam::987654321098:role/deployment-role
          role-chaining: true
          role-skip-session-tagging: true
      - name: DEBUG AFTER
        run: echo "AWS Account: ${{ steps.second-auth.outputs.aws-account-id }}"  # "AWS Account: 123456789012" <-- Expected "AWS Account: 987654321098"

Possible Solution

I'm wondering if the fact that we're calling exportAccountId twice is causing issues. Or that it's not picking up the new session when we call it at the very end of the action after assuming the role.

We call it here for both calls to the action, and we call it here when we're using role-chaining or passing creds through.

Additional Information/Context

No response

[tim-finnigan]

Thanks for reporting this issue. Role-chaining was just added in https://github.com/aws-actions/configure-aws-credentials/pull/688/files a few months ago and this may have been something that was missed.

[andrew-wiggins]

My team came across this bug as well and after some testing it seems to be working as expected in main but not in a tagged version (e.g. v4 or v4.0.2) 🤔

@tim-finnigan do you think we could cut a new tagged version release with the latest main in it?