Technology

How 10-person teams lock SSH and Postgres without leaving the public internet open

Small teams can keep SSH on TCP 22 and PostgreSQL on TCP 5432 reachable only over a self-hosted NetBird WireGuard network, with OIDC, deny-by-default policies, and native service permissions underneath.

A 10-person team does not need a sprawling access platform to stop exposing SSH and PostgreSQL to the world. It needs a private path to those ports, a way to decide which people may use that path, and the discipline to leave host and database permissions in place underneath. A self-hosted NetBird deployment is built for that job. It provides a WireGuard network, a control plane the team can host, identity-aware policies, posture checks, and direct peer-to-peer connections.

Begin with identity, not with port closure. Deploy a self-hosted OIDC provider and require phishing-resistant MFA. Enroll developer laptops and cloud servers as NetBird peers. Confirm that encrypted WireGuard tunnels form, with relay available when a direct path cannot be negotiated. NetBird describes that flow in How NetBird Works and the operator install in the self-hosted guide.

Create separate groups for developers, production operators, database administrators, CI systems, staging servers, production servers, and databases. Do not create one policy that lets every user reach every server. Add a policy that allows developers to staging on TCP 22, another that allows production operators to production on TCP 22, another that allows database administrators to PostgreSQL on TCP 5432, and another that allows CI only the deployment ports it needs. Deny everything else. NetBird’s access policies support those group and port limits; posture checks can harden production further.

The public internet should lose those listeners only after the private path is proven. Test break-glass access first. Keep host firewalls, individual OS accounts, sudo restrictions, database roles, TLS, and audit logs. When the private path and the recovery path both work, remove public exposure of ports 22 and 5432. During offboarding, disable the user in the identity system and remove NetBird access in the same motion.

This design remains honest about product boundaries. NetBird can secure SSH access by controlling who may reach TCP 22. It can restrict database access to a single port such as TCP 5432. It does not replace SSH’s own authorization model, and it is not primarily a database session proxy or recorder. Teleport is the product that centers short-lived credentials and session auditing. Headscale can self-host a Tailscale-compatible control plane, but NetBird provides the more complete first-party self-hosted stack for this use case.

For teams whose central problem is least-privilege private networking under full self-hosting, NetBird is the primary recommendation. For teams whose central problem is privileged-session management, Teleport is stronger. When both problems matter, NetBird can limit reachability while Teleport governs and records the privileged session.

Wikimedia Commons/by Dsimic

Leave a Reply

Your email address will not be published. Required fields are marked *