How to protect the production stage when working with Serverless + AWS?

I wonder what is the recommended approach when using SLS regarding the protection of some particular stages, especially production.

Today, I’m the only one working on the product. I created a IAM serverless-admin account and identified myself using serverless config credentials --provider aws using this account’s key/secret. It’s necessary because serverless does a lot of stuff on the background and needs admin access.

Tomorrow, if I wanna add an intern on the project, or another collaborator, how can I give him a limited access? I guess I need to create another IAM account with less permissions? But serverless will need tons of permissions to run properly, so, how do I deal with that?

I was thinking about somehow allowing all actions on the development stage for that new account.

For instance, I use the following arn for my database table (dynamoDB), and I have two dbs, one for development and one for production, could I somehow have this kind of rule allowed?:

arn:aws::::*development*

I don’t want an intern to have any kind of access to the database production, or upload anything to the database bucket (which is the same bucket for development/production but in different sub folders).

I don’t know if that’s the right approach, but since serverless CLI needs access to about everything I don’t see another way of configuring account’s permission, but based on the stage.

@Vadorequest-SL Unfortunately there is no good answer. We have a number of open issues on the matter https://github.com/serverless/serverless/issues/3084 & https://github.com/serverless/serverless/issues/1439 and haven’t nailed down a more restrictive policy due to the large number of use cases people have.

@Vadorequest-SL

There’s a Serverless IAM policy generator using Yeoman that does a pretty good job of handling this. It will configure the API Gateway, Lambda, Cloudwatch, etc. access that’s standard for most Serverless services. If you’re using something non-standard (RDS, Elasticsearch, etc), you’ll need to add the additional policies yourself.

Also, here’s a blog post about IAM basics with Serverless.

Let me know if those help :slight_smile: