NO_PROXY environment variable not supported, causing proxy issues

[nicolegrosshauser]

Describe the bug

Last week we got following error in our pipeline.

Our step config looks like following:

- name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ env.DEV_AWS_ROLE_ARN }}
          role-duration-seconds: 1200

We already figured out that the v4 tag was moved last week. Thats the reason, why we got this error not earlier.

Everything works fine, when we use the version @v4.1.0

The error occurs with version @v4.2.0

I can not see any changes between the versions, that could produce this error.

Regression Issue

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

Expected Behavior

action should not throw the error, or give more context, which response can not be parsed correctly.

Current Behavior

Action throws error:

Error: char 'F' is not expected.:1:1
  Deserialization error: to see the raw response, inspect the hidden field {error}.$response on this object.

Reproduction Steps

this is how we configure our step:

- name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ env.DEV_AWS_ROLE_ARN }}
          role-duration-seconds: 1200

I already checked our role arn, its correctly configured.

Possible Solution

I investigated a lot of time, but i have no clue whats wrong with our pipeline. Do have any idea what I can do next ?

Additional Information/Context

Our Github Runner is self hosted on a ECS. It runs in a aws account and wants to assume a role of a different account.
As I already mentioned, it works with a previous version. So our iam configuration is correct.

[kellertk]

Hi @nicolegrosshauser. Thanks for the report. I've been unable to get this to fail using 4.2.0 or 4.3.1. I'm using an Amazon Linux 2023 EC2 instance set up with an instance role and this workflow file:

name: cawsc
on:
  workflow_dispatch:

jobs:
  cawsc:
    runs-on: self-hosted
    steps:
      - name: CAWSC
        uses: aws-actions/configure-aws-credentials@v<4.2.0 or 4.3.1>
        with:
          aws-region: us-west-2
          role-to-assume: <role>
          role-duration-seconds: 900
          retry-max-attempts: 1
          role-session-name: TestCAWSC
      - name: Whoami
        run: |
          aws sts get-caller-identity

Relatively straightforward. My EC2 instance role has this trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

and grants these permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VE0",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "<role arn here>"
        },
        {
            "Sid": "VE1",
            "Effect": "Allow",
            "Action": "sts:GetCallerIdentity",
            "Resource": "*"
        }
    ]
}

The assumed role has this trust policy:

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<instance role arn>"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

and these permissions

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Vir0",
            "Effect": "Allow",
            "Action": "sts:GetCallerIdentity",
            "Resource": "*"
        }
    ]
}

That error message about OIDC is expected when you're trying to assume role from a self-hosted runner, so that's normal. The deserialization error is actually coming from the AWS JavaScript SDK. We did update our SDK dependencies between the versions, so that might have changed some things. Another change that might have impacted you is we now pick up environment variables and apply them to action inputs - we don't do this in 4.1.0 but we did in 4.2.0.

Your action output indicates you're using an HTTP(s) proxy. One possibility is you didn't intend to use a proxy, but the HTTP_PROXY environment variable is set in the runner's environment, so our changes to env variable handling now pick this up. If the proxy is returning a modified response from STS, that could cause the deserializaiton error you're seeing.

Can you share your environment details? I would like to reproduce this if I can. Thanks!

[nicolegrosshauser]

Thank your for fast reply!

We are using a ECS task. (Due to company restrictions we are not allowed to use EC2)
So our permissions and trust relations are like following:

task role has this trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

and grants permissions:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Action": [
				"sts:AssumeRole",
				"sts:TagSession"
			],
			"Resource": "<role arn>",
			"Effect": "Allow"
		},
        ... 
	]
}

the assumed role has trust relationship:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TagSession",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<arn here>"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

For example, grants these permission :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "lambda:CreateFunction",
            "Resource": "*"
        }
    ]
}

So I think its not a problem with our permission settings.
Indeed we have some env variable set. I can show you a part of our env variables:

NO_PROXY=.amazonaws.com,localhost,127.0.0.1,::1
HTTPS_PROXY=<proxy-host>:8080
HTTP_PROXY=<proxy-host>:8080
AWS_REGION=eu-west-1

I see that you only read some of the env variables and put then into action input variables.

export function translateEnvVariables() {
  const envVars = [
    'AWS_REGION',
    'ROLE_TO_ASSUME',
    'WEB_IDENTITY_TOKEN_FILE',
    'ROLE_CHAINING',
    'AUDIENCE',
    'HTTP_PROXY',
    'MASK_AWS_ACCOUNT_ID',
    'ROLE_DURATION_SECONDS',
    'ROLE_EXTERNAL_ID',
    'ROLE_SESSION_NAME',
    'ROLE_SKIP_SESSION_TAGGING',
    'INLINE_SESSION_POLICY',
    'MANAGED_SESSION_POLICIES',
    'OUTPUT_CREDENTIALS',
    'UNSET_CURRENT_CREDENTIALS',
    'DISABLE_RETRY',
    'RETRY_MAX_ATTEMPTS',
    'SPECIAL_CHARACTERS_WORKAROUND',
    'USE_EXISTING_CREDENTIALS',
  ];
  for (const envVar of envVars) {
    if (process.env[envVar]) {
      process.env[`INPUT_${envVar.replace(/_/g, '-')}`] = process.env[envVar];
    }
  }
}

Is it possible that you need to read the "NO_PROXY" variable as well ?