Generate IAM permissions for invoking lambda from lambda

Hello,

I am very new to the Serverless framework. I tried to invoke a lambda function created in the serverless framework from another serverless framework lambda function (using the aws sdk) and I received an error along the lines of “… is not authorized to perform: lambda:InvokeFunction on resource: …”.

It seems like this is something I’d setup in the serverless.yml file, but I’m just not sure what I should be doing.

Any help is much appreciated.

I just ran into something similar with api-gateway to lambda to dynamodb. So I went into my AWS console and found the role serverless created (in the IAM console) and attached an admin policy to it (just for testing purposes) and cleared it up.
I too would think this could be configurable but haven’t quite figured it out. Still finding my way around as well. Examples would be great.

Just watch out with that Adrian, as you might have issues/errors when removing the service that you’ve modified manually since resources are managed by CloudFormation in the background.

Ideally you would give you functions more IAM permissions. Here’s what I have to allow my functions to call each other:

provider:
  ...
  iamRoleStatements:
    - Effect: Allow
      Action:
        - lambda:InvokeFunction
        - lambda:InvokeAsync
      Resource: "*"

This way the permissions are managed by CFN, and will be cleaned-up for you (and in the right order) so you don’t get any surprises.

3 Likes

Thank you @rowanu! That worked beautifully. I am very quickly learning that I need to learn a lot more about CFN in order to get the most out of this framework (and AWS, frankly) :smile:

1 Like

I agree. I had not seen the lambda yaml for working with DynamoDB, when I tried some I did find out on the web I was having no luck. So thanks, I’ll refactor.

Is there a good place in the docs to see these examples? Or am I missing it?

NM … I found this https://serverless.com/blog/serverless-v1-0-beta-release-2/
Sorry, getting there slowly.
Works great.

Thanks! Works like charms.

using Resource: "*" in your policies often represents a security risk. You should probably use something more granular and specify a sourceArn specific to the lambda you would like to be allowed to invoke.