# Policy for (travis-ci) deployments

**URL:** <https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021>\
**Category:** Serverless Framework\
**Tags:** aws\
**Created:** [June 8, 2017, 6:30am UTC](https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021 "2017-06-08T06:30:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hendry](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/hendry/32/343_2.png) [@hendry](https://forum.serverless.com/u/hendry)\
**Post date:** [June 8, 2017, 6:30am UTC](https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021/1 "2017-06-08T06:30:53Z")

</div>

Carrying on from [Alleviating continuous headaches](http://forum.serverless.com/t/alleviating-continuous-headaches/1972/4) 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](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.

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

```

But with serverless I get:

```auto
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.

---

<div class="post-metadata">

**Author:** ![DavidWells](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/davidwells/32/201_2.png) [@DavidWells](https://forum.serverless.com/u/DavidWells)\
**Post date:** [June 8, 2017, 4:24pm UTC](https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021/2 "2017-06-08T16:24:10Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![DavidWells](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/davidwells/32/201_2.png) [@DavidWells](https://forum.serverless.com/u/DavidWells)\
**Post date:** [June 12, 2017, 2:09pm UTC](https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021/3 "2017-06-12T14:09:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![hendry](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/hendry/32/343_2.png) [@hendry](https://forum.serverless.com/u/hendry)\
**Post date:** [June 13, 2017, 2:11am UTC](https://forum.serverless.com/t/policy-for-travis-ci-deployments/2021/4 "2017-06-13T02:11:05Z")

</div>

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