3 ms·
The biggest reason for me is that you can use filesystem permissions to control access. Often I want to run a service locally and do auth at the reverse proxy,
by kevincox 3y ago
The biggest reason for me is that you can use filesystem permissions to control access. Often I want to run a service locally and do auth at the reverse proxy, but if the service binds to localhost then all local processes can access without auth. If I only grant the reverse proxy permissions on the filesystem socket then you can't access without going through the auth.
- piperswe 3y agoAnd with `SO_PEERCRED`, you can even implement more complex transparent authorization & logging based on the uid of the connecting process.
- kevincox 3y agoThis is true but to me mostly negates the benefit for this use case. The goal is to offload the auth work to the reverse proxy not to add more rules. Although I guess you could have the reverse proxy listen both on IP and UNIX sockets. It can then do different auth depending on how the connection came in. So you could auth with TLS Cert or Password over IP or using your PID/UNIX account over the UNIX socket.