Open iliana opened 7 years ago
Driveby thought dump:
An obvious problem to solve is storing the iam secrets.
Travis has a concept of encrypted secrets. However, these are secure by only functioning for PRs that aren't coming from forks. I assume that rules them out entirely.
That's not to say Travis is ruled out, just relying on their encrypted secrets.
Jenkins has a slightly nicer concept that almost works but is a pain to setup. Jenkins secrets can be made available during PRs, but a set of files can be marked as "sensitive" and are taken from master instead of from the PR. This set of files is the Jenkinsfile (for obvious reasons), but would also be configured to be all other files executed at any point during stages that have access to the secrets. This would allow PRs to change the example code, but not e.g. a bash script that uploaded the code to lambda and needed said secrets.
The above is meant as an aside though because I can't seriously recommend using jenkins and the above behaviour is finicky at best to configure.
I think that an easier solution than either of the above though is simply not exposing IAM secrets at all. They have the unfortunate problem of, well, being secrets. An alternative would be to simply not have a travis IAM user. Instead you could have some magic endpoint which contains the IAM user and takes a lambda tarball to run, which it runs and proxies back the output of.
That has a nice property that the IAM user will certainly never be exposed and, since the CI configuration for the actual running isn't exposed (only "upload to this url and wait", not "do these aws operations"), it's much simpler to reason about.
The resulting attack surface is basically that arbitrary people on the internet can now run arbitrary code. This isn't easy to fix perfectly, but it can be massively improved by requiring the request to include the github PR or travis build id, which can then be verified to be valid and used for rate limiting.
As a bonus, it's possible that endpoint could be a lambda function using crowbar to do all the above :)
I have some experience with Travis here. Im mostly used to provisioning IAM user credentials for deployment with serverless framework apps ( crowbar included ).
I think this would be doable with private Travis env vars. Travis takes measures to restrict what access to forks have to those. Iam is also designed specifically for restricting what you can do with them should you gain access to them. I think Travis runs would be doable.
We might find some inspiration in the rusoto project. I believe it does something similar for integration tests
Last I looked into it, private travis variables couldn't be used for pull requests from non-org members. The above comment I wrote was with the assumption that testing arbitrary pull requests is a goal, and that we can do it safely enough, but that travis might not be the right vehicle.
Has it changed so that you can have travis include such secrets in non-org-member PRs?
You're right. This is looking like not a good option :/ https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-settings
I think a satisfactory solution could be a ci-setup of the following:
Some nice properties of the above:
Some downsides:
I think the biggest downside is that we have to build this bespoke system to use it. I could maybe have a swing at it, but I'd like to first air the idea and see if anyone has a better idea or can poke holes in this one.
This is basically the same idea I was expressing in my previous comment here, just fully fleshed out.
Travis should compile and run all examples in AWS Lambda and verify output on pull requests.
This is, of course, questionable from an AWS account security perspective. Some thoughts on mitigation:
Lambda::Function
resources)