Support assumeRole chains for AWS auth

[sgarfinkel]

Proposal

We would like to have a way to configure a TriggerAuthentication such that the operator’s ServiceAccount calls assumeRole on another role ARN.

Use-Case

We need to support cross-account access, and rather than giving the operator direct access to the underlying resource, we’d like it to call assumeRole on a given ARN (with the appropriate trust policy) before trying to access the underlying resource. This doesn’t seem to be possible. KEDA will either use the operator to access the resource, or try to assume a role ARN directly via OIDC. We’d like to instead have support for chains. This is a common pattern for cross-account resource access, and is supported as a credential pattern in all of the SDKs.

The docs seem to indicate this is supported already but we were unable to get any configuration working and there’s no examples of this.

Is this a feature you are interested in implementing yourself?

No

Anything else?

No response

[JorTurFer]

Hello
Currently it's supported by aws pod identity, isn't? I think that this is the case you're describing

podIdentity:
  provider: aws
  roleArn: <role-arn> # Optional. 
  identityOwner: workload # Optional.

You can set roleArn with the role that you want to assume or identityOwner: workload if you want that KEDA assumes the workload role and you prefer to not deal with arns

Additionally, there is an ongoing PR to support ExternalID for a better cross-account integration

[sgarfinkel]

@JorTurFer I’ll confirm tomorrow but I think if so, it wasn’t working as intended

[JorTurFer]

we haven't tested it for multi account setups because we just have a single AWS account, but the chained identity is covered by an e2e tests where KEDA (using its own role) assumes the workload role and using workload role, access to the resource.

We added this flow to avoid stacking too many permissions on the same role.

This is the e2e tests that covers the case -> https://github.com/kedacore/keda/blob/main/tests/secret-providers/aws_identity_assume_role/aws_identity_assume_role_test.go

[sgarfinkel]

@JorTurFer Just checked, unfortunately this does not work as intended. It never seems to fallback to sts:AssumeRole, and it only seems to try to assume the role using sts:AssumeRoleWithWebIdentity which is the exact pattern we are trying to avoid here. Full stack below, with account information redacted

2025-10-30T01:23:31Z	ERROR	aws_credentials_cache	error retreiving arnRole arn:aws:iam::redacted:role/redacted via WebIdentity	{"error": "failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: 6920c10b-224e-4c81-836e-7322b90b14e6, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity"}
github.com/kedacore/keda/v2/pkg/scalers/aws.(*sharedConfigCache).retrievePodIdentityCredentials
	/workspace/pkg/scalers/aws/aws_config_cache.go:163
github.com/kedacore/keda/v2/pkg/scalers/aws.(*sharedConfigCache).GetCredentials
	/workspace/pkg/scalers/aws/aws_config_cache.go:108
github.com/kedacore/keda/v2/pkg/scalers/aws.GetAwsConfig
	/workspace/pkg/scalers/aws/aws_common.go:61
github.com/kedacore/keda/v2/pkg/scalers.createSqsClient
	/workspace/pkg/scalers/aws_sqs_queue_scaler.go:194
github.com/kedacore/keda/v2/pkg/scalers.NewAwsSqsQueueScaler
	/workspace/pkg/scalers/aws_sqs_queue_scaler.go:64
github.com/kedacore/keda/v2/pkg/scaling.buildScaler
	/workspace/pkg/scaling/scalers_builder.go:136
github.com/kedacore/keda/v2/pkg/scaling.(*scaleHandler).buildScalers.func1
	/workspace/pkg/scaling/scalers_builder.go:85
github.com/kedacore/keda/v2/pkg/scaling.(*scaleHandler).buildScalers
	/workspace/pkg/scaling/scalers_builder.go:90
github.com/kedacore/keda/v2/pkg/scaling.(*scaleHandler).performGetScalersCache
	/workspace/pkg/scaling/scale_handler.go:354
github.com/kedacore/keda/v2/pkg/scaling.(*scaleHandler).GetScalersCache
	/workspace/pkg/scaling/scale_handler.go:282
github.com/kedacore/keda/v2/pkg/scaling.(*scaleHandler).startPushScalers
	/workspace/pkg/scaling/scale_handler.go:202

[sgarfinkel]

Unless of course this is intended. The operator claims it's working afterwards, but I'm not seeing any activity in the underlying role.

[JorTurFer]

Do you have debug level logs enabled? I only see that message as debug with -v = 1 (and that's why I'm asking).

keda/pkg/scalers/aws/aws_config_cache.go

Line 163 in 3ea6bd9

a.logger.V(1).Error(err, fmt.Sprintf("error retrieving arnRole %s via WebIdentity", roleArn))

If yes, that message is perfectly fine and if you don't see any other error, it should be working. That error happens because KEDA tries to get the role before using sts:AssumeRoleWithWebIdentity and then with sts:AssumeRoley as fallback.

Is the scaler that uses this trigger authentication Ready: true?