Boundary Server
A boundary server routes user traffic to private hosts using identity rules instead of IP rules. You set up a controller and worker nodes to check roles before starting a network session. Teams often group many hosts under broad roles to save setup time. When roles are too broad, users gain entry to whole subnets and sensitive data stores. How a boundary server manages network sessions A boundary server splits its work between two main node types. The controller node holds the state, user rol
Kubernetes API Server Access + Boundary (HashiCorp): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A boundary server routes user traffic to private hosts using identity rules instead of IP rules. You set up a controller and worker nodes to check roles before starting a network session. Teams often group many hosts under broad roles to save setup time. When roles are too broad, users gain entry to whole subnets and sensitive data stores.
How a boundary server manages network sessions
A boundary server splits its work between two main node types. The controller node holds the state, user roles, and host catalogs. It talks to your identity provider to check who is logging in. The worker node sits inside the private network and moves the actual bytes.
First, an admin defines scopes to group projects and teams in the system. Inside each project, the admin creates a host catalog for servers and databases. Next, the admin links those hosts to targets with set network ports. Roles then bind user groups to specific actions on those targets.
When an engineer needs to work, they log in through a client tool. The controller checks their group membership and matches it against the target rules. If the check passes, the user gets a session token for the worker node. The worker opens a TCP tunnel from the user device to the target host.
Teams can also link the controller to external secret stores to fetch database keys. When the session starts, the user receives temporary keys to log into the database. This design removes the need to put database passwords into shared team vaults. It also keeps private servers off the public internet without using a full VPN.
What native network routing solves and what it misses
This architecture solves the problem of wide network exposure across your cloud accounts. Users no longer join a flat VPN that exposes every port on a subnet. Instead, they only reach the exact host and port listed in their role. Network admins also avoid managing static firewall rules when staff members change teams.
Still, a TCP tunnel only checks identity at the start of a session. Once the worker node connects the pipe, it does not read the traffic inside. It cannot tell the difference between a safe read query and a table drop. All actions run with the full power of the database role tied to the session.
Kubernetes API Server Access + Boundary (HashiCorp): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Because the worker works at the transport layer, it cannot mask sensitive fields. If a table holds emails, phone numbers, or card numbers, the query returns everything. Dynamic data masking cannot rewrite matched fields in results over a raw TCP pipe. Teams must either build custom database views or accept the risk of raw data exposure.
Audit logs also lack detail when you only track network connections and ports. The controller logs who started a session, which target they used, and when it ended. It does not log the exact SQL statements or shell commands the user ran. To trace an incident, admins must dig through local logs on each target host.
Why teams struggle with day-to-day role upkeep
As a company grows, the number of targets and roles multiplies fast. Admins must create separate targets for read-only work, schema changes, and prod fixes. Each target needs its own scope, host set, and secret store mapping. Soon, the platform team spends hours each week updating role bindings for simple tasks.
To cut down on tickets, teams often fall back to shared admin targets. Engineers use these high-power targets even when they only need to check a single row. A single typo in a console session can then delete critical production data. Safe operations require controls that check each command or query while the session runs.
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
What is the difference between a controller and a worker node?
The controller handles user logins, checks role rules, and manages the system state. The worker handles the network traffic and routes TCP packets to the private host.
Does a boundary server replace a traditional VPN?
Yes, it replaces a VPN for engineering access to servers, clusters, and databases. It opens direct tunnels to single ports instead of bridging the whole private network.
Can a boundary server inspect or filter SQL queries?
No, it forwards raw TCP traffic and does not parse database protocols in flight. You need an app-level tool to block dangerous queries or rewrite sensitive fields in results.