Today I came across the following exception while working with the AWS SDK for Amazon Lambda:
com.amazonaws.AmazonServiceException: Cross-account pass role is not allowed. (Service: AWSLambda; Status Code: 403; Error Code: AccessDeniedException; Request ID: xxx)
At first I was a bit puzzled where this exception might come from; but when I found out what the problem was, it seemed to be pretty obvious:
I tried to upload a lambda function to one AWS account while specifying an execution role that belonged to another AWS account.
So that could easily be fixed by providing a role belonging to the correct account!
Alternatively, this error might also occur when you deploy a lambda function which has references to another cross-account role in the template.yaml file (as mentioned by Steven T in the comments below)
UPDATE
As mentioned in the comments by rjhintz, if you require to use the role from another user, you can do so by modifying the policy for the role as follows:
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":[
"arn:aws:iam::123456789012:user/user1",
"arn:aws:iam::123456789012:user/user2"
],
"Service":"ec2.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
I wonder if you could still use the other account if you explicitly added a trust relationship to the account/user in the role’s IAM trust policy.
That’s a good point! Have you tried it?
That would probably mean to add something like the following to the policy?
{"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::AWS account ID that contains the role:role/role name"
}
In IAM for a role, under Trust Relationship, you could try adding something like this for each user who will call the function, substituting the account number(s), user name(s), and service name(s)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/user1",
"arn:aws:iam::123456789012:user/user2"
],
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Haven’t tried it for anything but the single account case calling from Python. The EC2 service parameter is left over from the earlier state of the trust relationship file before I added the AWS user ARNs. No wildcard for users.
Perfect! That’s very useful, I’ve added this to the post above! Thanks!
Hi Max,
I’ve come across this issue today, turns out the issue was related to attempting to deploy a lambda function, which had references to another cross-account role in the template.yaml file. I was using this role to specifically allow Lambda function accesses to backend services.
Hi Steven, thank you for your comment! I’ve added a line to the post above for other seeker’s of cross account roles!