Putting Livebook behind Teleport

[slashmili]

Hi!

I'm trying to put Livebook behind Teleport. However I'm running into an issue with the iframe that Livebook loads.

How it works:

a. I'm hosting the Livebook on https://livebook.teleport.mydomain.com
b. When loading a smartcell, it opens an iframe(with sandbox mode) which loads https://livebookusercontent.com/iframe/v5.html
c. the v5.html now loads javascript on my livebook.teleport.mydomain.com/assets/.../main.js

The problem is that when the v5.html opens main.js on livebook.teleport.mydomain.com , Teleport–which acts like a proxy–detects the request as a new request and redirects the request to the teleport login page. which fails because the login page of Teleport doesn't have Access-Control-Allow-Origin: * in the header

Note: If I test the flow in chrome with option --disable-web-security I'm able to load smartcells

---

We looked into different options,

1. Was to host the iframe under livebook-iframe.teleport.mydomain.com and configure LIVEBOOK_IFRAME_URL but it was the same, Teleport didn't like that.
2. Putting iframe and Livebook service under same domain.

As I mentioned the only one that it works is if we put Livebook and the iframe service behind nginx and serve both under the same domain livebook.teleport.mydomain.com behind Teleport proxy.

flowchart TD
    A[livebook.teleport.mydomain.com] --> Teleport
    Teleport --> Nginx{Nginx}
    Nginx --> |/iframe/v5.html| IframeService
    Nginx --> |rest| livebook

Based on #2366 (comment) , we are loading the js from an iframe(using different domain) because of security reasons.

In my search, I came across How to Safeguard your Site with HTML5 Sandbox article which I guess explains what we are doing here with the sandbox option in iframe

And if I understood it correctly, in A sandbox approach section it says:

This means that even content coming from the same domain is treated with the cross-domain policy, as each IFRAME content will be viewed as a unique origin.

Does it mean it's ok to host iframe and Livebook under the same domain? and the security part of it is taken care by the sandbox option of iframe?

[jonatanklosko]

@slashmili unfortunately the Livebook web app and the iframe needs to be served from a different origin, more details:

livebook/assets/js/hooks/js_view/iframe.js

Lines 7 to 10 in 940d511

	// Additionally, we cannot load the iframe from the same origin as
	// the app, because using `allow-same-origin` together with `allow-scripts`
	// would be insecure (2). Consequently, we need to load the iframe
	// from a different origin.

The ideal solution would be if you could configure Teleport to pass all requests to Livebook "/public/*" path without authentication. Under these paths we serve assets from the kino packages, so not requiring auth should be fine, hence "public". Is that something that you can configure?

[josevalim]

If this is something we can do, would you send a PR updating the Teleport guide with the relevant instructions?

[slashmili]

@jonatanklosko I'm not sure if it's possible.

I'll update you(and docs) if there is any workaround.

[josevalim]

@jonatanklosko do you remember why we use separate domains even with the sandbox? Is it to stack the security benefits? If so, should we also serve the iframe from Livebook for people who need to opt-in into the same domain?

[jonatanklosko]

@josevalim the separate origin is crucial. We need the sandboxed iframe to have allow-same-origin to function properly, and also allow-scripts to run the JS. When both of these attributes are set, and the iframe is loaded from the same origin as the webpage, the JS within the iframe can access window.parent and effectively do anything, including removing the sandbox attribute from the iframe.

[josevalim]

Ah yes, thank you! I also found this: #968

[slashmili]

Thanks for the clarification!

[josevalim]

In case this does not work, we should probably remove the Teleport integration :(

[slashmili]

I understand and agree.

[josevalim]

I looked a bit at this and it seems it is not possible, I will submit a pull request to revert the integration. :(

[dkarter]

@slashmili I’m on the same boat. Encountered the same issue and spent many hours trying different things before giving up and eventually referred to this discussion. I’m curious to hear what you ended up doing or if you found any workaround.

[slashmili]

For the record we have given up on the idea of running Livebook on Teleport. We are looking for alternative tools to Teleport. Luckily for us it's easy because we just picked up Teleport.

I'll create a PR to revert #2296

[josevalim]

Thanks @slashmili! Please consider giving this feedback to them as well, if they understand that clients are living due to the ability to provide per-path restrictions, maybe they can implement the feature (if technically feasible).

[josevalim]

Btw, I think you can use Fly as very straight-forward alternative to Teleport.

You can deploy a new Livebook app like this:

fly machines run ghcr.io/livebook-dev/livebook:edge --app my-livebook --env LIVEBOOK_IP=:: --vm-memory 1GB

This will run a machine inside your Fly organization and not expose it to the real world. You can then use fly wireguard create to create a wireguard profile to connect to it. Only those with wireguard access will be able to access it.

[josevalim]

Oh, to clarify, once you deploy, you will be able to access the app on your browser as my-livebook.internal:8080. You can also set port 80 with LIVEBOOK_PORT=80.

[slashmili]

Thanks for the tip! We are using AWS and EKS (Kubernetes). The idea is to run one Livebook instance on the same cluster and be able to connect to any Elixir app. It would serve as a backoffice for all the running apps we have.

[anthonator]

@slashmili if you open an issue with Teleport can you please post the issue here so others can follow?