MDAA does not validate cross-cccount Role ARN for cross-account permissions

[nitincs10]

MDAA CDK deployment currently does not properly validate cross-account IAM Role ARNs used for cross-account permissions and integrations.

During deployment, the validation logic assumes the role exists within the current AWS account and attempts to validate it directly using account-scoped role lookup/validation mechanisms. This causes deployment failures when a valid cross-account IAM Role ARN is provided.

In cross-account architectures, the role may legitimately exist in a different AWS account and should still be accepted as long as:

• The ARN format is valid
• Trust relationship is configured correctly
• Required permissions are granted

Current Behavior

• Deployment fails when a cross-account role ARN is provided
• Validation logic attempts to resolve or verify the role in the local account
• Cross-account IAM role usage is blocked even when AWS trust policies are correctly configured
  Error:
  Resource handler returned message: "The role with name fleet-manager-ecs-task-role cannot be found. (Service: Iam, Status Code: 404, Request ID: 800922f9-aab6-495e-8f7f-bf2fd6d97c6a) (SDK Attempt Count: 1)" (RequestToken: bbe44215-e78b-f4d7-d89a-4e02e585ef98, HandlerErrorCode: NotFound)

Expected Behavior

MDAA should:

• Allow valid cross-account IAM Role ARNs
• Validate ARN format (or optionally skip existence validation)
• Support cross-account trust-based integrations without local account role resolution failures

Example

Valid cross-account role ARN:

arn:aws:iam::123456789012:role/fleet-manager-ecs-task-role

Current validation incorrectly assumes the role must exist in the deployment account.

Impact

• Prevents legitimate cross-account deployments
• Blocks multi-account AWS architecture patterns

Suggested Fix

• Update ARN validation logic to support cross-account IAM roles
• Optionally add a flag/configuration to bypass strict local validation for cross-account integrations

[vlnzrv]

Hello @nitincs10!

Thank you for reporting this issue. The behavior here is working as designed, but the intended cross-account pattern isn't obvious — we'll improve the docs and look at reducing friction in the future.

What's actually happening

This isn't ARN format validation. MDAA resolves every roleRef into the full {id, arn, name} triple via a CloudFormation custom resource that queries IAM in the deployment account only (see resolve_role.py). A cross-account ARN surfaces as NoSuchEntity because the role doesn't exist in the deploy account.

We don't auto-accept cross-account ARNs at the moment because role name and ARN are mutable handles — an actor with IAM write in the remote account could recreate a role with the same name but a hostile trust policy, hijacking anything that trusts it. The AWS-generated RoleId (AROA...) is immutable across recreation, so it's the secure anchor.

We don't auto-accept cross-account ARNs at the moment because role name and ARN are mutable handles — an actor with IAM write in the remote account could delete and recreate a role with the same name but a different trust policy. MDAA pins resource grants (KMS key policies, S3 bucket policies, etc.) to the role's RoleId via aws:userId conditions. Since recreating a role generates a new RoleId, the original grants stop matching — preventing a recreated role from inheriting the access of the role it replaced. The AWS-generated RoleId (AROA...) is therefore the secure anchor.

Workaround for now

Provide all three fields — id, arn, and name — so every getter short-circuits and the resolver Lambda is never invoked:

someRole:
  id: AROA1234567890EXAMPLE
  arn: arn:aws:iam::123456789012:role/fleet-manager-ecs-task-role
  name: fleet-manager-ecs-task-role

Get the RoleId once from the target account this way for example:

$ aws iam get-role --role-name fleet-manager-ecs-task-role \
  --profile <target-account-profile> \
  --query 'Role.RoleId' --output text

Going forward

We acknowledge that this is a workaround, not the final experience. We'll look at reducing friction for cross-account role references, while preserving the RoleId-based hijack protection.

[nitincs10]

I completely understand the security concern and this sounds like a decent workaround however I am concerned using RoleID as it could change upon re- deployment with same name. We had encountered this before when a team had to nuke the roles and recreate them. ARN and Name still remain same but ID changes.

[vlnzrv]

@nitincs10 I agree, it's a lot of friction, and right now there is no way to do such a migration seamlessly (even if the roleid is stored in SSM, it needs to be updated, etc). We're going to support "cross-account role referencing by arn" (with required security guardrails) in a future release (v1.7.0) -- although It can't be part of v1.6.0, as it's already on staging.