Minimal IAM role for Serverless Framework

Serverless Framework
,
1

Hi everyone,

Few years ago my team considered using Serverless Framework but eventually we were forced to choose CDK/Terraform since our security-department didn’t want to grant power-user/admin IAM role permission to the Serverless Framework.

I see many articles regarding minimizing and narrowing down IAM role for Serverless deployment but all are from ~2018. I wonder if there have been any update/progress.

I’d like to use Serverless for my next projects/teams so i wonder if the IAM role concerns are still there.

To be even more specific - we identified multiple AWS projects where we need S3, Lambda, SQS and SNS so i wonder if it’s possible to limit Serverless scope in a way that it won’t be able to access existing resources ( and just manage/create the Serverless resources).

thanks in advance (i apologize if it’s too vague/unclear)

2

Since the start there have always been ways to limit the scope of permissions for Serverless Framework. The problem with doing that is it very quickly becomes a very time consuming and tedious task as there is no real minimal set to use. Every implementation is different, every service deployed makes use of different resources within AWS and so each one has to have a unique set of credentials deployed. For that reason, when I was working in an environment such as the one you mentioned we implemented the following:

  1. Developers had access to their own AWS accounts to develop and experiment in so that nothing they did coul affect production. You could do this with a single shared account if you want to as well. They can have admin permissions in these accounts and so focus on solving the problem not worrying about security yet.
  2. When they were ready to integrate their changes into production, they created a test user with no permissions and would make a deployment using credentials of this user.
  3. A deploy would return an error about missing permissions. They could then add those missing permissions to the test user. Then deploy again. Deal with the next error. And so on until deployments resulted in no errors.
  4. Specific requirements for the permissions document could also be put in place such as ensuring that specific and generic resource names were used; i.e. no dynamodb:* and so on.
  5. They could then merge their changes including a file as a part of the service that contained the entire set of permissions needed. The devops team could then review and create/update the deployment user as needed in order for the service to be deployed to the production account
1 Like
3

Thank you !! I really appreciate the details/approach. Will definitely take this approach back to my security department to see if we can adopt it .

Z.