Open andymartin-sch opened 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.
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.
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:
tilt up
over ssh (some devs prefer doing work remotely on linux workstations and need a way to still hit the Tilt UI in their browser on a separate machine)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 :)
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
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
Thanks for the link! That's really interesting. Will let you know if we start experimenting with anything on our end.
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:
localhost
and cannot be accessed from remote machines over the networkEver 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).