[GH-ISSUE #22] Feature Request: Entry Point Listing from static.yml #21

New issue

Closed

opened 2026-05-06 12:22:44 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-06 12:22:44 +02:00

Owner

Originally created by @wolfnacht44 on GitHub (Apr 12, 2026).
Original GitHub issue: https://github.com/chr0nzz/traefik-manager/issues/22

Originally assigned to: @chr0nzz on GitHub.

I know you're pulling entry points, but as it's a static YML I know they cant be edited or changed without restarting the service, and that may be a future implementation with a static editor.
However as a stopgap, is it possible to pull the entrypoints and list them in the route UI as check boxes as you did with the domains. or a selection similar to my feature request in #20

Originally created by @wolfnacht44 on GitHub (Apr 12, 2026). Original GitHub issue: https://github.com/chr0nzz/traefik-manager/issues/22 Originally assigned to: @chr0nzz on GitHub. I know you're pulling entry points, but as it's a static YML I know they cant be edited or changed without restarting the service, and that may be a future implementation with a static editor. However as a stopgap, is it possible to pull the entrypoints and list them in the route UI as check boxes as you did with the domains. or a selection similar to my feature request in #20

BreizhHardware

2026-05-06 12:22:44 +02:00

closed this issue
added the
feature request
label

BreizhHardware commented

2026-05-06 12:22:45 +02:00

Author

Owner

@chr0nzz commented on GitHub (Apr 12, 2026):

This is a simple fix for now; I’ll be adding the ability to select them from the available list.

I am also working on support for managing static .yml files. The main challenge is security, and here is the solution I’ve come up with:

Tecnativa's Docker Socket Proxy (ghcr.io/tecnativa/docker-socket-proxy)

This container acts as a security layer between the application and the Docker socket (/var/run/docker.sock). It restricts access to specific Docker API endpoints that you explicitly allow (e.g., container restarts) rather than granting the traefik-manager container full, unrestricted socket access.

The proposed workflow:

Restrict Permissions: Run the socket proxy with only CONTAINERS=1 and POST=1 enabled to allow restart calls.
Isolate the Socket: Mount the Docker socket into the proxy container only not into traefik-manager.
Proxy Communication: traefik-manager communicates with the proxy’s HTTP API instead of the raw socket.
Trigger Restart: When the static config changes, the app sends a POST /containers/traefik/restart request through the proxy.

This prevents traefik-manager from having raw socket access, which is a significant security risk for any network-exposed service.

What are your thoughts on this approach? Do you have a better method for restarting the Traefik container? (Side note: the standalone Linux installation is much simpler and doesn't require a socket proxy, so this wouldn't apply there.)

@chr0nzz commented on GitHub (Apr 12, 2026): This is a simple fix for now; I’ll be adding the ability to select them from the available list. I am also working on support for managing static .yml files. The main challenge is security, and here is the solution I’ve come up with: **Tecnativa's Docker Socket Proxy** (ghcr.io/tecnativa/docker-socket-proxy) This container acts as a security layer between the application and the Docker socket (/var/run/docker.sock). It restricts access to specific Docker API endpoints that you explicitly allow (e.g., container restarts) rather than granting the traefik-manager container full, unrestricted socket access. **The proposed workflow:** * **Restrict Permissions:** Run the socket proxy with only CONTAINERS=1 and POST=1 enabled to allow restart calls. * **Isolate the Socket:** Mount the Docker socket into the proxy container only not into traefik-manager. * **Proxy Communication:** traefik-manager communicates with the proxy’s HTTP API instead of the raw socket. * **Trigger Restart:** When the static config changes, the app sends a POST /containers/traefik/restart request through the proxy. This prevents traefik-manager from having raw socket access, which is a significant security risk for any network-exposed service. What are your thoughts on this approach? Do you have a better method for restarting the Traefik container? (Side note: the standalone Linux installation is much simpler and doesn't require a socket proxy, so this wouldn't apply there.)

BreizhHardware commented

2026-05-06 12:22:45 +02:00

Author

Owner

@wolfnacht44 commented on GitHub (Apr 12, 2026):

Ahh okay, I wasn't sure if it was a quick dirty implementation or a permanent one.

I'm personally not too familiar with docker, unfortunately, and my experience with it is limited.
It seems like Docker Socket is the only option, from I can find, and DSP (Docker Socket Proxy) seems to mitigate some of the security risk. However, there would still be security risk, if DSP gets abandoned, or 0-days found within docker itself.

Would there be an option to "bundle" Traefik in your image as an option? or would there be a way to "SSH" into Traefik container with self generated keys?

Custom implementation may be required. I do believe there's some softwares out there that can spin-up, shut-down, and restart, other docker containers pending the needs of docker.
It also seems relatively common place in home-labs that people run a front-end for docker, would there be a way to hook into a front-end API such as Rancher/Portainer/etc?

I'll look further into this. When I get some downtime. However, this might be the best approach for the time being, but it'd be a pain to rewrite an entire module just for a simple feature.

I've only been testing the Native install, in a "mirrored" production environment. I figured it's less common practice these days, and if you're supporting it, I'll poke at it.

@wolfnacht44 commented on GitHub (Apr 12, 2026): Ahh okay, I wasn't sure if it was a quick dirty implementation or a permanent one. I'm personally not too familiar with docker, unfortunately, and my experience with it is limited. It seems like Docker Socket is the only option, from I can find, and DSP (Docker Socket Proxy) seems to mitigate some of the security risk. However, there would still be security risk, if DSP gets abandoned, or 0-days found within docker itself. Would there be an option to "bundle" Traefik in your image as an option? or would there be a way to "SSH" into Traefik container with self generated keys? Custom implementation may be required. I do believe there's some softwares out there that can spin-up, shut-down, and restart, other docker containers pending the needs of docker. It also seems relatively common place in home-labs that people run a front-end for docker, would there be a way to hook into a front-end API such as Rancher/Portainer/etc? _I'll look further into this. When I get some downtime._ However, this might be the best approach for the time being, but it'd be a pain to rewrite an entire module just for a simple feature. I've only been testing the Native install, in a "mirrored" production environment. I figured it's less common practice these days, and if you're supporting it, I'll poke at it.

BreizhHardware commented

2026-05-06 12:22:45 +02:00

Author

Owner

@chr0nzz commented on GitHub (Apr 17, 2026):

new update out

@chr0nzz commented on GitHub (Apr 17, 2026): new update out