Use traefik forward auth or some other proxy with authentication. Frigate will probably never have auth built in.

traefik forward auth- googling that, thanks. why is Frigate not planning on having auth built in?
(by the way thank you SO much for the work you do!)

No need to reinvent that wheel.

Well, and no disrespect - have you ever tried to use traefik auth? it's a bloody nightmare to get working. i like to use the app's built in auth instead of one central point of authentication

https://mitchross09.medium.com/how-i-self-host-my-own-sites-and-applications-with-unraid-docker-authelia-and-cloudflare-1f0d8e6f8912

have you ever tried to use traefik auth

For sure. I use it every day to provide consistent auth for several services I run on my server. I am using this. My setup is documented here.

There are also other options that could be a little simpler:

• oauth2_proxy
• nginx basic auth
• Just use homeassistant with the integration for access.

These are battle tested authentication systems that have major companies including mine running them through regular penetration testing.

I will probably create a guide in the docs for setting up simple authentication in front of frigate some day.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

What would be a good way to prevent people on the same local network from accessing the frigate webui port? I would like to keep frigate local, not expose it to WAN.

I've been trying to set up Authelia but I can't get it to work locally/internally only. The documentation is really WAN-centric. I just want the port to be protected by some kind of auth in my LAN.

Duckduckgo keeps throwing me back to this issue.

You'll want to not pass port 5000 from frigate to the device, have authelia be in the same docker network and expose frigate 5000 only via the authenticated domain / subdomain (very generic, really depends on your exact setup)

A Home Network architecture is way too simple, and often it got some very unsecure IoT devices in the same network as the frigate installation.

Spanning a Proxy with basic auth over Frigate is an overkill solution, especially for your Home, and no one can tell me how to use the home assistant integration then? At least, I wasn't able to find a proper way.
I'm no a stranger to things like that, how easy is it then for a non-tech-savvy person?

Is it not possible to just add a simple auth into frigate?
It would be MUCH more attractive then.

Is there a way to do this without a FQDN, especially as Frigate is already relying on NGINX. I'm using a local network to access my cameras and I have no intention of enabling external access to Frigate. That being said, currently anyone within our network has access to Frigate. Now, I could solve this by using a Firewall, but that seems like a really jank solution that leaves a lot to be desired. I've been banging my head against a wall for a while now and I can't think of a solution that would work on local network, because even if I set a host name for Frigate, users can still bypass NGINX reverse proxy, by connecting directly to the IP:Port, which would then involve even more firewall rules and fancy rerouting.

users can still bypass NGINX reverse proxy, by connecting directly to the IP:Port, which would then involve even more firewall rules and fancy rerouting.

you can not map the ports in the frigate container and instead use a docker network where only nginx has access to frigate directly, it can all be done in docker

users can still bypass NGINX reverse proxy, by connecting directly to the IP:Port, which would then involve even more firewall rules and fancy rerouting.

you can not map the ports in the frigate container and instead use a docker network where only nginx has access to frigate directly, it can all be done in docker

Is this referring to the standard DNS/FQDN setup or a basic home network? I know I can expose Frigate port to be only accessed by NGINX, but then Frigate can't log the correct IPs in NGINX log, because everyone is connecting through reverse proxy. At least I had that issue when I had Frigate in bridge mode and it was detecting everyone as localhost.

you would just use the logs of the NGINX reverse proxy and not use the frigate nginx logs

Even if using some other method to secure access to the web UI, the ability to create users with their own passwords and permissions seems like a very reasonable feature for a security product.

If I'm missing something here I apologize, but having both the feeds of all cameras and and full admin control available to anyone on the LAN in the out of the box config seems to crazy to me.

Even if using some other method to secure access to the web UI, the ability to create users with their own passwords and permissions seems like a very reasonable feature for a security product.

If I'm missing something here I apologize, but having both the feeds of all cameras and and full admin control available to anyone on the LAN in the out of the box config seems to crazy to me.

You can do this with Authelia

https://www.youtube.com/watch?v=kw_pohbKE3Y

Yeah. Super simple for LAN usage. You just need to purchase an external domain and re-route it to your home network, then block all external access (completely negating the point of an external domain), or setup a complex Active Directory Domain, because Microsoft REALLY does not like it, when you reroute vildcard *.server.local subdomain to an IP address. Then you only have to deal with 4 different docker containers (NGINX, MARIADB, AUTHELIA, REDIS) and hope that you are not running them on a Synology machine, because half of the ports are overlapping and NGINX can't work as a reverse proxy.

I discarded the entire project, because it was just too much hassle to setup and maintain, just to obtain the most basic feature when it comes to NVR security. A password.

If you don't want to use authelia you can use frigate in home assistant which has username and password. If you don't want that you can use nginx reverse proxy manager and use http basic auth. https://nginxproxymanager.com/advanced-config/

You don't need a domain you can use duck dns.

You can set host names up on your dns resolver ie unbound.

Even if using some other method to secure access to the web UI, the ability to create users with their own passwords and permissions seems like a very reasonable feature for a security product.
If I'm missing something here I apologize, but having both the feeds of all cameras and and full admin control available to anyone on the LAN in the out of the box config seems to crazy to me.

You can do this with Authelia

https://www.youtube.com/watch?v=kw_pohbKE3Y

Appreciate the reply.

Do I understand correctly that the suggested method is to configure roles via authelia that restrict access based on the URL's users are permitted to access?

If so that's workable, if a bit kludgy.

Putting that aside, unless I misunderstand their docs authelia seems pretty exclusively designed for use behind a reverse proxy, is there a recommended secure config for local access control?

Even if using some other method to secure access to the web UI, the ability to create users with their own passwords and permissions seems like a very reasonable feature for a security product.

If I'm missing something here I apologize, but having both the feeds of all cameras and and full admin control available to anyone on the LAN in the out of the box config seems to crazy to me.

You can do this with Authelia

https://www.youtube.com/watch?v=kw_pohbKE3Y

Appreciate the reply.

Do I understand correctly that the suggested method is to configure roles via authelia that restrict access based on the URL's users are permitted to access?

If so that's workable, if a bit kludgy.

Putting that aside, unless I misunderstand their docs authelia seems pretty exclusively designed for use behind a reverse proxy, is there a recommended secure config for local access control?

You always will need a reverse proxy to route / web server to route to apps. That's how the internet and web hosting works.

You can use ngnix or traefik as common reverse proxy's. I personally like traefik the most. However ngnix reverse proxy manager is a nice GUI over ngnix. If you go with traefik you can use https://github.com/thomseddon/traefik-forward-auth

Just go on YouTube and search setup traefik forward auth or authelia. There's a ton of videos out there.

Thanks. I will give the traefik link a look and do some reading.

The first page of the setup for Nginx reverse proxy manager ends with "Immediately after logging in with this default user you will be asked to modify your details and change your password".

I do not think it is unreasonable to expect a NVR which is an inherently security security related product to have access control as a development priority. If it's an issue of limited developer energy I totally get that, but to ignore it entirely in the OOB configuration seems crazy to me, especially given that it so many other projects include it by default.

We will be adding authentication at some point. This is a relatively young project maintained by a small number of people who have full time jobs and families. It's just been more of a priority to develop other features. Users either need to be comfortable setting up authentication or not care about someone seeing their camera video feeds when on their network.

Many users including myself have all exterior cameras showing areas that are visible to someone walking by my house from public property. If you are close enough to connect to my home network, you can already see everything the cameras see with your own eyes. It is very reasonable for many users to be comfortable with their cameras being visible on their LAN without authentication.

When Frigate does have authentication, I won't use it. I disable auth on every service I run on my server and use single sign via traefik for all services. Here is an example of how I run traefik to secure not just Frigate, but every other service I run on my server: #6250 (comment)

I'm going to lock this issue. If users would like help setting up authentication, please open a new discussion or support issue.