expose a live view of the tilt interface securely over a network
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10.1k
- Forks
- 413
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 6
Description
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:
- Tilt defaults to binding to
localhostand cannot be accessed from remote machines over the network - 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).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No implementation files or tests are identified. Start by reviewing the --host behavior and the Tilt Web UI endpoints, then examine the proposed Tilt Cloud or GitHub integration options. Done would require an agreed authentication design and a defined security boundary for network-accessible UI clients.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication, backend, networking, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100