The Serverless framework is an easy to use, mature and well understood framework for scaffolding and deploying functions in to AWS. For the main part, it’s a pleasure to work with. One of the really great features is the developer story. Specifically that with a bit of YAML, some simple code and the serverless CLI, you can spin up an AWS lambda. Well, sort of. The key ingredient missing from that that list is, of course, the right security permissions/policy.

The serverless framework was my former clients go to framework when working with AWS lambdas, for reasons which are obvious when you use it. One of the downsides however, of working with a well organised, innovative client with a mature engineering approach, is that I didn’t have to give consideration to the permissions that are required to deploy a lambda. My client had built a custom CI/CD pipeline making it easy to adopt and provision all manner of AWS resource, including lambdas. Furthermore, they had made great use of SSO, MFA and the AWS Security Token Service, providing the engineering community with an ability to assume a role with enough privileges to be able to sls deploy a lambda in to an AWS account, right from our laptops*. Needless to say I’d highly recommend that code and infrastructure changes go through a CI/CD pipeline, but being able to deploy a lambda right from my laptop proved invaluable numerous times, particularly when needing fail fast or when working on new lambdas.

Having moved on from the client I refer to above, and now working with a new client who needs help to to mature their delivery and engineering approach, it occurred to me that I ought to find out what IAM permissions are required to deploy a AWS lambda using the serverless cli. If I had to create a custom ‘developer’ policy, to help make that serverless developer story fruitful, what would that policy look like?

After a few attempts I came up with the following bare bones policy, aimed squarely at supporting a lambda deployment. I masked my IP address but left the condition in place to show that you can restrict a policy to an IP address/IP range, something that I discovered as I iterated on the problem.

The above is a basic policy, which you could easily extend by adding “sns:CreateTopic“, “sns:DeleteTopic“, “sns:GetTopicAttributes” (for example) in order to support engineers wiring up an SNS lambda trigger.

Conclusion

Thankfully adopting technologies like AWS lambda is made much simpler through the serverless framework. The serverless website even has link to an  IAM credentials gist to make adoption easy, though the gist in question is a far too permissive if all you want to grant is the right permissions to deploy a basic AWS lambda.

* My client had several AWS environments. The first of which was a QA environment per team that ensured isolation. Needless to say we only ever deployed lambdas directly from our laptops in to the teams QA environments, and typically when working on a new service as it allowed us to get tracer bullet feedback.