Hi Prefect, I was wondering if it is possible to connect the prefect UI to an internal network, that might not be available from the host I'm viewing the UI with? It seems that currently

server.ui.apollo_url

is called from the browser (and not from the server where the UI is running). For example, I have a docker-compose managed prefect server somewhere with an internal network called

prefect-server

, which has both

apollo

,

ui

, and the other prefect server services. Using

apollo_url="<http://localhost:4200/graphql>"

only works if I also bind

apollo:4200

to the local

4200

port where I'm running the browser from. For example setting

apollo_url="<http://apollo:4200/graphql>"

and letting the UI -> GraphQL connection go via the docker network wouldn't work afaik. In this case I see the following error in my browser's JS console:

VM9:1 POST <http://apollo:4200/graphql> net::ERR_NAME_NOT_RESOLVED

Hi @Peter Roelants - by definition this wouldn't be possible; the UI is a completely separate front-end only application. It needs to have http access to the API in order to populate, since it doesn't have its own backend API to act as the proxy before serving content.

Oh, it's fully frontend, I see. Are there any plans to create an extension to be able to expose the Prefect UI without exposing the server itself? And is there any known current workaround (besides tunneling the apollo API)?

At this time we don't have plans to extend the UI for a use case where the API is unavailable to the host; I think either tunneling or some other network tooling (a private VPN, for example, that can resolve the API url) is the best way to handle private network configurations at the moment.

@Peter Roelants Not exactly tunneling, but something like https://github.com/oauth2-proxy/oauth2-proxy might help in your situation. It’s still proxying though, but there’s no hassle of VPN/networking setup. We use it with Keycloak and so far everything works pretty reliably

Thanks Andrew. Are you using the OAuth Proxy to protect the Apollo GraphQL endpoint the UI is communicating with?

Yes, exactly.

Hi @Andrew Druchenko. We are trying to do something very similar i.e use a proxy to protect the Apollo GraphQL endpoint. We have used https://github.com/vouch/vouch-proxy which I think is similar to oauth2-proxy. However we have not yet been able to make the UI add authorization bearer headers on the requests it is making to Apollo. I would be very grateful to hear how you have solved this?

@Jonathan Wright Can’t give you an exact recipe with regards to vouch-proxy, but in essence, it works via so-called secure cookie which is issued by OAuth provider, in our case it is Keycloak. Here’s a sample config for Oauth2-proxy and Keycloak https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#keycloak-auth-provider What happens is following 1. You try to access Prefect UI in browser (in our case it is a dedicated subdomain

<http://prefect.yourcompany.com|prefect.yourcompany.com>

) 2. Oauth2-proxy checks for secure cookie and if there’s none or it is expired, presents you with a special page asking to redirect you for login at your Oauth provider 3. You click that button, then you’re redirect to login page and then you’re redirected back again to

<http://prefect.yourcompany.com|prefect.yourcompany.com>

4. At this point, your browser has secure cookie issued by Keycloak 5. All requests to prefect backend API (apollo) issued by Prefect UI from browser are all having secure cookie, so that they are correctly proxied by oauth2-proxy to upstream apollo service The only “glitch” and minor inconvenience is that once cookie expires, Prefect UI just starts displaying you tons of weird errors (since all backend requests start to fail at this time) Only full browser refresh helps So, TL;DR; — try to find something similar with your OAuth provider and/or use Keycloak

Thank you. We are stuck on 5. We have a cookie in our UI browser session (issued by vouch and okta) but the traffic from the UI to Apollo is missing authorization. I’ve attached an image of a request going to Prefect Cloud which is what we are hoping to see in our local setup. But we have no authorization header. It sounds like you didn’t have to change the UI to make this work?

Well, we run our own Prefect deployment and not using Prefect cloud. Maybe, that’s one direction worth investigation? As I said above, there are no special headers set by oauth2-proxy and/or Prefect UI (we’re using stock version without any mods)

I was just comparing our approach to the auth used by Prefect Cloud. I can see now that we shouldn’t expect to see an authorization header in our cookie based approach. Looks like something is not quite right in our nginx/vouch configuration.