How to Trigger ECS Tasks in a cross-account architecture - amazon-web-services

Question

I'm in the process of trying to use Airflow to trigger ECS Tasks in another AWS Account. The worker nodes that Airflow uses always assume a specific role (role-a) in Account A. The ECS Cluster is in Account B. I have a role in Account B called role-b that should have all the permissions needed to run ECS Tasks and connect to ECR etc, and I'm trying to establish access to this role so that only role-a in Account A can assume it.
When I check the sts identity on a worker node using boto3, it gets returned as arn:aws:sts::494531898320:assumed-role/role-a/botocore-session-1631223174. This last bit at the end is always a random number. Because it's constantly changing I'm trying to use a wildcard in role-b's Trust Policy so that my worker nodes will always be able to assume this role in the other account and run ECS:RunTask operations with it in Account B's ECS Cluster.
Below is my trust policy for role-b.
# role-b in Account B - The account where the ECS Cluster is.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:sts::494531898320:assumed-role/role-a/*"
}
}
}
]
}
However, this doesn't work. My Airflow worker nodes instantly get an error that role-a can't assume this role-b role. Is my wildcard condition not working? Do i have to put a sts:AssumeRole policy in the actual policy attached to this role-b role instead of only in the Trust Permissions?
It'd be a lot easier to do this all in a single account but that's not an option for my use case as of right now. I'm kinda lost on how to proceed and haven't found great examples of how to properly implement this - any help would be appreciated !

Answer 1

sytech's suggestion was correct but seems to have been half the answer; the IAM Role ARN (arn:aws:iam::<account>:role/<your-role>) needs to be in the Trust Policy, not the assumed-role/xxx bit that my sts identity was spitting back.
The other thing I had to do was attach an IAM Policy to role-a that gives sts:AssumeRole access to the role-b in Account B so that role-a actually has permissions to call the AssumeRole API operation on that resource in the other account.
Without this, even though the Trust Policy was now correct it was still returning an AccessDenied simply because the role-a was never given permissions to do an sts:AssumeRole Operation.