Assuming two roles in the same region in the same account fails

[dbogen]

If I use this action to assume a role in a given region in a given account, perform some actions, and then try to assume a different role in the same region and the same account, it looks like the action defaults to using the first role to assume the second role.

In this case, I'm trying to use the first role (source role) to copy from a source S3 bucket to a local store, assuming the second role (target role), and using that second role to copy to a target S3 bucket.

My action looks generally like this:

---
name: Deploy

on:
  workflow_dispatch:

env:
  MY_AWS_REGION: us-west-2
  MY_TARGET_S3_BUCKET: foo-target
  MY_AWS_ACCOUNT_ID: ${{ secrets.MY_AWS_ACCOUNT_ID }}
  MY_SRC_S3_BUCKET: foo-src

jobs:
  build_and_deploy:
    runs-on: [self-hosted, linux, small]
    name: Deploy to S3
    timeout-minutes: 10
    steps:
      - name: Get AWS credentials for source S3 bucket 
        id: get-src-creds
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ${{ env.MY_AWS_REGION }}
          role-to-assume: arn:aws:iam::${{ env.MY_AWS_ACCOUNT_ID }}:role/foo-src
          role-duration-seconds: 1800

      - name: Copy from source S3 bucket
        id: copy-from-s3
        shell: bash
        run: |
          aws s3 sync --only-show-errors --no-progress --delete  "s3://${MY_SRC_S3_BUCKET}" ${GITHUB_WORKSPACE}

      - name: Get AWS credentials for target S3 bucket
        id: get-target-creds
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ${{ env.MY_AWS_REGION }}
          role-to-assume: arn:aws:iam::${{ env.MY_AWS_ACCOUNT_ID }}:role/foo-target
          role-duration-seconds: 1800

      - name: Copy to target S3 bucket
        id: copy-to-s3
        shell: bash
        run: |
          aws s3 sync --only-show-errors --no-progress --delete  ${GITHUB_WORKSPACE} "s3://${MY_TARGET_S3_BUCKET}" 

When running that action, the source role assumption succeeds and I'm able to copy files from the source S3 bucket.

The target role assumption fails with the following error:

Error: User: arn:aws:sts::***:assumed-role/foo-src/GitHubActions is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::***:role/foo-target

That error is true; the source role is not authorized to assume the target role.

My assumption was that the action would use the self-hosted runner's instance profile and associated role to assume the second role (which is how it assumed the first role), rather than using the first role to assume the second role.

Is there a workaround to assume a second role in the same region and account where a first role was assumed? Should I instead be passing some sort of flag to tell the action unset all the environment variables it previously set before it tries to assume a new role?

[allisaurus]

Hi @dbogen , thanks for reporting this!

So I think I may know what's going on - this action does reset the session token to account for multiple runs, but the check only triggers when you're providing an AWS_ACCESS_KEY and AWS_SECRET_KEY, vs. relying on an instance role.

I'm still undecided whether this action should always reset these before running - it may sometimes be desired to assume a role with temp creds - but in the meantime, can you try explicitly resetting these vars and then checking the caller identity in your workflow to see if that will get you back to a state which is using the instance role? I.e, add these 2 steps after your Copy from source S3 bucket step:

- name: reset creds
  shell: bash
  run: |
       echo "AWS_ACCESS_KEY_ID=" >> $GITHUB_ENV
       echo "AWS_SECRET_ACCESS_KEY=" >> $GITHUB_ENV
       echo "AWS_SESSION_TOKEN=" >> $GITHUB_ENV

 # should output the ARN of your instance role, if it's now being used
 - name: identity check
   shell: bash
   run: aws sts get-caller-identity

[dbogen]

Thanks for the response, @allisaurus .

Resetting those credentials in a separate step is the workaround I ended up using so, yes, that works.

However, it would be great to have a flag (something like, reset-session-token or use-instance-role) to signal to the action that using whatever credentials currently exist in environment variables is not desired when assuming the next role.

[dcharles-godaddy]

Similar problem here. In our case, we use the role associated with the EC2 instance is the only one permitted to assume the other roles that we need. But, after assuming the first role, there doesn't seem to be any way to drop the credentials and go back to the the role associated with the EC2 instance.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[scub]

I'm still undecided whether this action should always reset these before running - it may sometimes be desired to assume a role with temp creds

I think providing a flag to clear out these environment variables is probably a reasonable compromise to both allow the intent of the described behavior while preserving the role chaining which currently happens.

[peterwoodworth]

A combination of role-chaining or the newly introduced unset-current-credentials in v3 may help in some cases where this action runs multiple times

[github-actions]

** Note **
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.