Policy for (travis-ci) deployments

Serverless Framework
1

Carrying on from Alleviating continuous headaches I’m trying to get my lambdas to deploy from a git push from the master branch using Travis CI.

However the user / policy I’m thinking that I need to setup for the CI via AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY seems to be quite over reaching (to say the least!), since it needs to be able to orchestrate any AWS resource IIUC from the IAM stanzas in serverless.yml

Short of specifying my own power user keys, why do you guys recommend I do? I think this is AWS’s response: http://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html but I couldn’t find serverless’s documentation on the matter.

With Apex.run, the following policy is sufficient I think, because the role that it runs in has the assigned permissions after the fact.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:*"
            ],
            "Resource": [
                "arn:aws:lambda:REGION:ACCOUNT_ID:function:*"
            ]
        }
    ]
}

But with serverless I get:

ServerlessError: ServerlessError: User: arn:aws:iam::ACCOUNT_ID:user/travis-lambda-deploy
     is not authorized to perform: cloudformation:DescribeStackResources

So what’s the right deployment policy for the sls framework?

Sidenote: One important element missing from sls deploy list is that I can’t see who uploaded a lambda change. It’s happened before and I’m sure it will happen again, when a deployment is corrupted since someone overwrote a working lambda with a bad node_modules state or something silly like that (node 8), and I want to root out those sort of issues.

2

Hey @hendry. Good idea on the “who” for the sls deploy list command! I’ve added this as an issue on https://github.com/serverless/serverless/issues/3756

We have been investigating a more fine grained permissions model for the framework, it’s quite challenge with different services requiring access to difference pieces of AWS. @eahefnawy was looking into this.

3

This is the issue were the provider permission levels were being discussed https://github.com/serverless/serverless/issues/3084

4

Thanks for the followup David!

I favour the two roles:

  1. Admin for creating stuff, i.e. when I run sls deploy
  2. CI deployment role, when travis ci runs sls deploy it’s unable to create new IAM resources, but only deploy over what’s currently there?

Guess the weak analogy is:

  1. sudo make install (where I assume the perms, like some sort of App install)
  2. binary --upgrade