'AccessDeniedException' During Cross-Account Rekognition Call ('sts:AssumeRole' Failure)
.jpeg)
Why sts:AssumeRole fails when identity and trust policies don’t align across AWS accounts
Category: IAM & Permission Boundaries
Problem
Your application runs in Account A.
Rekognition resources (or the S3 bucket feeding Rekognition) live in Account B.
Your code attempts to assume a role in Account B before calling Amazon Rekognition.
The call fails with one of the following:
AccessDeniedException: User is not authorized to perform: sts:AssumeRole
or
AccessDeniedException: User is not authorized to perform: rekognition:DetectLabels
IAM policies look correct in both accounts.
Still denied.
Clarifying the Issue
Cross-account access requires two separate permission grants:
- The caller in Account A must be allowed to call
sts:AssumeRole. - The target role in Account B must trust Account A in its trust policy.
Both sides must agree.
In cross-account scenarios:
đź“Ś Identity policy + Trust policy must align.
If either side is misconfigured, the AssumeRole call fails before Rekognition is even evaluated.
Even if AssumeRole succeeds, the role in Account B must still allow Rekognition actions.
Cross-account access introduces an additional boundary layer.
Why It Matters
This failure is common in:
- Multi-account production architectures
- Centralized AI or data accounts
- Shared-services models
- Federated security environments
Engineers often validate IAM permissions in one account but forget to verify the trust relationship in the other.
Cross-account misalignment wastes significant debugging time.
This is an account-boundary issue — not a Rekognition issue.
Key Terms
Cross-Account Access – Accessing resources in one AWS account from another.
sts:AssumeRole – AWS Security Token Service API used to obtain temporary credentials.
Trust Policy – The role policy that defines which principals can assume the role.
Principal – The identity allowed to assume a role (account, role, or user).
Temporary Credentials – Short-lived credentials issued after successful role assumption.
External ID – A unique identifier sometimes required in cross-account trust relationships to prevent the “confused deputy” problem.
Steps at a Glance
- Confirm which account is calling and which account owns the target role.
- Verify the caller’s identity policy allows
sts:AssumeRole. - Inspect the target role’s trust policy.
- Validate the role ARN being assumed is correct.
- Confirm the assumed role allows Rekognition actions (and S3 access if applicable).
- Test the AssumeRole call independently using AWS CLI.
Detailed Steps
Step 1: Confirm Account Roles
Identify:
- Source account (where the application runs)
- Target account (where the role and/or Rekognition resources exist)
Confirm the exact role ARN being assumed.
Cross-account confusion often starts with an incorrect ARN.
Step 2: Verify Caller Permissions in Account A
In Account A, inspect the identity policy of the calling role.
Ensure it includes:
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::ACCOUNT_B_ID:role/TARGET_ROLE_NAME"
}
Without this permission, the assume request will fail immediately.
Step 3: Inspect the Trust Policy in Account B
In Account B, open the target role → Trust relationships.
The trust policy must allow Account A (or its specific role) as a principal.
Example:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_A_ID:role/SOURCE_ROLE"
},
"Action": "sts:AssumeRole"
}
If your organization requires an External ID, ensure the trust policy includes the correct condition and that the caller supplies it during the AssumeRole request. External IDs are commonly required in enterprise environments to prevent the confused deputy problem.
If the trust policy does not include the correct principal (or required External ID), AssumeRole fails.
Both sides must agree.
Step 4: Validate the Role ARN
Ensure the ARN being used in the AssumeRole call exactly matches the target role.
Common mistakes:
- Wrong account ID
- Wrong role name
- Using role alias instead of full ARN
Even a minor mismatch results in AccessDeniedException.
Step 5: Confirm Rekognition and S3 Permissions in Account B
Once AssumeRole succeeds, the temporary credentials operate under the target role’s permissions.
Verify the role in Account B allows:
rekognition:DetectLabels
If the image feeding Rekognition resides in Account B, confirm the role also has:
s3:GetObject
Rekognition cannot “reach back” into Account A after role assumption. All required service permissions must exist in the assumed role’s account.
Cross-account success does not automatically grant service permissions.
Step 6: Test AssumeRole Independently
Use AWS CLI from Account A credentials:
aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_B_ID:role/TARGET_ROLE_NAME --role-session-name test-session
If an External ID is required:
aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_B_ID:role/TARGET_ROLE_NAME --role-session-name test-session --external-id YOUR_EXTERNAL_ID
If this command fails, the issue is purely STS configuration.
If it succeeds, use the returned credentials to test a Rekognition call directly.
Isolate STS from service-level permissions.
Pro Tips
- Cross-account access requires alignment on both sides — identity policy and trust policy.
- Administrator permissions in Account A do not transfer across accounts.
- The assumed role’s permissions fully replace the caller’s original permissions for that session.
- If images live in Account B, ensure the assumed role has S3 access there as well.
- External IDs are frequently required in enterprise environments and must match exactly.
When cross-account calls fail, debug the trust boundary before the service boundary.
Conclusion
AccessDeniedException during cross-account Rekognition calls often originates from a failed sts:AssumeRole.
In multi-account architectures, access requires mutual agreement between identity policy and trust policy — sometimes including an External ID.
If the trust relationship is broken, Rekognition never receives the request.
This is an account-boundary issue — not a Rekognition issue.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment