Open Jesse-jApps opened 1 month ago
hi @Jesse-jApps - thank you for the issue!
there's been some discussion on this here, and I think its worth revisiting at this point.
I think we'd want to avoid user/pass auth, as there is explicitly no concept of a user in OSS, but a simple token auth might be a good option. What do you think about that?
@zzstoatzz It it good have same authorization as prefect cloud where we can use prefect api key in authorization to secure the prefect OSS server
If you are willing to add this feature, there were users who were willing to add a PR. @pbecotte ?
Thanks for the feedback. Back in 2020 the decision was to not add any auth, since it is expected to be network internal only, see here.
I don't know how much of the view has changed by now.
In my case I work and have worked on plenty of smaller projects (shops, web tools, etc.), which are all publicly accessible and run 80% on self-managed servers.
When using prefect for those projects, I can do everything without exposing the prefect api, except using the dashboard.
If setting the --host to a internal address, I can setup a protected nginx to gain access to the dashboard, but since the dashboard is using the --host address for lookups, it doesn't properly work.
So an alternative to implementing an auth-mechanism, is by having more control over how the dashboard accesses the api.
So beside the PREFECT_API_URL
a PREFECT_DASHBOARD_API_URL
(optional) would be helpful.
Describe the current behavior
When deploying Prefect on-premise, it is not possible to configure custom authorization methods, such as Basic Auth. For example, when somebody uses a reverse-proxy setup and wants to protect the API and Dashboard with additional authorization. While Prefect Cloud uses API keys for Bearer-like authorization, on-premise deployments lack configurable authorization options.
Describe the proposed behavior
The option to define
httpx_settings
globally. The idea is, that this somehow implemented:But properly, generally and via a proper config.
Example Use
Possibly authorization can be defined via ENV-Variables.
Additional context
No response