tilt-dev / tilt

Define your dev environment as code. For microservice apps on Kubernetes.
https://tilt.dev/
Apache License 2.0
7.58k stars 298 forks source link

expose a live view of the tilt interface securely over a network #3517

Open andymartin-sch opened 4 years ago

andymartin-sch commented 4 years ago

One thing that came up in a recent meeting with @victorwuky is that the Tilt UI doesn't currently require any authentication from clients that browse to it.

This has historically not been an issue because:

  1. Tilt defaults to binding to localhost and cannot be accessed from remote machines over the network
  2. Tilt doesn't expose sensitive functionality through the Web UI (Note: I have not looked at all the endpoints exposed by the Tilt server - it's possible this isn't entirely true)

Ever since support was added for the --host parameter, it's been possible to set --host 0.0.0.0 and (1) is no longer true in deployments where this is the standard way of launching Tilt. (This is the case for us.)

What we talked about a bit was that it's possible that future Tilt features may start to carve away at (2) too.

For example, what if Tilt exposed a shell that let users run kubectl commands against the cluster right from the browser? That would be a really cool feature, but currently it would mean that anyone on your network would have full access the cluster as well.

Or what if Tilt let people add breakpoints or debug/edit the execution of the Tiltfile or other resources? Really cool feature, but it would let anyone with access to the Web UI call local() and have code running directly on the host machine.

One potential solution might be to more directly integrate Tilt UI with Tilt Cloud (or GitHub, etc) -- something like: "because of some setting in my Tiltfile, Tilt knows that this UI should only be made accessible to the user that Tilt Cloud/GitHub/etc recognizes as User X".

I'm not sure that it makes sense to do this kind of big refactor, but I wanted to file this issue to (a) get a discussion started about whether Tilt developers generally see the Tilt UI as a privileged interface or not and (b) think about potential workarounds if features start coming up that would chip away at (2).

wu-victor commented 4 years ago

Thanks for starting this discussion @andymartin-sch . This is an interesting use case. Tagging @jazzdan here for tracking and also @nicks to see if this is something interesting / seen elsewhere.

https://github.com/tilt-dev/tilt/issues/2060 is about accessing containers from within the Tilt UI, but doesn't bring up any authentication ramifications.

nicks commented 4 years ago

This is a good question.

One high-level aside: I try to avoid using phrases like "privileged interface" when talking about this, since it quickly leads to context collapse problems and big misunderstandings (cf https://twitter.com/jessfraz/status/985948824429461504)

w/r/t the security model of Tilt's web interface

if the user is on an untrusted network, I would strongly discourage them from binding the Tilt web interface to --host=0.0.0.0.

There are simply too many ways to accidentally leak secrets when you're doing kubernetes stuff in dev (e.g., printing an env variable with a secret token or printing the kubectl auth credentials, which would let anyone on the network do kubectl execs).

There are features that we might add in the future that might make this even worse from a security standpoint, but TBH, I feel like Tilt can't reasonably protect you from all the security problems with this setup.

That said, I think there are many ways we could make it possible to do this securely without too much effort. e.g., add a tilt up --password flag that protects the web server. Or opt in to some other cookie-based auth approach.

andymartin-sch commented 4 years ago

Thanks, agree with all of that!

I think tilt up --password would likely be totally sufficient and much simpler than involving Tilt Cloud / GitHub / etc for auth.

That said, I think what we'd really like is to get away from running --host 0.0.0.0 entirely. The two key use cases that make us need it currently are:

Part of me thinks both of these could also be solved by some kind of integration with ngrok or if Tilt Cloud supported this same functionality natively (as in: tilt is no longer responsible for running a webserver locally on the machine, it just sends state information up to cloud.tilt.dev and all users view it there).

We can schedule some time on our end to explore the ngrok integration in the next few months, but if you all think you may explore the latter option in the next ~year, let us know and we may back off and wait :)

nicks commented 4 years ago

We discussed this ticket a bunch today over video.

I like the idea of having "live" view of a tilt instance on someone else's machine. To do that, we need a better way to discover the view, and a better way to make that secure. I'm going to update the title of this to better reflect that.

ya, you're right that you could hack something together with ngrok, though it would have some rough edges

nicks commented 3 years ago

The newest version of Tilt (v0.17.9 should work with https tunnels, so that you can open a live tunnel over to Tilt over ngrok / https

Cloudflare team wrote this great blog post on how they use Argo Tunnel w/ Tilt to get this behavior https://blog.cloudflare.com/how-argo-tunnel-engineering-uses-argo-tunnel/ and i wonder if we could make this either really easy to stitch together with an arbitrary auth system, or offer a hosted version of it

andymartin-sch commented 3 years ago

Thanks for the link! That's really interesting. Will let you know if we start experimenting with anything on our end.