Use role-to-assume without OIDC in destination account

[rosswickman]

I'd like to add a feature request for the addition of a with.arg for something like role-to-leverage where this role is the role in a single (orchestration) account where the OIDC is deployed that has the principal and condition to use the IDP.

Prior to the implementation of OIDC, an IAM user in the orchestration account could directly assume a role in a different account.
Now in order to implement the OIDC, the IDP needs to be present in every account.

It would beneficial to use the role-to-assume as a role in a destination account that can be assumed by the role-to-leverage which is in the orchestration account.

This implementation allows the single modification/termination of a role that has access to 100s of accounts instead of having an individual role/idp pair in 100s of accounts that continue to work in GitHub actions until modified.

This would be the role-to-leverage permissions as is my current IAM user

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::*:role/Orchestrator"
        }
    ]
}

And this is the Action Workflow that currently leverages it

name: "Deploy Mgmt Acct Resources"

  on:
    workflow_dispatch:
      inputs:
        accountID:
          description: 'Customer Management Account ID'
          required: true
        customerName:
          description: 'Customer Name Identifier (lowercase)'
          required: true
        DeploymentOU:
          description: 'Deployment OU (Root OU ID - r-xxxx)'
          required: true


  env:
  
    AWS_DEFAULT_REGION: us-east-1
    AWS_DEFAULT_OUTPUT: json
    AWS_ACCESS_KEY_ID: ${{ secrets.DEPLOY_AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.DEPLOY_AWS_SECRET_ACCESS_KEY }}
    AWS_ROLE_SESSION_NAME: Github-Orchestration
    AWS_DESTINATION_ASSUME_ROLE: arn:aws:iam::${{ github.event.inputs.accountID }}:role/Orchestrator

  jobs:
  
    deploy-resale-stacks:
      if: github.ref == 'refs/heads/master'
      runs-on: ubuntu-latest
      name: Deploy Resale Stacks
      steps:
  
        - name: Configure AWS credentials - Assume Customer Account
          uses: aws-actions/configure-aws-credentials@v1
          with:
            aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}
            aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}
            aws-region: ${{ env.AWS_DEFAULT_REGION }}
            role-to-assume: ${{ env.AWS_DESTINATION_ASSUME_ROLE }}
            role-duration-seconds: 1200
            role-session-name: ${{ env.AWS_ROLE_SESSION_NAME }}
            role-skip-session-tagging: true

Thanks

[yahyabmx]

big +1, this can come in handy

[foxylion]

This can be easily achieved using a compound action.
An example can be found here: https://github.com/meisterplan/actions-aws-credentials

[rosswickman]

Yes, thank you for this. It is a viable option, but the point of the ODIC action is to eliminate the use of IAM Tokens and therefore a security requirement to rotate and secure them.
If I have to use a token anyway, I'd rather continue to do so in the single step.

[foxylion]

@rosswickman The compound action would also only use temporary tokens.
@aws-actions/configure-aws-credentials does always generate temporary credentials and stores them in environment variables.
A compound action can make use of this and use the temporarily generated credentials to assume another (second) role.

[rosswickman]

@foxylion Ah. I missed that. I see what is happening.
I glossed over the fact that

aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}
aws-session-token: ${{ env.AWS_SESSION_TOKEN }}

Are the sts temp session creds provided by the ODIC role and not static secrets.
This is extremely helpful. While I'd love to see it native in the AWS action this will for sure get me by.
Thank you.

[peterwoodworth]

I'm not sure I understand the explicit request on another look at this. Our action uses the credentials you have available to make the call that you want to be making. Please upgrade to the latest version v4, take a look at all the options and features we have, and if there's still something we can do about this issue let me know and please clarify exactly what the ask is from us

[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.