AWS SQS Cross-Account Role Chaining Issue with KEDA Autoscaler

[Linolearning]

We are implementing KEDA autoscaling based on AWS SQS queue metrics in EKS. Our setup involves cross-account access where the pod IAM role needs to assume another role in a different AWS account to read SQS metrics.

Direct access to the target role is not allowed in our governance model, so we must use IAM role chaining. We tried setting up role chaining, but it’s currently failing with AccessDenied errors.

Has anyone successfully configured KEDA with cross-account role chaining for SQS autoscaling? Any guidance or recommended approach would really help.

[nicknikolakakis]

Cross-account role chaining with KEDA's SQS scaler is supported. Here's how to set it up:

Architecture

KEDA Operator (IRSA Role A, Account 111) -> Assumes Role B (Account 222) -> Reads SQS

Step 1: IAM Role A (your EKS account, Account 111)

The KEDA operator's IAM role needs sts:AssumeRole permission for the target role:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::222222222222:role/keda-sqs-role"
}

Step 2: Role B trust policy (target account, Account 222)

Role B must trust the KEDA operator role (not the pod directly):

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/keda-operator"
  },
  "Action": [
    "sts:AssumeRole",
    "sts:TagSession"
  ]
}

Role B needs SQS read permissions:

{
  "Effect": "Allow",
  "Action": [
    "sqs:GetQueueAttributes",
    "sqs:GetQueueUrl"
  ],
  "Resource": "arn:aws:sqs:*:222222222222:your-queue"
}

Step 3: KEDA TriggerAuthentication

Use podIdentity.provider: aws with roleArn to specify the target role:

Note: Use podIdentity.provider: aws, not aws-eks. The aws-eks provider is deprecated since KEDA v2.13 and will be removed in v3.

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: sqs-cross-account-auth
spec:
  podIdentity:
    provider: aws
    roleArn: "arn:aws:iam::222222222222:role/keda-sqs-role"

Important: roleArn and identityOwner are mutually exclusive. Do not set both.

Step 4: ScaledObject

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-scaler
spec:
  scaleTargetRef:
    name: your-deployment
  minReplicaCount: 0
  maxReplicaCount: 100
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.us-east-1.amazonaws.com/222222222222/your-queue
      awsRegion: us-east-1
      queueLength: "5"
    authenticationRef:
      name: sqs-cross-account-auth

Common causes of AccessDenied

1. Role B trust policy references the OIDC provider instead of Role A. For role chaining, it must trust the IAM role directly
2. Missing sts:AssumeRole on the KEDA operator role (Role A)
3. Missing sts:TagSession in the target role trust policy. KEDA may require this during role assumption
4. Using deprecated aws-eks provider instead of aws. Migrate to podIdentity.provider: aws on KEDA v2.13+
5. STS regional endpoint - set AWS_STS_REGIONAL_ENDPOINTS=regional if your cluster uses regional STS

Debugging

Check KEDA operator logs for the specific error:

kubectl logs -n keda deploy/keda-operator | grep -i "access\|error\|sqs"

Can you share the specific AccessDenied error? That will pinpoint which leg of the chain is failing.

[Linolearning]

Thanks @nicknikolakakis — we followed the exact same setup you described. Our architecture is:

Role A has sts:AssumeRole to Role B, Role B's trust policy trusts Role A with both sts:AssumeRole and sts:TagSession, and Role B has sqs:GetQueueAttributes / sqs:GetQueueUrl permissions. We're using podIdentity.provider: aws with roleArn pointing to Role B.

However, it only works when we add Role A directly to the SQS queue resource policy in Account 222 — which bypasses the role chain entirely. Is this expected, or should the role chaining work without adding Role A to the queue policy? Without that queue policy, we get AccessDenied. This shouldn't be needed in a proper role chaining setup, right?

Let me set it up again cleanly and share the KEDA operator logs here so we can pinpoint which leg of the chain is failing.

[Pionerd]

Ran into this today. The missing piece is in the above Step 1: IAM Role A (your EKS account, Account 111). Next to AssumeRole, TagSession also needs to be allowed. Tested OK:

{
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:iam::222222222222:role/keda-sqs-role",
            "Sid": "AssumeKedaCrossAccount"
        }
    ],
    "Version": "2012-10-17"
}

[kinthaiofficial]

Cross-account SQS + KEDA is a common pain point. The role chaining issue typically comes down to one of these:

The trust relationship setup

The KEDA operator needs to assume a role in Account A, and that role needs permission to assume a role in Account B. You need:

1. Account B: Create keda-sqs-reader-role with:

   • Trust policy allowing the KEDA role in Account A to assume it
   • Permission policy with sqs:GetQueueAttributes and sqs:GetQueueUrl

2. Account A: The KEDA pod's service account role needs sts:AssumeRole permission targeting the Account B role ARN

3. KEDA TriggerAuthentication: Reference the Account B role ARN for role chaining

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-aws-sqs
spec:
  podIdentity:
    provider: aws
  awsSTSAuthentication:
    roleArn: arn:aws:iam::<ACCOUNT_B>:role/keda-sqs-reader-role

Common failure modes:

• IRSA (IAM Roles for Service Accounts) annotation missing on the KEDA service account
• The intermediate role doesn't have sts:AssumeRole for the target — this is often the missing piece
• External ID not matching if Account B requires one in the trust policy
• Session token expiry — KEDA caches credentials; default refresh may be too long for short-lived tokens

Debugging: enable KEDA operator verbose logging (--zap-log-level=debug) — it logs the exact STS call and the IAM error response, which points directly to which step in the chain is failing.

What's the specific error you're seeing in the KEDA operator logs?