When deploying a function that is triggered by an EventBridge event, Serverless framework define a resource-based policy that allows that EventBridge rule to trigger this particular function. Example below:
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "validation-api-dev-handleNewValidationNeededEvent-validation-api-dev-handlenewvalidationneededevent-",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:{{account_id}}:function:validation-api-dev-handleNewValidationNeededEvent",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:events:us-east-1:{{account_id}}:rule/dev-validations/validation-api-dev-handleNewValidationNeededEvent-rule-1"
}
}
}
]
}
It works very well when the function and the EventBridge queue definition sits under the same application.
However when the event bus is in a different serverless app it looks like Serverless framework has a bug when setting the AWS:SourceArn. It mistakenly sets the source ARN (that is in another service) with the target service. For example:
Correct rule ARN: arn:aws:events:us-east-1:{{account_id}}:rule/dev-applications/validation-api-dev-handleNewApplicationEvent-rule-1
ARN considered by sls: arn:aws:events:us-east-1:{{account_id}}:rule/dev-validations/validation-api-dev-handleNewApplicationEvent-rule-1
Note the confusion made by sls with the service names: dev-applications is where the event bus/rule is deployed, dev-validations is where it’s being used.
For the time being I fixed this by manually adding this permission via CLI to that particular lambda.
Any help on that?