Multi-hop sessions

Reaching a target inside a private network usually means opening inbound firewall rules, which many security policies prohibit. Boundary multi-hop sessions chain two or more workers together. Each worker connects outbound to the worker above it, which forms a reverse proxy path from the client to the target. Multi-hop configurations let you reach targets across multiple network enclaves without weakening your security posture.

Inbound network rules

With a multi-hop deployment, all connections are initiated outbound from the most downstream worker in the chain. After Boundary establishes the initial connection between the workers, it uses the established connection for any subsequent connections. These persistent TCP connections result in the requirement for only outbound connectivity.

If you have one or more firewalls sitting between the ingress and egress workers, you do not need to create additional inbound networking rules to facilitate a Boundary multi-hop deployment. This not only helps to simplify your infrastructure configuration, but also ensures that your security posture is not weakened or compromised.

Multi-hop worker types

In multi-hop scenarios, workers perform three roles: ingress, intermediate, and egress.

Tip

“Ingress,” “intermediate,” and “egress” are general ways to describe how the respective worker interfaces with resources, and a worker can act as more than one of those at a time. For example, in the following diagram the intermediate worker is also an egress worker, because it can access a target.

Multi-hop session example showing ingress, intermediate, and egress workers

The following sections describe each role and the network access it requires.

Ingress workers

An ingress worker is a worker that is accessible by the client. The client initiates the connection to the ingress worker.

To proxy target connections, ingress workers require outbound access to the Boundary control plane and inbound access from clients.

HCP Boundary clusters automatically deploy HCP-managed workers, which you can use as ingress workers. HCP-managed workers are helpful when your organization has strict network security policies that prohibit any inbound access. In this scenario, intermediate or egress workers within the private network establish a reverse proxy connection to the HCP-managed ingress worker.

Intermediate workers

An intermediate worker is optional. It sits between the ingress and egress workers as part of a multi-hop chain, and a chain can include more than one intermediate worker.

Intermediate workers require outbound access to an upstream worker, which may be an ingress worker or another intermediate worker. They also require inbound access from a downstream worker, which may be an egress worker or another intermediate worker.

Egress workers

An egress worker is a worker that can access the target. The egress worker initiates reverse proxy connections to intermediate or ingress workers.

To proxy target connections, egress workers require outbound access to an upstream worker and outbound access to the destination host or service.

Session path

After Boundary establishes the persistent connection chain between the workers, connecting to a target host proxies you through the following path:

Boundary client to the ingress worker
Ingress worker to the egress worker, through any intermediate workers in the chain
Egress worker to the target

Multi-hop worker capabilities

Multi-hop capabilities, including multi-hop sessions and Vault private access, is when a session or Vault credential request goes through more than one worker. To enable multi-hop capabilities, you must connect two or more workers to each other in some configuration. There are no limits on the number of workers allowed in a multi-hop session configuration.

It helps to think of “upstream” and “downstream” nodes in the context of multi-hop. If you view controllers as the “top” node of a multi-hop chain, any worker connected to a node is "downstream" of that node. The worker or controller that a node connects to is the "upstream" of that node. For example, in the diagram below, Worker 2’s upstream is Worker 1, and its downstream is Worker 3.

Worker chain in which Worker 3 connects upstream to Worker 2, Worker 2 connects to Worker 1, and Worker 1 connects to the controller

You can deploy multi-hop workers in scenarios where inbound network traffic is not allowed. A worker in a private network can send outbound communication to its upstream worker, and create a reverse proxy to establish a session.

You can configure target worker filters with multi-hop workers to allow for fine-grained control on which workers handle ingress and egress for session traffic to a target. Ingress worker filters specify the workers you use to initiate a session, and egress worker filters specify the workers you use to access targets.

Complete worker configuration

For the full set of worker parameters and a complete configuration example, refer to the worker stanza documentation.

Next steps

Refer to the following topics to configure multi-hop sessions: