Cloudflare Access / JWTs

[chasers]

It would be great to be able to access a JWT from a request and handle it in a Livebook.

• maybe a smart cell?

Not only would that JWT provider know that identity accessed which Livebook but the Livebook author could then pull data from the claims to do things inside individual cells.

• e.g. if you wanted to make sure and log who was querying a database from a Livebook you could do it this way

[josevalim]

You can try a smart cell. They run in an iframe, so you may have permission issues, but worth checking. otherwise the best option is to require an input (which the user will have to explicitly fill in for now).

[krzysztofwos]

Perhaps my question is a little off-topic, but since it relates to Cloudflare Access, it might be good to include it in this thread.

Is it possible to secure Livebook with Cloudflare Access's self-hosted Application?

I am trying to deploy Livebook on my machine and expose it on the web with Cloudflare Access using the following Docker Compose configuration:

  cloudflared:
    image: cloudflare/cloudflared:latest
    environment:
      TUNNEL_TOKEN: <token>
    command:
      ["tunnel", "--no-autoupdate", "run"]
    restart: unless-stopped

  livebook:
    image: ghcr.io/livebook-dev/livebook:latest-cuda11.8
    environment:
      - LIVEBOOK_TOKEN_ENABLED=false
    volumes:
      - /data/livebook:/data
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              capabilities: [gpu]

I then expose this with a tunnel under livebook.<mydomain>. This works fine with token authentication, but since I am the only user, I would like to secure this as a Self-Hosted Application and have a link to Livebook in my Cloudflare launcher. It's a very nice way of getting my Livebook deployment securely accessible from anywhere.

However, if I set up Cloudflare Self-Hosted Application to protect that route, Cloudflare restricts access to all the routes, including /public/*. So, when I access my notebook, I get the following error:

Failed to load the widget JS module, got the following error:

    Failed to fetch dynamically imported module: https://livebook.<mydomain>/public/sessions/qr7qgsrdqeqfllndf2z3znd7shvilh4gx2ekwzvj/assets/lt343epve5begwldnkrw3qthqi/main.js

See the browser console for more details. If running behind an authentication proxy, make sure the /public/* routes are publicly accessible.

[bamorim]

I just faced that exact same problem. The iframe application also runs side by side with livebook server, but by default it is on the 8081 port. So all I've done was to create another ingress, higher up on the list, specifying the path /iframe and pointing to the 8081 port instead. This is how it looked (I edited the html to hide the domain)

Then finally, I added LIVEBOOK_IFRAME_URL=https://livebook.<mydomain>/iframe/v4.html env variable to my livebook config.

Now this works because now the iframe is on the "SameSite", so the browser includes the cookie in the request, which makes Access happy.

Edit: forgot to mention about LIVEBOOK_IFRAME_URL

[josevalim]

@bamorim you should be fine with having an ingress on the whole port as well (but restricting it does not hurt). We have plans to reduce the reliance on the iframe/ path and use it only for path dependencies.

[jonatanklosko]

Now this works because now the iframe is on the "SameSite"

@bamorim serving iframe from the same origin makes the auth work, but it makes your Livebook vulnerable to XSS (any JS running in the iframes will be able to modify anything on the whole page). Using a different port (or a different URL for https://) is exactly to ensure the iframe is loaded from a different origin, hence sandboxed iframe content has no access to the parent page.

We have plans to reduce the reliance on the iframe/ path and use it only for path dependencies.

@josevalim that's for /public/, the iframe is something else :D

[bamorim]

Would it be possible to configure a different domain for the /public/ then? Because then it would be easier for me to put another tunnel at something like public.livebook.mydomain routing just the /public path.

[bamorim]

Ok, Cloudflare UI is not great, but I figured out how to allow just one path.

You have to create two applications, mine I named

• Livebook
• Livebook Public

The public one, you will set the path:

And then you attach only one policy, which is bypass

The other one I setup as normal, without the path and with the Policy to only allow who I wanted.

[spunkedy]

I have mine hosted where port 8081 gets mapped to a sub path on the same proxy where / is hosted and it works well.

…

On Sat, May 6, 2023, 1:07 PM Bernardo Amorim ***@***.***> wrote: Would it be possible to configure a different domain for the /public/ then? Because then it would be easier for me to put another tunnel at something like public.livebook.mydomain routing just the /public path. — Reply to this email directly, view it on GitHub <#1857 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIUL2BIP4M2RYPHJZGFS3XE2HPDANCNFSM6AAAAAAW4JRDKA> . You are receiving this because you commented.Message ID: ***@***.***>