fix: Remove SystemCredentials source check during AWS role assume

[onyxraven]

Summary

This removes the 'source === "environment"' check done during the role assume for AWS SystemCredentials.

In every case of the SystemCredentials usage for AWS, it is supposed to assume the role required during credential setup (with the given externalId as well). The previous conditional would only do that assume if it was via environment. This left out the (recently added) pod, container, and instance sources, and those would return the system credentials instead (unintended, I think, and a potential security risk). These sources should act the same way.

I added a test using one of the other sources, and red-green tested. I've also tested this "in practice" along with my other PR (#22316) in our environment.

Related Linear tickets, Github issues, and Community forum posts

Fixes #21961

(https://linear.app/n8n/issue/GHC-5527)

Review / Merge checklist

• PR title and summary are descriptive. (conventions)
• Docs updated or follow-up ticket created.
• Tests included.
• PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

[onyxraven]

While stepping through understanding, noticed this misspelling. This type is not exported and only used below.

[onyxraven]

Ultimately, this could (should?) iterate through each source type and ensure it behaves as intended.

[cubic-dev-ai]

No issues found across 3 files

[n8n-assistant]

Hey @onyxraven,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following:
• Tests are included for any new functionality, logic changes or bug fixes.
• The PR aligns with our contribution guidelines.

Regarding new nodes:
We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email [email protected] and we will be happy to discuss the best approach.

About review timelines:
This PR has been added to our internal tracker as "GHC-5801". While we plan to review it, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Thank you again for contributing to n8n.

[onyxraven]

This has been rebased against n8n master as of today.

• pnpm build
• (cd packages/node-base; pnpm test)

[darkgoldxp]

Hello @onyxraven

I habe a problem with EKS Pod Identity.
I test that since #21584 is merged in version 2.1.0

All my conf is OK and I can assume role on the pod using CLI but not on n8n (Failed to assume role: System AWS credentials are required for role assumption. Please ensure AWS credentials are available via environment variables, instance metadata, or container role.)

Logs in the pod-identity-agent is :
{"client-addr":":","cluster-name":"<CLUSTER_NAME>","level":"info","msg":"handling new request request from :","time":"2025-12-23T14:16:38Z"}
{"client-addr":":","cluster-name":"<CLUSTER_NAME>","level":"error","msg":"Error fetching credentials: Service account token cannot be parsed: token is malformed: could not base64 decode header: illegal base64 data at input byte 6","time":"2025-12-23T14:16:38Z"}

For validate assume role is OK in CLI I do :
export EKS_TOKEN_CLEAN=$(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE | tr -d ' \n\r')
curl -v -H "Authorization: $EKS_TOKEN_CLEAN" http://169.254.170.23/v1/credentials

Your pull request can fix my problem ?

[onyxraven]

I habe a problem with EKS Pod Identity. I test that since #21584 is merged in version 2.1.0

All my conf is OK and I can assume role on the pod using CLI but not on n8n (Failed to assume role: System AWS credentials are required for role assumption. Please ensure AWS credentials are available via environment variables, instance metadata, or container role.)

Logs in the pod-identity-agent is : {"client-addr":":","cluster-name":"<CLUSTER_NAME>","level":"info","msg":"handling new request request from :","time":"2025-12-23T14:16:38Z"} {"client-addr":":","cluster-name":"<CLUSTER_NAME>","level":"error","msg":"Error fetching credentials: Service account token cannot be parsed: token is malformed: could not base64 decode header: illegal base64 data at input byte 6","time":"2025-12-23T14:16:38Z"}

For validate assume role is OK in CLI I do : export EKS_TOKEN_CLEAN=$(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE | tr -d ' \n\r') curl -v -H "Authorization: $EKS_TOKEN_CLEAN" http://169.254.170.23/v1/credentials

Your pull request can fix my problem ?

This looks like a different issue. This PR would handle the way n8n uses the credentials, where this error is the system failing to get the initial system credentials. I don't have access to a pod identity cluster currently so I can't reproduce.

[marty-sullivan]

I'm still cherry-picking the commit from this PR into our docker builds as of v2.1.2 and it's still working great in production.

This PR really is a low-impact merge that very clearly only affects a completely broken and undocumented Credential type, so seems like they should just merge it, IMO.

[admirationmr]

hey @onyxraven i have a quick question, i was facing an issue when trying to enable AWS IAM Role assume, the error is

Couldn’t connect with these settings
Failed to assume role: Access to AWS system credentials disabled, contact your administrator.

I think your PR solves this?

[darkgoldxp]

hey @onyxraven i have a quick question, i was facing an issue when trying to enable AWS IAM Role assume, the error is

Couldn’t connect with these settings Failed to assume role: Access to AWS system credentials disabled, contact your administrator.

I think your PR solves this?

Hello @admirationmr I think you need to set env var "N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED" to true

[marty-sullivan]

hey @onyxraven i have a quick question, i was facing an issue when trying to enable AWS IAM Role assume, the error is

Couldn’t connect with these settings Failed to assume role: Access to AWS system credentials disabled, contact your administrator.

I think your PR solves this?

As @darkgoldxp said, you do need to set that environment variable, but even with that variable added, the credential will still not work with system credentials without this PR merged.

[admirationmr]

hey @onyxraven i have a quick question, i was facing an issue when trying to enable AWS IAM Role assume, the error is
Couldn’t connect with these settings Failed to assume role: Access to AWS system credentials disabled, contact your administrator.
I think your PR solves this?

Hello @admirationmr I think you need to set env var "N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED" to true

@marty-sullivan Hey, thanks for the reply. I just enabled system credentials in the pod configuration, and now the error is slightly different:

Failed to assume role: System AWS credentials are required for role assumption. Please ensure AWS credentials are available via environment variables, instance metadata, or container role.

I’m guessing this means it won’t work until the PR is merged.
Is there any way we can temporarily point to the image built from that PR (or otherwise reference it) in the meantime?

[onyxraven]

hey @onyxraven i have a quick question, i was facing an issue when trying to enable AWS IAM Role assume, the error is
Couldn’t connect with these settings Failed to assume role: Access to AWS system credentials disabled, contact your administrator.
I think your PR solves this?

Hello @admirationmr I think you need to set env var "N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED" to true

@marty-sullivan Hey, thanks for the reply. I just enabled system credentials in the pod configuration, and now the error is slightly different:

Failed to assume role: System AWS credentials are required for role assumption. Please ensure AWS credentials are available via environment variables, instance metadata, or container role.

I’m guessing this means it won’t work until the PR is merged. Is there any way we can temporarily point to the image built from that PR (or otherwise reference it) in the meantime?

Possibly. Depends on which flow you're expecting to use. IRSA is handled in this PR. AFAIK, the other strategies (pod identity, EC2 Instance via KIAM, etc) should work. The code first has to acquire the running-container's credentials, and then use those sign an STS request to assume the provided role and get those credentials (which requires the execution role and the role-to-assume to have mutual sts:assumeRole permissions. I think one of the previous comments may have been a missing policy permission.).

That second step (the sts assume) is what this PR helps fix. Without it, you will likely not see this error, but an error when attempting to use the credentials in a node which will reference the container's execution role (something like: execution role has no allow for sqs:SendMessage or whatever), instead of referencing the role you expected to assume added in the credential.

As far as a container, we're considering it. I'd rather not have a unofficial patch/fork that must be maintained if we can avoid it.

[marty-sullivan]

Glad to see a review is requested. I can confirm this PR is still working in our production self-hosted environment as of v2.6.3

[ShireenMissi]

Tested locally and it works as expected ✅

Stuck

[ShireenMissi]

@onyxraven Thank you for your PR 🙏
Could you please merge master in so the CI checks can pass

[onyxraven]

@onyxraven Thank you for your PR 🙏 Could you please merge master in so the CI checks can pass

Done!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[onyxraven]

It failed the PR name check - should this be "AWS Node"? (Bummer is it passed previously?)

[n8n-assistant]

Got released with [email protected]