Hybrid Access Nodes
You set up hybrid access nodes by running outbound agents inside each private network. These nodes link local systems and cloud networks without opening inbound firewall ports. Many teams start by linking networks with broad site-to-site VPN tunnels. That wide network path lets one bad role reach every server on the subnet. Teams use node agents to keep network paths tight and separate. How hybrid access nodes work in split networks A modern company often runs apps across both local servers a
Access Nodes: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up hybrid access nodes by running outbound agents inside each private network. These nodes link local systems and cloud networks without opening inbound firewall ports. Many teams start by linking networks with broad site-to-site VPN tunnels. That wide network path lets one bad role reach every server on the subnet. Teams use node agents to keep network paths tight and separate.
How hybrid access nodes work in split networks
A modern company often runs apps across both local servers and public clouds. Linking these split networks takes careful planning and clear rules. Traditional network bridges join whole subnets together at the IP level. If an attacker gets on one subnet, they can scan the other side.
Hybrid access nodes solve this problem by shifting how traffic moves. You install a small node service inside the private subnet next to your targets. The node dials out to a central control plane over standard encrypted ports. Because the node dials out, you keep all inbound firewall ports shut.
Your firewall team does not need to manage complex public IP allowlists. Network admins also avoid building fragile routing tables between every cloud VPC. Each node acts as a local relay for approved user traffic. You place one node in each isolated network zone you own.
How to set up roles and permissions on each node
Setting up a node starts with creating a machine role in your cloud or local host. This role needs network routes only to the specific databases or servers it serves. You should never put the node on a flat network that reaches everything. Instead, use local firewall rules to limit which ports the node can touch.
Next, you register the node with your central control plane using a registration token. This token binds the running node to its assigned network zone. Once registered, the node waits for approved user sessions from the control plane. Admins map directory groups to specific targets behind that node.
You should also set up host rotation and health checks for each node. Running two nodes per zone keeps traffic flowing if one host fails. Give the node host minimal local disk rights and lock down its operating system. Only the node service account should read the local registration secret.
Access Nodes: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native node setups solve and what they miss
Native node setups solve the tough problem of crossing private network boundaries. They remove public IP addresses from your databases and internal servers. They also replace wide VPN tunnels with narrow, outbound-only links. Your network team gets a clean way to reach legacy data centers and cloud VPCs.
Still, a basic network node only checks who can open a tunnel. Once the tunnel opens, the node passes raw bytes back and forth. It does not check what commands or queries the user runs inside that session. A developer with a valid role can still run a destructive drop table query.
Standard network nodes also force you to distribute database keys or SSH keys to users. Or they rely on static keys stored on the local target host. Also, if a user queries a table with customer emails or phone numbers, the node sends everything. A basic node cannot rewrite sensitive fields like card numbers or national IDs in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Do hybrid access nodes require inbound firewall rules?
No, these nodes open outbound connections to the control plane. Your firewall keeps all inbound ports closed to the public internet, which lowers exposure to outside scans.
How many nodes should a team run per network zone?
Teams should run at least two nodes in each private subnet or cloud VPC. This setup keeps connections active during host patching or unexpected hardware failures.
Why is network-level node routing not enough for database security?
Network routing only controls which host a user can reach over TCP. It does not inspect SQL statements, require peer approval for risky commands, or mask sensitive fields in query results.