Breaking change in v4.3.x

[meister245]

Describe the bug

Our team uses major version 4 of this github action in our production deployment pipelines. We don't deploy on a fixed schedule, but we started having failures starting from last week.

We isolated the issue and the only thing that changed was this github action. We have managed to mitigate the issue by renaming our environment variables, so they don't match any generic AWS env variable names.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Given a workflow file with multiple jobs, that access different AWS accounts with different roles and authentication mechanisms.

• Account A is accessed with OIDC identity provider
• Account B is accessed with AWS secret access key
• Environment variables are declared on workflow level.

It is expected that the jobs remain isolated from each other.

Current Behavior

With the latest changes in v4 our jobs were no longer isolated.

• Given a top level environment variable "ROLE_TO_ASSUME" in the workflow, will get automatically picked up by jobs in the workflow.
• Even if a job should use AWS secret access key stored in github secrets to access the AWS account, it will instead attempt to use OIDC identity provider.

Looking at the translateEnvVariables function here:

configure-aws-credentials/src/helpers.ts

Line 10 in afdc2a4

export function translateEnvVariables() {

It appears this function extracts all environment variables from the runner environment and forwards them as input to the github action.

But this already existed in v4.2.x and we had no issues using that version. so the most likely suspect is the new output-env-credentials, which has a default "true" value.

c3b3ce6

Reproduction Steps

I provide a simplified workflow of where our problem occured. The workflow failed in the "invalidate-cloufront" job, as that attempted to login via OIDC provider, instead of the AWS secret key.

name: Deploy Production

on:
  workflow_dispatch:

env:
  ROLE_TO_ASSUME: arn:aws:iam::****

jobs:
  deploy-production:
    runs-on: ubuntu-latest

    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ${{ vars.AWS_REGION }}
          role-to-assume: ${{ env.ROLE_TO_ASSUME }}

      - run: |
          echo "Deploying to production..."

  invalidate-cloudfront:
    needs: deploy-production
    runs-on: ubuntu-latest

    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ${{ vars.AWS_REGION }}
          aws-access-key-id: "***"
          aws-secret-access-key: "***"

      - run: |
          echo "Invalidating CloudFront cache..."

Possible Solution

Switch the output-env-credentials option to default false.

Additional Information/Context

No response

[kellertk]

Hi there, the action started picking up environment variables as action inputs in version 4.2, but we also were not moving the major version v4 tag, which was fixed at 4.0.3, until last week. The major version tag now moves as you would expect. Before this change you were likely still using 4.0.3.

We added the output-env-credentials flag to work around this issue, as well as a new force-skip-oidc flag in v5. Outputting the environment credentials always defaulted to true before, but you now have the option to turn it off. Since most uses of the action do actually need it to set environment variables, you probably want force-skip-oidc instead, which will not use OIDC even if the action thinks you should based on inputs. The other workaround is what you've discovered: rename the environment variables so that the action doesn't pick it up.

[meister245]

Thank you for your response, I was not aware that the major version didn't follow the latest version. I did not follow the git history, but this still sounds like a breaking change, considering 4.0.3 was released about 6 months ago.

The output-env-credentials flag sounds helpful in this context, given what you described. I will keep this in mind for future workflows.

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