Hi. Looking for some tips on self-hosted authentication / authorization (user logins, roles) when running our own Prefect Orion (2.0) server. We can't use Prefect Cloud due to compliance issues with using the SaaS offering (despite its hybrid security model), and this seems to be about the only box not checked for what we want the tool to do in standalone form. I don't want to have to open it up and bolt on FastAPI OAuth2 support to the web api. Any other solutions or workarounds to make it so that anyone on the network can't arbitrarily start, stop, modify flows? Maybe there's a way to allow all GET requests and block any POST/PUT/DELETE etc. to effectively make it read-only by default, and writable for privileged users?

Hey Keith, We run our own Orion API server and have looked into similar problems. We haven’t (yet) solved it, but have a general idea of our approach we’re happy to share. When building an AuthN and AuthZ, those are commonly broken into two different systems, with the AuthN handling the N many different ways to authenticate (SSO, JWT, username/pass) etc. Once authenticated, most solutions involve some form of an auth token. I’ll focus more on AuthZ as that is the more useful discussion w.r.t. Prefect. Our approach for tackling this is involved: • Middleware server responsible for calling to our AuthZ server, passing along the users token. If no token, redirect to AuthN server • AuthN server evaluates request and returns permitted or not • Middleware server then takes action to forward along the request For the policy aspect, we’ve prototyped an OPA policy https://www.openpolicyagent.org/ that our Prefect resource policies against the users request and makes a Yes/no decision. In our POC, we ran this as a sidecar next to the orion server & middleware server for latency purposes. Alternate options are to use • Auth0, which can handle both AuthZ & AuthN, with some caveats/tradeoffs • Keycloak https://www.keycloak.org/ Hope that helps!

Hi Keith, in addition to Cole's excellent suggestions, you might consider putting a Caddy webserver in front of the Orion server and then add Caddy security. It has authentication, so you could hide the UI behind a login screen. It also has RBAC and can filter by HTTP method, so you can make your access controls quite fine-grained. Users would still be able to see everything in the UI, but you should be able to make it so they can't do everything depending on their role. Also note that if you set PREFECT_API_KEY in your Prefect config on the machine(s) where you run Prefect agents, HTTP requests sent by the agent should contain the API key in the Authorization header. I believe you'd be able to configure Caddy security to grant full access to the Prefect API if an HTTP request contains a valid API key in the header.

Hi there. We have been running Prefect 1 in Kubernetes for a year now, using Traefik for ingress and the External Auth Service (EAS) middleware for auth. This has worked quite well, however there are some caveats. AuthZ is only limited to whether the user in our Tenant actually have access to Prefect, and will not control access to different Prefect teams or projects. I believe the Open Policy Agent should be able to handle this, but for now this has been acceptable for us. Secondly, token refresh is a little "iffy". The Prefect UI will simply disconnect from the Apollo instance when the token expires, and not refresh it. Accessing the Prefect UI with an expired token can also lead to the user being stuck on the Prefect "loading screen", or present the user with the initial UI setup. These symptoms are commonly fixed by either refreshing the UI or going to the URL of the Apollo service, which usually prompts the user to log in. We are using EAS for several other services without issue, but since the Prefect UI talks to the API/Apollo from the browser session and not the backend, the access token refresh is not triggered.