Relay Host Teleport
A relay host teleport setup routes engineer traffic through a public node to private servers. You set up a node in your network to dial back to the main cluster. Platform teams often use this design to reach servers behind strict firewalls. Still, broad node roles often give users full shell control across every linked host. Once a user logs in, they can run risky commands or read private files. How a relay host teleport architecture works In a standard setup, private servers sit inside a loc
Teleport: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A relay host teleport setup routes engineer traffic through a public node to private servers. You set up a node in your network to dial back to the main cluster. Platform teams often use this design to reach servers behind strict firewalls. Still, broad node roles often give users full shell control across every linked host. Once a user logs in, they can run risky commands or read private files.
How a relay host teleport architecture works
In a standard setup, private servers sit inside a locked network with no public IP. Engineers still need a way to log in and fix broken apps. To solve this, teams place an agent on a middle node or the target host. This node opens an outbound tunnel to the main cluster control plane.
When an engineer wants to log in, they first prove their identity to the cluster. The cluster checks their team role and issues a short-lived cert for the session. The engineer then sends traffic to the main cluster, which routes it down the tunnel. The relay node takes that traffic and passes it to the final private server.
This design keeps teams from opening inbound firewall ports on their private cloud networks. Outbound tunnels handle all the routing work behind the scenes for the user. Network admins only need to allow outbound traffic from the internal relay node.
Why native roles fall short during live sessions
This native routing model solves the problem of reaching hidden servers across split networks. It also ties server logins to your central identity provider and team groups. Admins can map group traits to server accounts and drop static SSH keys.
Yet this setup only decides who can open a tunnel to a host. Once the session starts, the native role does not inspect single commands or queries. If a user gets a shell on a host, they hold that OS role.
A broad role lets an engineer run destructive scripts or dump full database tables. Even if you log the screen, the damage happens before anyone reads the log. Teams also struggle when a relay node has wide network reach inside a VPC. Any user who can route through that node might reach sibling hosts on that subnet.
Teleport: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing commands and data inside the tunnel
To reduce risk, teams must move checks from the login step to the command step. Instead of granting full shell sessions, teams should limit what runs over the link. Admins can define rules that check each command or query before the server runs it.
When a user runs a database query, data masking can rewrite matched fields in results. This step replaces sensitive values like emails, phone numbers, card numbers, or national IDs. Engineers get the output they need to fix bugs, while private strings stay hidden.
For high-risk shell commands, teams can require a quick peer check in chat first. A lead reviews the exact command and approves it for a single run. This workflow keeps production safe without giving anyone standing admin rights on private hosts.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Do I need inbound firewall ports for a relay node?
No, the internal node dials out to your main cluster to build a reverse tunnel. Your network team only needs to allow outbound traffic from that private subnet.
Can a relay setup stop users from viewing sensitive customer data?
A basic network relay only moves packets and cannot inspect data inside a database stream. You need inline data masking to rewrite emails, phone numbers, or card numbers in results.
How do teams limit blast radius on shared relay nodes?
Teams restrict network routing from the relay host so it only reaches specific target ports. They also replace broad shell roles with command-level checks and peer approvals for risky tasks.