Application requires Docker API Exposure on other Hosts

[pvyswiss]

The Application is nice made and a big win. However, exposing Docker-API even in a LAN Net is required to scan other hosts in the net.
That is always a security risk. I suggest to spend some time work with docker, rc-services and systemD Agents, with an Key and Token beside an expected port to be exposed. Adding a new host works only over the https:// Protocol and he expects Port 4999, which is useless on a scanning target. Second, if you like to make a sys admin Life easy, they have probably an existing HomeLab or Productive Environment. So adding hosts by CIDR eg 192.168.1.0/24 would make sense as a batch operation, assuming you have an agent deployed on this hosts.

Second, think about unpriviledged LXC Containers... Proxmox.

[mostafa-wahied]

Thanks for the feedback. Quick clarification on the architecture:

portracker uses a peer-to-peer design where each machine runs its own instance and they communicate over HTTP/HTTPS. Docker API is never exposed to the network since each instance connects to its own local Docker socket (or optionally through a docker socket proxy for additional security)

When you add a peer you specify the full URL including port, for example http://192.168.1.10:4999. The default 4999 is configurable via the PORT environment variable.

That said, your point about peer authentication is valid. Currently peer endpoints don't have token/key auth. This is planned for v1.3.0 as mentioned in the README.

For the other suggestions:

• CIDR/batch discovery: Noted as a feature request
• Proxmox LXC: On the roadmap for future collectors

Thanks again for the detailed suggestions.

[pvyswiss]

Thanks for your reply.

I will add some clarification:
I understand the p2p concept. But this requires in a LAN or DMZ or Cross Site, to open a Port 4999 (of course you can map it with port forwarding/nat rules. or what ever. Normally you have Core Firewall / Lab Firewall plus each host has either IPTAABLEs, UWF or something else in place. Now think about, we have a few hundred servers acting as Docker Hosts.

The easiest way would be: One Deployment as a Hub, Others connect over an Variable to the Hub. Agent Connects to Hub and estabish a connection. Once Conneced, Hub can run port scans. This scenario requires only on Hub to open Port 4999 (or whatever) You can add a step with OpenSSl, to generate SSL Certs with a yearly renewal over cron, let's say: /etc/porttracker/ssl add this ass variable. Most networks allow Host to Connect anywhere from inside out, or restrict that only on Core or LAB Firewall to allowed Nets. This way, less Ports has to be opened, Both in OPNsense and Local Firewall. And Deployment works automated over what ever you use, Komo.do , Swarm, Configu, Openbao Opening Firewall Ports does not work automatically on Core Firewalls / Mult-Level.... Keep Going, Playing with it. Really nice UI!

[mostafa-wahied]

Thanks for the follow-up and glad you're enjoying the UI!

You're right that the agent-hub model (agents connecting outbound to a central hub) would simplify firewall management for larger deployments. That's a valid architecture pattern used by tools like Zabbix, Netdata.

The reason I went with p2p is that it fits the homelab use case well. Most users have a handful of servers and don't need the complexity of agent distribution and management. Each instance is self-contained and just works.

That said, for larger deployments (50+ servers, cross-site, DMZ scenarios) I can see how the current model becomes tedious. This would be a significant architecture change though, but I'm open to exploring a hybrid approach in the future where both connection modes are supported. Keeping peer to peer for simple setups while adding an optional agent mode for more complex networks.

No promises on timeline, but I've noted this for the long term roadmap. Thanks for thinking through the use case!

let me know if that makes sense.

[pvyswiss]

Absolutely. I will make internal note, if we are sufficient, to think of your project :-)