Issue when using aws_session_token

[slomangino123]

Review the following job. By using aws-actions/configure-aws-credentials@v1 to get temporary credentials the AWS_SESSION_TOKEN environment variable is set for later use. but using the following with: aws_session_token: ${{ env.AWS_SESSION_TOKEN }} always seems to return the following error.

Error: Deployment failed: Error: Status: 403. Code: InvalidClientTokenId, Message: The security token included in the request is invalid.

I have tested this with a role that allows the following IAM AWS Managed policy: AdministratorAccess-AWSElasticBeanstalk and confirmed this issue.
When not using a the aws_session_token input, and assigning the user directly the AdministratorAccess-AWSElasticBeanstalk policy the action works just fine.

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Create Bundle
        run: |
          .
          . removed for brevity
          .
    
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
          role-to-assume: <arn-here>/AdminRole
          role-duration-seconds: 1200

      - name: Deploy to Elastic Beanstalk
        uses: einaregilsson/beanstalk-deploy@v20
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws_session_token: ${{ env.AWS_SESSION_TOKEN }}
          application_name: <my-app>
          environment_name: <my-env>
          version_label: <my-version>
          region: us-east-1
          deployment_package: bundle.zip

[adrianmxb]

@slomangino123 did you find a solution for this problem or can you recommend and alternative?

[slomangino123]

@adrianmxb I could not easily find a way to make a temporary session work with an IAM role so I resolved to using permissions on a IAM user directly instead. I would say this is a workaround and goes against best IAM best practices.

[tomjohn1028]

I ran into a similar issue and resolved it by using the following parameters

aws_access_key: ${{ env.AWS_ACCESS_KEY_ID }}
aws_secret_key: ${{ env.AWS_SECRET_ACCESS_KEY }}

Notice how they are set to env rather than secrets