Is configuring this as a socket unix socket still adding value? #114
-
|
Hello community. I have been playing with this for a while and was struggling with some things. I found my solution in not using TCP sockets but the classic .sock file. I have this working and it is as expected... but noticed some of the configurations are not needed. Is this more secure than using the default socket? Which settings should I focus on to reduce reduce the footprint? Is this still of value? How to secure it best in this configuration? Many thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I am using socket-proxy as a Unix socket for my Beszel agent that's on the same machine as my Beszel hub as apparently host mode is needed for that agent. I think it still adds value insofar as attempts to use the Docker Engine API via the proxy will still be subject to the allow list, hence the best way to secure it is to have the most restrictive allow list that still allows enough to do what the container needs to do (and which you also want the container to do). An attacker who has compromised a container other than socket-proxy still cannot directly reach the original Docker socket since these other containers lack the relevant bind mount, even if they can reach the socket-proxy Unix socket. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I am a wee bit beyond my depth and did not know what settings were still applicable. do you stand up a unique proxy per service or configure teh allow* command with a cumulative setting over all teh services that run it? If running it as a socket, are there any extra precautions you would suggest one do? It is working well.... I just was concerned I was adding a layer to do what the native layer did anyhow... and not adding additional security to it. |
Beta Was this translation helpful? Give feedback.
I am using socket-proxy as a Unix socket for my Beszel agent that's on the same machine as my Beszel hub as apparently host mode is needed for that agent. I think it still adds value insofar as attempts to use the Docker Engine API via the proxy will still be subject to the allow list, hence the best way to secure it is to have the most restrictive allow list that still allows enough to do what the container needs to do (and which you also want the container to do).
An attacker who has compromised a container other than socket-proxy still cannot directly reach the original Docker socket since these other containers lack the relevant bind mount, even if they can reach the socket-proxy Unix…