You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2024. It is now read-only.
Instead of focusing on a mechanism (port binding), the focus should be on containerization, and the verbiage should also allow for things like UNIX-domain (file) sockets for the exposed connection. If anything, UNIX-domain sockets are superior to plain port binding because they're more secure on several axes:
Finer-grained access control, following the UNIX permissions model
No chance of a misconfiguration exposing the raw port to the outside world
Limits the attack surface for multiple users on a shared system
Additionally, in my own experience it makes things a lot easier to configure, since you don't have to run anything that keeps track of a service-port mapping, and it's way less likely to make mistakes with e.g. configuring multiple services on the same port or reverse proxying to the wrong one. You can also make better use of systemd to only launch the underlying service when the socket is needed by the fronting server, which can save on resources when managing several services which only run on rare occasion.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Instead of focusing on a mechanism (port binding), the focus should be on containerization, and the verbiage should also allow for things like UNIX-domain (file) sockets for the exposed connection. If anything, UNIX-domain sockets are superior to plain port binding because they're more secure on several axes:
Additionally, in my own experience it makes things a lot easier to configure, since you don't have to run anything that keeps track of a service-port mapping, and it's way less likely to make mistakes with e.g. configuring multiple services on the same port or reverse proxying to the wrong one. You can also make better use of systemd to only launch the underlying service when the socket is needed by the fronting server, which can save on resources when managing several services which only run on rare occasion.
The text was updated successfully, but these errors were encountered: